If the question is "Do a significant number of users run into problems with a piece of software," then the consensus is absolutely relevant.
The question isn't whether there is a problem but whether there is a solution. The virtualenv/pip people seem to think so.
> The virtualenv/pip people seem to think so.
No. Unless those people are morons, but the guys who actually code them know they're tools for python developers, and maybe for sysadmins of python solutions. Pip and virtualenv for software using Python as a config file format? not a good idea.
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…
Well, it's a matter of opinion, but I would define "all versions" as versions sharing a major number, i.e. code targeting 2.2 should run on anything starting with 2. As for trivial code, just look at the string operations part of the documentation and search for "new in" and "changed in". My connection is rather slow right now, to the point that the page I mentioned is still loading, so I won't look for more examples, but string processing should IMO be trivial parts of any language. Don't get me wrong, the changes have mostly been useful ones for 2.x versions, but I have been caught testing scripts on my own box that end up not working after deploying. Since then, I have been, as you say, more careful, but I feel I have a valid gripe when I expect string and io operations to be consistent across major versions without having to do a fine print and version check. :)
> 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.
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. Your impression is correct. Perl is a more mature platform than Python, and backwards compatibility is taken more seriously. The latest Perl 5.12 release can still run most of the test suite for Perl 1 released back in 1987. That and its wide availability and portability make it…
> Perl is a more mature platform than Python, and backwards compatibility is taken more seriously.
That's a silly thing to say w/r/t Python 2.x. What makes people’s Python 2.5 code not run on Python 2.2 (or 1.x) is that new features were added in the mean time. New very shiny happy features that make life a lot easier for developers. Almost all python code continues to work from one version to the next, and it’s easy to write code that will work on all the versions from 2.2 to the present (or whatever), as long as you’re willing to avoid all the nifty stuff.
Basically by “backwards compatibility“ you mean “forward compatibility”.
There's a lot of equivalent old warts in Perl that haven't been fixed This is the crux of the issue. Serious language users (especially the ones writing the new libraries that add significant value to your platform) want the warts fixed to make the environment pleasant to work in. Meanwhile, most casual users are desperate for backward compatibility because it makes distribution easier. I actually prefer Python's cho…
I should have said: They haven't been fixed by default . Perl is also moving forward, it's just doing so differently than Python. Python has major releases like 2.6 and 3.0 where they explicitly break old code in the default installation. Perl however doesn't break any of the old warts by default, but developers can easily do so by importing modules like Moose and perl5i in their own code. See http://search.cpan.org/…
You can write code that runs on 2.4, yes. But you miss quite a few useful features of more recent Pythons by doing so (context managers, for example, are a big deal, as are several of the newer standard-library modules). The same thing used to happen with Python 2.3; you could write 2.3-compatible code, but it meant no decorators, no generators, etc. Python has these useful features and has had them for years; why is…
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…
Sounds like he could've easily embedded python into his app instead.
I understand what Zed's saying here - particularly as I came to programming from a sys admin background. 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). Shit can and will break if you mess with your OS. You never got this with PHP because people didn't use it in their OSs. But there's a simple solution: not only does the Ministry of Packagin…
Shit can and will break if you mess with your OS. Updating a program I use should never constitute "messing" with my OS, it should constitute "using". Why should I as an OS user have to constantly worry about upsetting the OS maker? Why should I have to jump through obscure hoops just to install some software without breaking my OS? Wouldn't a better solution be for the OS makers to wall off their magic python behind…
Python brought this on itself by having no respect for compatibility between versions. 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…
Mercurial runs unchanged on 2.4 to 2.7, and it's not a trivial little piece of software.
Pretty much the only thing you need to do to make your Python code run on 2.x+ is "don't use features released after 2.x".
Zed Should have used Lua(the entire lua source distro weighs couple of hundred kilo bytes). Lua is superb embedded language and even better configuration language.
No one needs to know it is Lua, (which also happens to be a marketing problem for Lua, heh).
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).
Zed Should have used Lua(the entire lua source distro weighs couple of hundred kilo bytes). Lua is superb embedded language and even better configuration language. No one needs to know it is Lua, (which also happens to be a marketing problem for Lua, heh). 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 Lu…
Well, he said he made the new parser read the unchanged config file format. Presumably, lua would have needed a change of syntax.
Also possibly he decided to step outside the language wars because it's less hassle to write your own parser than wrangle language partisans.
Except no one installs ActiveState. For most, most of the market, the RedHat supplied version of python is python.
Does RedHat still have that much of a market share in linux to demand such? I guess I am out of the loop, but I hear way more about ubuntu these days than RedHat...
The US Govt can use Redhat, but not Ubuntu (Ubuntu hasn't been Common Criteria / EAL tested).
That's a pretty huge market right there.