

Pushing Python Past the Present - gits1225
http://archlinux.me/dusty/2012/10/04/pushing-python-past-the-present/

======
guns
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

~~~
fmoralesc
> 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/>

~~~
Goopplesoft
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?

~~~
antidoh
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.

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

~~~
fmoralesc
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>

~~~
stefantalpalaru
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=...](http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=2)

~~~
fmoralesc
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>

------
mistercow
>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).

~~~
epidemian
> 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?

