I understand what Zed's saying here - particularly as I came to programming from a sys admin background.<p>Just like Perl before it, Python (and to some extent, Ruby if you use Puppet) are part of the OS (Linux OS or OS X that is).<p><i></i><i>Shit can and will break if you mess with your OS. </i><i></i><p>You never got this with PHP because people didn't use it in their OSs.<p>But there's a simple solution: not only does the Ministry of Packaging want you to use virtualenv, your OS maker does too.<p>The faster pip and virtualenv become standard the better.
This thread is a classic example of something that happens over and over.<p>Someone says something is hard to use.<p>1/3 of the responses agree.<p>1/3 of the responses disagree, say it's simple.<p>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.<p>This is usually a sign that there is some merit to the original assertion.
Instead of inventing your own syntax, why didn't you use a portable syntax like XML, JSON, YAML, or better yet, libconfig[1]?<p>Please compare the libconfig test file to the mongrel configuration file:<p><a href="http://www.hyperrealm.com/libconfig/test.cfg.txt" rel="nofollow">http://www.hyperrealm.com/libconfig/test.cfg.txt</a><p><a href="http://mongrel2.org/doc/tip/docs/manual/book.wiki#x1-190003.3" rel="nofollow">http://mongrel2.org/doc/tip/docs/manual/book.wiki#x1-190003....</a><p>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.<p>[1]<a href="http://www.hyperrealm.com/libconfig/libconfig.html" rel="nofollow">http://www.hyperrealm.com/libconfig/libconfig.html</a>
Hi Zed,<p>Can you please elaborate with some details about how "broken" python is on systems, and the situation with python 2.4? According to the article, "recent Ubuntu releases" had broken/deprecated python installations. A quick search reveals that python 2.5 has been shipping as the default "python" meta-package(?)<p><a href="http://packages.ubuntu.com/search?keywords=python" rel="nofollow">http://packages.ubuntu.com/search?keywords=python</a><p>Can you also please elaborate any "features" that the install was missing - are these specific modules ?(I think python's sqlite3 is missing by default on Ubuntu. I'm not too sure.) I'm not questioning you or anything, I'm just slightly concerned as we had plans to ship a Python application, and when someone experienced enough has a valid complaint, it makes sense to understand the basis behind that.
I definitely would have used Lua in this situation. The Lua runtime is tiny and lightweight. You can write pretty nice config files in Lua which look pretty similar to Zed's too.<p><a href="http://windrealm.com/tutorials/reading-a-lua-configuration-file-from-c.php" rel="nofollow">http://windrealm.com/tutorials/reading-a-lua-configuration-f...</a>
This is a major problem. PETSc uses Python for configuration and we have to be careful not to use any features requiring >2.3. The last release (this spring) required 2.2 because RHEL3 is still supported (in production phase 3, see <a href="http://www.redhat.com/security/updates/errata/" rel="nofollow">http://www.redhat.com/security/updates/errata/</a>) until Oct 31, 2010. Python is easy to install, but it's a lot to ask of users when they just want to get your software up and running. Note that RHEL4 sees end of life Feb 29, 2012 and RHEL5 not until Mar 31, 2014. So Python-2.4 support will have to live for a very long time.<p>I hate this, but don't see a decent alternative. Many of our users are building in batch environments of varying ages and just want to get their science done. Shell/bash is not very portable, it would be painful to write all the configuration in C (and confusing because people would need to both native compilers and cross-compilers).
He's absolutely right. I have come to the conclusion that we must do one thing: Stop sharing. Shared libraries and language runtimes are a relic of the past when memory and storage were orders of magnitude smaller. Bundle all dependencies and throw out the package managers!
Completely agree. The Linux distros (CentOS is the one I work with most, not out of choice) have antiquated Python versions.<p>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 things back.<p>I mean WTF does yum still require ye olde Python 2.4 ?
I'm not sure why he concerns himself with old distros. Are they the customers for Mongrel2? The description on the website emphasizes <i>modern</i> web technologies.<p>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 willing to compile their own necessary bleeding edge dependencies, and probably have a generally up-to-date distro preference (like Ubuntu).<p>Even the latest Debian stable, a notoriously conservative distribution, which is a year and a half old and due to be upgraded soon, uses Python 2.6. I'm not sure it's reasonable to support much past that.
FYI - Fedora 13 shipped with Python 2.6, Fedora 14 is going to ship with Python 2.7 and 3.1 in parallel. Not every distribution ships ancient versions.<p>I also recommend using virtualenv and pip, these tools make it much easier to create an easily reproducable Python environment.
I have found that the one system that doesn't give me any trouble running Python is Ubuntu. I'm using Ubuntu Server 10.4, specifically, which is the latest LTS (Long Term Support) version.<p>Ubuntu 10.4 has Python 2.6 but I wanted Python 2.7 (which is the LAST 2.x version). So here's what I did: I installed all common dependencies (such as OpenSSL with "apt-get build-dep python2.6", since they're all the same for Python 2.7. Then I installed Python 2.7 with "make altinstall" without disrupting the system's base 2.6 install. Then, I got pip and virtualenv installed.<p>I've never been happier doing Python development. pip never failed to install a single package I needed, and Python 2.7 is fast and gives me a safe path of migration towards Python 3, whenever the whole byte/str issue in the network libraries (or at least WSGI) is 'resolved'.
Zed Should have used Lua(the <i>entire</i> lua source distro weighs couple of hundred <i>kilo</i> bytes). Lua is superb embedded language and even better configuration language.<p>No one needs to know it is Lua, (which also happens to be a marketing problem for Lua, heh).<p>His decision not to use Lua the second time around is perplexing because he is not averse to reusing third-party libraries and he is already using the code from Lua for URL pattern matching (IIRC).
So what can we learn from this for designing future languages?<p>Make it standard idiom to have every file of code declare its version-dialect at the top?<p>Default to throwing warning if interpreter and code version-dialect mismatch?<p>Have the main code interpreter called by all code files simply be a host for routing code to the correct dialect-version interpreter? Perhaps include an optional "slim" download where the host only includes the interpreter for one dialect-version, but make this non-default\opt-in.
Including Gentoo is wrong. Gentoo uses a slotted ebuild for python. You can have many concurrent versions running. Not only that, but the latest portage works fine on the latest 2.6 release of python. If you don't want to learn how to use your OS, pick a different one. I hear that Macs "Just Work".
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.<p>In short: "...have killed Python" is a hyperbole for saying "I was tired to hear people nagging about dependency on Python". Still, it's a very good thing what Shaw did.
Shouldn't python just be a library dependency like any other? I was hoping the problem of libraries with different versions was solved somehow. Apparently not :-(
Doesn't every non-stale language suffer from the same thing? So either your choices are a) using language that hasn't evolved or b) using an old version of language which has evolved. I'm not sure that alternative b is that much worse than a.
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".<p>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.<p>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 <i>has</i> to work". I won't <i>touch</i> the system parts.
<i>Hilariously enough, I took the time to make sure the new config file format for m2sh was nearly perfectly backwards compatible with the old file. This is pretty funny because I predict nobody will blink an eye at the config file, even though it's basically Python.</i><p>This is an interesting point, especially given the amount of code (relatively small) actually needed to parse the subset of Python the config format uses. That said, the subset is fairly "generic scripting language" since there aren't any declarations, only assignments, lists, etc (at least at a cursory overview).
Python needs something like the "Go PHP 5" campaign (which pressured projects/hosting companies to drop support of PHP 4: <a href="http://gophp5.org/" rel="nofollow">http://gophp5.org/</a>).
All in all, the C code looks pretty good. I browsed around in a few files to see whether he used strn* or strl*, but it turns out he uses a proper string library instead.<p>Very rare, but very nice to see!
After several issues with Python, Lisp, Haskell, etc., I'm coming around to the philosophy of just generating C or C++ code from Python or Lisp.<p>Productivity is a function of (familiarity, language, libraries, configuration, runtime). Other languages may be great due to (language, library), but configuration can be a show-stopper. Especially since most devs seem to see library/wrapper writing as a chance to pull in all their favourite cruft dependencies.
If "python for linux sucks" I don't know what to say about python for mac or windows.<p>I have a lot of python programs that use OpenGL, matplotlib, and a lot other libraries. No problem or very little problems on Linux.<p>On mac 10.6 you have a limited python version and is very difficult to add matplotlib and other libs, with Windows is a similar pain in the ass, unless you buy it from a commercial scientific distro.
It sounds like the correct solution to this problem is a package maintainer for the Mongrel2 package on different OSs. The package maintainers job is to make sure a package builds and runs on a given OS. The reason we have them at all is that it is often a difficult job. Mongrol2 systems like a system application, no?
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.<p>If all would be fine, perhaps my network appliance would be shipped with mongrel2 which would be fantastic.
I would be very curious to learn why you had not packaged Mongler2 with cx_freeze, which allows you to provide your own copy of Python with any modules you may want to add to it.<p>Doing so would have made your software immune to the broken Python installations.
Every unix based OS deals with package resolution in a stupid way. Didn't the old lisp machines before Linux, FreeBSD, etc solve this with self contained state in a single object? Everything old and solved is the new and hard problem.
It's sad and ironic (for Python) that Zed actually had to switch from Python to C to make Mongrel more portable.<p>Disclaimer: I love Python, but I hate that anything but the most trivial code won't run across all versions.
Narcissism and self-promotion as usual.<p>People who have any trouble with a system perl or python or java are shipping their own versions within the package.<p>Sap Bussiness Object, for example, comes with its own perl 5.004 and Sun JDK 1.4.<p>It is also possible to provide an up-to-date package for most used OSes. You cannot replace system's default python interpreter, because to much things in distros are depended on it, put it could be /opt/python<p>btw, it is only Debian-based systems and RHEL who are lagging behind. Fedora is always up to date.<p>I'm considering this post as just a flame-generator. There is no problem at all.
Is anybody using Google's <a href="http://en.wikipedia.org/wiki/Go_%28programming_language%29" rel="nofollow">http://en.wikipedia.org/wiki/Go_%28programming_language%29</a>
Python brought this on itself by having no respect for compatibility between versions.<p>There's really no such thing as the Python language, only "Python 2.2", "Python 2.4", "Python 3". If you want to run Python scripts, you need to have three or four different Python runtimes installed, and that's asking a lot of both the distros and of users who need to keep everything straight, and probably even hack the #! at the beginning of scripts so that they work correctly.