Live data from Hacker News

Mongrel2 Says, "Goodbye Python"

sheddingbikes.com

71–80 of 251 posts

Re: Mongrel2 Says, "Goodbye Python"

#71

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.

We're talking about technology, not politics so consensus be damned. There is a fact of the matter independent of perception and lack of consensus in and of itself is not a valid attack on a position.

In this case maybe we can listen to those who claim the python situation isn't that bad and have provided specific technical solutions for evaluation.

Re: Mongrel2 Says, "Goodbye Python"

#73
post #40

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. 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 Py…

What's the point of ever producing newer versions of a language with new features (or, golly, even bug fixes) if no one will ever use them because everyone has a 'lowest common denominator' mentality? More to the point, what is the process of changing the 'lowest common denominator' everyone's using?

Re: Mongrel2 Says, "Goodbye Python"

#74
post #49

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. 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 w…

> equivalent of targeting Python 1.6 and 2.0.

I'm less in touch with Perl language development in the past decade, but my impression is that the difference between Perl-5.6 and Perl-5.12 is much less than between these versions of Python and recent releases. This is expected when a language evolves rapidly, but it's rather frustrating to wait 10 years before you can depend on the "new" features being available.

Re: Mongrel2 Says, "Goodbye Python"

#75
post #40

Earlier quoted context omitted.

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 Py…

What's the point of ever producing newer versions of a language with new features (or, golly, even bug fixes ) if no one will ever use them because everyone has a 'lowest common denominator' mentality? More to the point, what is the process of changing the 'lowest common denominator' everyone's using?

Where do you get "no one will ever use them" from? We're talking about the darned config script which the guy first wrote in Python and then discovered that he would have to write the processing of that file in the lower version of Python than he blindly used or to use C. And he decided to use C, I still haven't read anywhere why exactly.

The platforms upgrades have their own dynamic. But you just shouldn't be surprised that somebody who has the server running for years doesn't want to install the latest Python only to process one config script. Not more not less.

Re: Mongrel2 Says, "Goodbye Python"

#76
Instead of inventing your own syntax, why didn't you use a portable syntax like XML, JSON, YAML, or better yet, libconfig[1]?

Please compare the libconfig test file to the mongrel configuration file:

http://www.hyperrealm.com/libconfig/test.cfg.txt

http://mongrel2.org/doc/tip/docs/manual/book.wiki#x1-190003....

The mongrel conf is a subset of libconfig; it doesn't use the more advanced features. Plus libconfig has bindings and versions of it in nearly every mainstream language.

[1]http://www.hyperrealm.com/libconfig/libconfig.html

Re: Mongrel2 Says, "Goodbye Python"

#77
post #18

Earlier quoted context omitted.

In the ancient days, stuff the OS relied on was in /usr/sbin and stuff that was "yours" was in /usr/local/bin (or /opt) and stuff that no-one was quite sure whose it was was in /usr/bin. And lo, peace and harmony did reign upon the face of Unix. And the sysadmin did lie down with the developer, and it was good. Who even knows how it works these days?

If there is one thing that ticks me off about modern unix it is that to install I end up having to install / upgrade half the rest of the system because of all the interdependencies between packages.

Exactly, and the baroqueness of package managers and the excentric configuration ideas of package writers are a symptom of that.

Re: Mongrel2 Says, "Goodbye Python"

#78
post #63

Earlier quoted context omitted.

In his particular case, he certainly was not missing the newer Python modules as he was able to write a "small" C-only replacement. That what he wrote in C would certainly be easier to write in Python 2.4 (or 2.2) Did you understand that he wrote the big C program just to process a small file with the syntax as in the following example (taken from his own file): main = Server( chroot="./", hosts = [mongrel2] ) settin…

I'm concerned with the general case of writing Python software. Zed's example perhaps could get by, but offers some minor annoyances. Distributing a framework like Django, on the other hand, when distros lag six years behind current Python, is a royal pain in the ass.

Django is in a very different situation because Python is central to all of its users, therefore it is reasonable to expect that they maintain a somewhat modern (released in the last 3 or 5 years, say) environment. When Python merely performs a subsidiary role, and your users may never use it themselves, it is far more important to support old versions.

Re: Mongrel2 Says, "Goodbye Python"

#79

what about dumping a local python install in $HOME/local/opt/mongrel-python if m2sh didn't find a version it likes? (yes, it's overkill)

This is an insane idea. I should not have to have a whole other version of python just to run a language independent web server. The choice Zed made is a great choice--all the functionality of the original python m2sh is present in the new, and there's nothing external to support, or dump somewhere else.

Re: Mongrel2 Says, "Goodbye Python"

#80
post #54

Earlier quoted context omitted.

> /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 O…

OS package-management (which can be considered "system" I guess) This is where I and the distro makers disagree. When I use synaptic to install the latest version of foobar, that is not in anyway "system" and foobar should not be dumped in the same directory as core system binaries. There should be a directory that contains everything core to the OS (like python 2.4), which was only updated by the OS updater routine…

We're getting into the debate of what constitutes a "core system", and I'm afraid there's as many answers to this question as there are debaters.

As far as the update routines are concerned - you can already have those, by self-selecting which packages do you want to update. As a pro-active measure, you can even lock down packages which should never be updated.

This seems to be fine to me - the advanced user has the means to control the update mechanism, and the casual user can just do an all-encompassing "apt-get upgrade" or an equivalent to make sure that she has all the security fixes.

Post reply on HN