Pushing Python Past the Present | Hacker News Reader

Pushing Python Past the Present

archlinux.me

76 pointsgits122522 comments

It is interesting that the author is an Arch Linux developer. My sole experience in the #python channel on freenode [1] was to be badly flamed once the room discovered I was an Arch user. Apparently there is considerable annoyance at Arch's decision to install Python 3 as /usr/bin/python, against the recommendations of the Python community.

While I understand that this decision may have increased calls for help from Arch users in #python, Arch is strictly rolling release, and Python 3 has been out for 4 years now. Given this last fact, the vitriol I encountered was quite surprising.

[1]: Asking simply for a method to obtain compile-time information about python from python. I got the answer from a sympathetic person in the channel. Thanks felipe

> Apparently there is considerable annoyance at Arch's decision to install Python 3 as /usr/bin/python, against the recommendations of the Python community.

Really? Isn't Arch complaint with PEP 394 [1], which deals with that issue? The problems are mostly with people assuming `python` means `python2`, and distros/installs not providing the `python2` command.

[1]: http://www.python.org/dev/peps/pep-0394/

Quote your link:

>python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions

Is Arch considered bleeding edge?

I see Arch as a kindler, gentler gentoo. So maybe not bleeding edge, but definitely an edge. You should only be there if you know why you want to be there.

Do you have USE flags in the (mainly) binary distro you compare to Gentoo?

It's been years since I tried gentoo (and eventually decided it wasn't for me), so I had to look up USE flags. Great idea.

I've never run Arch, my impressions are from what I've read. Coincidentally it was the python3 thing that helped me decide not to use Arch.

Since I don't run arch (or gentoo) I don't speak with any authority. Searching around, I saw something about yaourt, which may or may not serve the same intention for the type of distro that arch is.

https://wiki.archlinux.org/index.php/Yaourt

Dunno.

Sort of. The package building system is very simple and arch provides facilities for building everything from scratch if you want to.[1]

[1]: https://wiki.archlinux.org/index.php/Arch_Build_System

USE flags on Gentoo are a way to expose configuration options to the user, not just allowing packages to be built from source. More details: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=...

That's why I said "sort of". Arch (as far as I know) doesn't provide a global way to do what USE flags do in gentoo, but the same end can be acomplished by tweaking the packages . There are also ways to apply those changes automatically, but they are not the same thing either.[1]

[1]: http://aur.archlinux.org/packages.php?ID=10314

No, arch doesn't have anything remotely as use flags. But is 'gentoo-like' in that they serve upstream vanilla, without modifcations. I still prefer Gentoo's use flags and tolerating the suckage that sometimes ocurrs when an emerge fails.

Someone should make a way to sharing ebuilds with the same useflags and CFLAGS(or at least compatible CFLAGS) so users could opt-in and 'crowdsource' the binary generation, as I feel gentoo with binary packages would be the best distro ever (I am aware portage supports binary files, it is just prohibitevly expensive to support all configurations.

Gentoo doesn't have a fixation on vanilla packages. In fact it's quite common to see multiple patches going aside your average ebuild.

The combination of USE flags / CFLAGS / LDFLAGS that make sense for individual users is so high that maintaining binary repos doesn't seem feasible.

It's not bleeding edge, just up to date. There are testing and stable repositories, but the stable packages are supposed to provide stable software rather than a stable system as a whole. You, as the user, are responsible for the stable system.

> The problems are mostly with people assuming `python` means `python2`, and distros/installs not providing the `python2` command

Yes, Arch follows the recommendations of the link you provided. I was compiling a naïve program that assumed /usr/bin/python to be Python, so I was trying to hack autoconf (or cmake?) by overriding the hard-coded path with the python2 libdir.

I thought it would be nice to ask python2 itself for its library path so I asked #python. The channel moderator in turn appended "NO ARCH" to the channel banner once I mentioned Arch Linux.

Not nice at all, to say the least.

I think the blame ultimately lies on the Python side, for not giving clear guidance that switching /usr/bin/python is a bad idea. (But Arch definitely deserves plenty of blame for making a bad decision where the Python guidelines allowed them to choose.)

http://mailman.archlinux.org/pipermail/arch-general/2011-Dec...

Arch should just make /usr/bin/python point to PyPy from now on. Screw the C modules that can't keep up with the E.U. and crowd funded future, right? As long as your pure python code is repeated long enough to be traced and JITed, you'll be almost OK.

Freenode channels are not a representative sample of any community. While people are often incredibly helpful, the channels are unmoderated (or moderated poorly, as you describe further down) and easily hijacked by people who have nothing better to do than give out poor, abrasive, opinionated advice. I've lost count of times when I came into a channel and asked a specific technical question, only to be flamed for a completely tangential reason, or receive 100% certain, 100% incorrect advice.

What you say is not terribly far from the truth in general, and since it appears you meant it as such (as a general statement) I'll take it as if you did, but #python is not unmoderated by any means, nor is it moderated poorly on the whole in my opinion, and this is not a reflection of hijacking of any sort.

I personally agree with the sentiment, though if I were one of the ones that responded to the OP I hope I didn't do so abrasively.

I think it's pretty easy to get flamed on IRC; pick a channel and then pick an opinion that differs from the majority. I've been told I was stupid and irrational for preferring the wrong code editor before. It's admittedly infuriating when supposed adults act and argue like children, but I guess it's not a big deal in the long run.

>I think it’s unfortunate that the only way to code for a web browser is to use JavaScript or a language that compiles to JavaScript. I feel there is no real reason browsers can’t support arbitrary <script type=""> tags. I discussed this last March.

I don't find that unfortunate at all. With one single standardized language we have fragmentation across browsers which sometimes causes problems. Allowing arbitrary languages would be a nightmare.

There is, of course, a workable way to do arbitrary languages already, which is to do it the way CoffeeScript and many of its cousins do it: implement the compiler in JS and compile your scripts to JS on the client side.

Would it be nice if such compilers could compile to a more sane and low level intermediate representation instead? Sure. But that's not the world we live in, or will likely ever live in (although maybe, if the IR were a subset of JS... but I digress).

I agree with the author on this one. It's not a language's job to solve browser fragmentation.

> With one single standardized language we have fragmentation across browsers which sometimes causes problems. Allowing arbitrary languages would be a nightmare.

I'm not sure about that.

One thing i really dislike about web development is that it's so unnecessary complicated to say "i want to use ECMASript 5 for this web page" and then let the browser decide what to do, either just stupidly show an error message, or, more intelligently, download the necessary components to make ECMAScript 5 work, kind of what a package manager would do. If the web would have been polyglot from the start (in the scripting language side), i think it's not far fetched to imagine that browsers could have adopted a similar approach to the later one.

Really, i feel it's really stupid that we've been fallen into this "beware, <browser X> doesn't support Array::map!" trap, instead of "how silly, Array::map didn't exist because i didn't mark my <script> tag with language=ecmascript5, now it does :)". I can't but feel that Only One Scripting Language to Rule Them All mentality brought us here.

But anyway, the What Would Have Happened If won't take us anywhere. The decision for us to make is: do we embrace a polyglot/package managed like architecture now, or do we continue with (re)standardising the one and only web scripting language?

Reply on news.ycombinator.com