Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mongrel2 Says, "Goodbye Python"

sheddingbikes.com

Post reply on HN
Print view View original

41–50 of 251 posts

Re: Mongrel2 Says, "Goodbye Python"

#41

Post by rbanffy »

It's funny how, for Zed, anything that doesn't work the way he thinks it's supposed to work is "broken" and the result of some boneheaded decision and that it "sucks".

I too am frustrated by ancient versions of server OSs that use equally ancient versions of Python, but that's why virtualenv was invented. And source distributions. I am happy using it when required.

Being "stable" in OS terms is not changing APIs very often. One of the good things is that I know that code I wrote for RHEL 4 the day it was launched will run flawlessly on RHEL 4 today. The primary goal of such a Linux distro is that "it has to work". I won't touch the system parts.

Re: Mongrel2 Says, "Goodbye Python"

#42

Post by munchhausen »

dagw wrote: post #26
nailer wrote: post #20

Earlier quoted context omitted.

Stuff that belongs to the OS (but runnable by all users) is in /usr/bin. That's FHS. Stuff that's yours is wherever dir you specified when you ran: export WORKON_HOME=$HOME/.virtualenvs Seriously. Use virtualenv (and virtualenvwrapper). http://www.doughellmann.com/projects/virtualenvwrapper/

What about stuff that belongs to me (the sysadmin) but runnable by all users? /usr/local/bin? /opt/bin? /my/homemade/solution/bin? There is a bunch of stuff that doesn't (shouldn't) belong to the OS, but still be runnable by all users without all of them needing a copy in their $HOME directory.

You answered your own question - /usr/local/bin. I don't know about MacOSX but on Linux, this is the solution to your problem - "stuff that belongs to me (the sysadmin) but runnable by all users".

Re: Mongrel2 Says, "Goodbye Python"

#43

Post by gaius »

dagw wrote: post #26
nailer wrote: post #20

Earlier quoted context omitted.

Stuff that belongs to the OS (but runnable by all users) is in /usr/bin. That's FHS. Stuff that's yours is wherever dir you specified when you ran: export WORKON_HOME=$HOME/.virtualenvs Seriously. Use virtualenv (and virtualenvwrapper). http://www.doughellmann.com/projects/virtualenvwrapper/

What about stuff that belongs to me (the sysadmin) but runnable by all users? /usr/local/bin? /opt/bin? /my/homemade/solution/bin? There is a bunch of stuff that doesn't (shouldn't) belong to the OS, but still be runnable by all users without all of them needing a copy in their $HOME directory.

Well exactly. People who never learnt the old-skool ways always reinvent the wheel in an over-complex way. /usr/local/bin is stuff for the users, but which the sysadmin installs. So /usr/bin/python for the OS and /usr/local/bin/python for your users.

Re: Mongrel2 Says, "Goodbye Python"

#44

Post by gfunk911 »

This thread is a classic example of something that happens over and over.

Someone says something is hard to use.

1/3 of the responses agree.

1/3 of the responses disagree, say it's simple.

1/3 of the responses say it's simple, all you have to do is use additional software package Y to manage X and it works great.

This is usually a sign that there is some merit to the original assertion.

Re: Mongrel2 Says, "Goodbye Python"

#45

Post by rbanffy »

donaq wrote: post #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.

> I hate that anything but the most trivial code won't run across all versions.

Please, define "all versions" and "most trivial code".

I have very little problems with Pythons ranging from the ancient 2.4 to modern 2.7. Of course, I am careful with what I do. I know if I use a dictionary comprehension I will be limited to 2.7+, so I try not to. I am quite sure a lot of the code I write could run under any 2.x Python with little modification. As for 1.x, I will agree that things get more complicated.

Re: Mongrel2 Says, "Goodbye Python"

#47

Post by nailer »

dagw wrote: post #26
nailer wrote: post #20

Earlier quoted context omitted.

Stuff that belongs to the OS (but runnable by all users) is in /usr/bin. That's FHS. Stuff that's yours is wherever dir you specified when you ran: export WORKON_HOME=$HOME/.virtualenvs Seriously. Use virtualenv (and virtualenvwrapper). http://www.doughellmann.com/projects/virtualenvwrapper/

What about stuff that belongs to me (the sysadmin) but runnable by all users? /usr/local/bin? /opt/bin? /my/homemade/solution/bin? There is a bunch of stuff that doesn't (shouldn't) belong to the OS, but still be runnable by all users without all of them needing a copy in their $HOME directory.

> What about stuff that belongs to me (the sysadmin) but runnable by all users?

If you're writing quick ad-hoc scripts and don't have time to package, /usr/local/bin.

Per above, Python is used by your OS. It's installed by default, and not uninstallable, because the OS needs it. We can't and probably don't want to change that, so we'll need to live with it.

Use virtualenv. if you need to to, install a quick Python 2.6 package that slots alongside your OS package rather than removing it - using RHEL 5 as an example, you'd install 'python26' alongside your existing 'python' package.

Re: Mongrel2 Says, "Goodbye Python"

#48

Post by gaius »

ubernostrum wrote: post #31
auxbuss wrote: post #9

Earlier quoted context omitted.

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

This is a complete non-issue. ActiveState for example installs Python, Tcl, etc in /opt.

Re: Mongrel2 Says, "Goodbye Python"

#49

Post by avar »

ubernostrum wrote: post #27
acqq wrote: 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 --…

In the Git project we target Perl 5.6 for critical code (like git add --interactive) and Perl 5.8 for some other code (like git-svn). Those are 10 and 8 years out of date, respectively. Or the equivalent of targeting Python 1.6 and 2.0.

It can be mildly annoying sometimes to have to use 5.6 features when I usually develop on 5.12 or newer, but Perl's policy of backwards compatibility makes this a lot easier than it would be in Python.

Git also has some Python code that targets 2.4, making it compatible with such an old version was relatively easy (see http://git.kernel.org/?p=git/git.git;a=commit;h=23b093ee087e... for an example). A lot easier anyway than rewriting and maintaining that code in C.

Re: Mongrel2 Says, "Goodbye Python"

#50

Post by barfoomoo »

zeemonkee wrote: post #33
joelmichael wrote: post #23

Earlier quoted context omitted.

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.

Which distro you think is the best to run LAMP stack with an up to date package manager?
Post reply on HN