22 ms·

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

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 -- they sat on 1.5 forever). That's simply unacceptable, and creates endless headaches for people who want to distribute software written in Python.

acqq 16y ago
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.
- ubernostrum 16y ago
  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 it acceptable to say that it will be 5-10 years before we can reliably use anything new?
  - acqq 16y ago
    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] ) settings = {"zeromq.threads": 1} mimetypes = {".txt": "text/plain"} servers = [main]
    - ubernostrum 16y ago
      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.
      - jedbrown 16y ago
        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.
        ubernostrum 16y ago
        I mentioned Django as a counterexample; the conversation seemed to be heading toward using the single specific example of Mongrel to demonstrate that there either is not a problem here or that it's not particularly serious. Meanwhile, anyone who depends on Python for much more than a config-file parser knows what a genuine and large issue this is, and that "just write to the lowest common denominator" is not really a reasonable solution.
        jedbrown 16y ago
        My point is that the lowest common denominator is higher for users of something like Django because Python is a central component of what they do, thus it's reasonable to assume that they are not using an 8-year old Python environment.
        ubernostrum 16y ago
        Tell that to the many, many people I know who are using Django on RHEL. There's a reason why we just (as of Django 1.2) got around to dropping Python 2.3 support...
- mgkimsal 16y ago
  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?
  - acqq 16y ago
    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.
avar 16y ago
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=23b093ee087e9 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.
- jedbrown 16y ago
  > 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.
  - berntb 16y ago
    This backwards compatibility is a conscious decision. And it is argued about. To find a bit to read about that, Google e.g. for darkpan. (It is probably one reason why Perl 5 is so extensible.)
    - acqq 16y ago
      Thanks berntb! That's a perfect tip for a new submission: http://news.ycombinator.com/item?id=1712404 http://news.ycombinator.com/item?id=1712404 The DarkPAN matters "There is currently some FUD going about in some parts of the Perl community about why we should break Perl 5 backwards compatibility. A short blog entry, schmarkpan, is a good example of the trend: loud, noisy, but clueless and devoid of any content."
  - avar 16y ago
eddieplan9 16y ago
So after complaining that he could not use new language features that appeared six years ago, he went back and rewrote the whole thing using a different language whose syntax is much much more than six years ago. I guess he must have found these must-have Python 2.5 language features that are so important and desirable in C. And by the way, don't use new GCC features, because some ancient GCC versions will be supported by Red Hat until 2020. For God's sake, support != enforce
- zedshaw 16y ago
  It was users complaining, not me. I had no problem with Python, but all of the non-python users (the users of one of the 9 other languages Mongrel2 supports) hated Python for these reasons.
  - acqq 16y ago
    Did you by any chance have the users who haven't had any Python installed?

acqq 16y ago

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.

ubernostrum 16y ago
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 it acceptable to say that it will be 5-10 years before we can reliably use anything new?
- acqq 16y ago
  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] ) settings = {"zeromq.threads": 1} mimetypes = {".txt": "text/plain"} servers = [main]
  - ubernostrum 16y ago
    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.
    - jedbrown 16y ago
      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.
      - ubernostrum 16y ago
        I mentioned Django as a counterexample; the conversation seemed to be heading toward using the single specific example of Mongrel to demonstrate that there either is not a problem here or that it's not particularly serious. Meanwhile, anyone who depends on Python for much more than a config-file parser knows what a genuine and large issue this is, and that "just write to the lowest common denominator" is not really a reasonable solution.
        jedbrown 16y ago
        My point is that the lowest common denominator is higher for users of something like Django because Python is a central component of what they do, thus it's reasonable to assume that they are not using an 8-year old Python environment.
        ubernostrum 16y ago
        Tell that to the many, many people I know who are using Django on RHEL. There's a reason why we just (as of Django 1.2) got around to dropping Python 2.3 support...
mgkimsal 16y ago
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?
- acqq 16y ago
  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.

avar 16y ago

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=23b093ee087e9 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.

jedbrown 16y ago
> 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.
- berntb 16y ago
  This backwards compatibility is a conscious decision. And it is argued about. To find a bit to read about that, Google e.g. for darkpan. (It is probably one reason why Perl 5 is so extensible.)
  - acqq 16y ago
    Thanks berntb! That's a perfect tip for a new submission: http://news.ycombinator.com/item?id=1712404 http://news.ycombinator.com/item?id=1712404 The DarkPAN matters "There is currently some FUD going about in some parts of the Perl community about why we should break Perl 5 backwards compatibility. A short blog entry, schmarkpan, is a good example of the trend: loud, noisy, but clueless and devoid of any content."
- avar 16y ago

eddieplan9 16y ago

So after complaining that he could not use new language features that appeared six years ago, he went back and rewrote the whole thing using a different language whose syntax is much much more than six years ago. I guess he must have found these must-have Python 2.5 language features that are so important and desirable in C. And by the way, don't use new GCC features, because some ancient GCC versions will be supported by Red Hat until 2020. For God's sake, support != enforce

zedshaw 16y ago
It was users complaining, not me. I had no problem with Python, but all of the non-python users (the users of one of the 9 other languages Mongrel2 supports) hated Python for these reasons.
- acqq 16y ago
  Did you by any chance have the users who haven't had any Python installed?