Hacker News Reader

Comment by ubernostrum | Hacker News Reader

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?

View on HN

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]

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.

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.

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.

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

We can't drop Python 2.3 until 2012 (when RHEL4 reaches end-of-life).

However your replies started with your response "That's simply unacceptable" to my "I'd very much like to know why it wasn't easier for him to simply write in Python 2.4" You mentioned (in this context actually OT) Django much later.

And I still don't know if he tried adjusting his already existing Python code to simply be backwards compatible -- he never mentions that, neither why that would be a problem in his particular case.

Regarding Django, see the other replies here about side-by-side installations, it's more than reasonable if you have something big which always runs, but not reasonable for a small config script used once.

Sounds like he could've easily embedded python into his app instead.

"Big"? You keep using that word. I do not think it means what you think it means:

  $ rm src/parser.c src/cli.c src/lexer.c src/linenoise.c 
  $ wc -l src/*.c src/*.rl  148 src/ast.c
  646 src/commands.c
  267 src/config_file.c
   93 src/constants.c
   36 src/m2sh.c
   13 src/token.c
  186 src/cli.rl
  156 src/lexer.rl
 1545 total

That's dinky tiny, even with the linenoise and generated files it's only 4061 lines long, which isn't much at all.

My count is 4636 lines, and I can imagine much. much smaller Python 2.3 code:

    ast.c 115
    ast.h 45
    cli.c 482
    cli.h 31
    cli.rl 143
    commands.c 498
    commands.h 5
    config_file.c 193
    config_file.h 27
    constants.c 82
    constants.h 14
    lexer.c 360
    lexer.rl 121
    linenoise.c 433
    linenoise.h 40
    m2sh.c 27
    mimetypes.csql 851
    parser.c 1074
    parser.h 15
    parser.y 69
    token.c 11

No, most of that is generated from the .rl files or just SQL that's common to everything. Also, you'll want to throw in all of Storm and PyREPL if you want a real comparison.

Then again, 4600 lines of anything is tiny. You have a massively skewed view of "Big" and haven't disproven anything by finding 600 lines of cruft in one directory.

I fully agree with you that this is more than tiny for a C project, but it can be big compared to a small script. I also develop/maintain the projects measured in zipped megabytes (where I don't even have a wish to try to wait to count the lines!) I only compared it to some script solution.

You're right, 600 lines more or less are irrelevant. I just thought you're measuring something else as I saw the total of 1000 instead of 4000. Still it is all tiny for a real C program.

I also think that the C solution is more portable than the dependence on any version of Python. I also cross-compiled the code for 32 MB RAM mipsel platforms and I agree that only C dependencies are better than any script language dependencies (not counting shell, when it's carefully written).

But I actively use both Perl and Python so I'd still really like to know what was lacking in Python 2.2 or 2.3 or 2.4, of course only in case you already knew that you were to have any Python on the target computer. But then if you couldn't expect to have any Python, then the fact that distros still use older versions wasn't of much relevance.

Reply on news.ycombinator.com