Live data from Hacker News

Mongrel2 Says, "Goodbye Python"

sheddingbikes.com

31–40 of 251 posts

Re: Mongrel2 Says, "Goodbye Python"

#31
post #9
post #4

Zed's pronouncements are works of art. The man is a pro. A veritable Martin Luther for our times.

Indeed. I got to the statement: "The distros have killed Python." Said out loud, "here we go", and settled down for some classic Zed. Can't fault him on it, though.

I'd go one further: distros in general haven't killed Python, Red Hat has. By tying their flagship OS to a six-year-old Python release, they've made it impossible for a lot of popular software to move on and take advantage of more recent advances in the language (since "screw everybody who uses Red Hat" simply isn't a viable option).

Re: Mongrel2 Says, "Goodbye Python"

#32
I guess it was just about time for me to try mongrel on a fresh new project. I feel I am blessed for that only. Seeing that 0MQ batteries are included is a great bonus.

If all would be fine, perhaps my network appliance would be shipped with mongrel2 which would be fantastic.

Re: Mongrel2 Says, "Goodbye Python"

#33

Completely agree. The Linux distros (CentOS is the one I work with most, not out of choice) have antiquated Python versions. You can get round it with virtualenv etc., and I do this as a matter of course when installing Python web applications. For a generic "plug and play" package like Mongrel2 however, where sysadmins just want something that runs straight out of apt-get or whatever, it's a pain and is holding thin…

CentOS is about as conservative an option as you can get, though. Unusably so, in my opinion. None of the other popular distros have packages that old.

Question to manager: WTF are we using CentOS ?

Reply: because it's Enterprise.

Re: Mongrel2 Says, "Goodbye Python"

#34
post #21

Python, as per Guido Van Rossum's wishes, is pushing for suspension of all language syntax and built-in changes and work towards preserving semantics, precisely for giving time to alternative implementations time to catch up with CPython, as well as the various distributions to catch up with Python's recent progress. In short: "...have killed Python" is a hyperbole for saying "I was tired to hear people nagging about…

[deleted]

Re: Mongrel2 Says, "Goodbye Python"

#35
post #21

Python, as per Guido Van Rossum's wishes, is pushing for suspension of all language syntax and built-in changes and work towards preserving semantics, precisely for giving time to alternative implementations time to catch up with CPython, as well as the various distributions to catch up with Python's recent progress. In short: "...have killed Python" is a hyperbole for saying "I was tired to hear people nagging about…

I've never heard the distro argument used by any of the python maintainers and I would be surprised if they had. The solution to distros which are bundling three year old software is not to halt your progress for three years, that should be obvious.

I was mentioning it as a side-effect, the main reason was to give time to alternative Python implementations to reach Python 3.1.

Re: Mongrel2 Says, "Goodbye Python"

#36
post #24
post #16

Earlier quoted context omitted.

Firstly: no hoops are required to install any version of python or any required Python module your app needs: * Just use pip and virtualenv. * Your OS remains intact, and you get better deployment for free! Replacing a component of your OS (Python 2.x) with another one (python 2.x +1 ) affects: * The OS installer (Anaconda on RHEL, Ubuntu'sequivalent) * The packaging system (yum) * Many GNOME system admin apps. * The…

My point is that /usr/bin/python probably shouldn't be a core OS component. /usr/bin/python should be whatever I want it to be. The core OS-component should be something like /sys/bin/centos-python which I will never directly use, touch or even necessarily know about. The bottom line I guess is that mixing core OS components and user installed software in the same directory structure with no way of differentiating th…

> /usr/bin/python should be whatever I want it to be.

Why /usr/bin/python? /usr/bin/ has been for ages the "system" area - why would you want to suddenly usurp it for yourself?

/usr/local/bin/python will on most Linux systems be executed ahead of /usr/bin/python, because /usr/local/bin/ usually precedes /usr/bin/ on the $PATH. Thus you can have your cake and eat it too.

> The bottom line I guess is that mixing core OS components and user installed software in the same directory structure with no way of differentiating them is simply bad design.

Linux distro makers agree with you - if you do not customize environment variables, user-installed software goes into /usr/local/ and the OS package-management (which can be considered "system" I guess) puts executables into /usr/{bin,sbin}.

This tends to work well as long as you keep in mind that everything outside of /usr/local/ (or your customized installation path) may at any update change subject to the will of the "system". I think this is a reasonable setup - it gives the OS vendor the ability to update the system, while giving you free reign in your /usr/local/ playground.

Re: Mongrel2 Says, "Goodbye Python"

#37
It's sad and ironic (for Python) that Zed actually had to switch from Python to C to make Mongrel more portable.

Disclaimer: I love Python, but I hate that anything but the most trivial code won't run across all versions.

Re: Mongrel2 Says, "Goodbye Python"

#38

I'm not sure why he concerns himself with old distros. Are they the customers for Mongrel2? The description on the website emphasizes modern web technologies. Using Rails 3 is best with Ruby 1.9.2, and yet the only popular distros that install that via their package management system are the rolling release ones, Arch Linux and Gentoo (where it is masked). Most people willing to use this brand new software are also w…

Upgrading Ruby to 1.9.2 won't break your OS. Upgrading Python on some distros can even break package management. That's the difference.

And if you have a well tested, rock stable environment you generally don't want to mess with it if you don't have to, or may not easily be able to.

You want to not support older than Lenny. Well, we have machines that are still on Sarge, though slowly being upgraded. Some of the machines haven't been rebooted since around the time Etch came out and that's the main reason they haven't been upgraded yet.

Re: Mongrel2 Says, "Goodbye Python"

#40
post #15

Earlier quoted context omitted.

I'd very much like to know why it wasn't easier for him to simply write a Python code that doesn't use anything not existing in 2.4. Just because he downloaded to his computer whatever later version he likes he can't expect from all distros and all users to have exactly the same version across of all the currently running computers, it's more than unrealistic, it's simply impossible and always will be.

I'd very much like to know why it wasn't easier for him to simply write a Python code that doesn't use anything not existing in 2.4. This isn't an "oh, a brand-new version just now came out and it's not in the distros yet" problem. Python 2.4 is six years out of date at this point. Python 2.3, which Red Hat will support until 2012, is even older (and for the longest time Red Hat didn't even use a 2.x Python at all --…

Why is it "simply unacceptable" to produce the code to the least common denominator?

Anything that is successful must have more versions in the installed base. You can target a single version of something only if it's not used at all. It seems too much developers live in "Everybody must have that what I have" world.

I haven't tried myself, but I can't believe Python changed that much that you can't write the plain Python code to the least common denominator of versions >= 2.4. If you have the specific examples why you can't I'd like to know them.

Edit: I've rechecked, he actually mentions 2.2 as the lowest version he saw, still I believe it doesn't change too much.

Post reply on HN