6 ms·

Hi Zed, 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, "recen

Hi Zed, 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(?) http://packages.ubuntu.com/search?keywords=python http://packages.ubuntu.com/search?keywords=python 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.

Twisol 16y ago
Speaking as someone who knows practically nothing here, I think the issue is existing systems, not brand new systems. The barrier to updating an existing system becomes greater the more and the longer things depend on it.
- deleted 16y ago
  [deleted]
acqq 16y ago
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. Just because he downloaded to his computer whatever later version he likes he can't expect from all distros and all users to have exactly the same version across of all the currently running computers, it's more than unrealistic, it's simply impossible and always will be.
- ubernostrum 16y ago
  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.
- DannoHung 16y ago
  Maybe he's got a whole shit load of code for this thing? I was able to do a 1,000 line project that was 2.4 compatible just by looking at the 2.7 docs and avoiding anything that said it was introduced in 2.5 or later. Not fun, mind you, because I really would have rather been doing it in 2.7 or 3.1, but not impossible or even very hard.
- vidarh 16y ago
  That doesn't solve his second issue, though, of user not wanting to touch something that depends on Python. Rewriting in C fixed both.
  - acqq 16y ago
    The config file written in the subset of Python, the only thing users would have to touch, hasn't changed! (edit: see http://news.ycombinator.com/item?id=1712269 http://news.ycombinator.com/item?id=1712269) He just changed how the file is processed, by implementing in C what would be certainly easier to implement in Python 2.4, (edit: 2.2) the lowest version he mentions. If he insisted that users install Python 3.1 only to run his config script and they complained, I don't blame them. If he had users that haven't had Python at all, then I fully understand what he did. But then he can't blame distros and users for not having the latest and greatest Python version, it's just about the existence of Python on the target platform.
joelmichael 16y ago
Actually, the linked search shows 2.6.5 is the default Python package. The current version is "lucid".
Goladus 16y ago
Just from my personal experience: Red Hat Enterprise Linux 5.1 ships with Python 2.4.3. Solaris 10/4 does not ship with python at all. OpenCSW provides Python 2.6.5 but virtualenv doesn't seem to work with it.
zedshaw 16y ago
It was a fairly small chunk of Ubunutus that had problems with Python versions. I made sure m2sh-py worked with 2.5 (since I had an OSX around with 2.5) and I ran into a couple people with what was a recent Ubuntu, but with a 2.4 Python. Boggled the mind, but then again people do really weird stuff with their systems. If your application is going to depend on Python then you definitely need to evaluate who's using it. If it's like mongrel2 where sysadmins will need to install it on various Linux distros they might not control, then you're screwed. You'll need some kind of installer that hooks up the right kind of python in a safe area. If it's more like a Desktop application, then just get it to work on the latest of the desktop Linux variants, and then have it bomb out if they don't have the right python. People on Desktop systems are used to having to upgrade to use software.

Twisol 16y ago

Speaking as someone who knows practically nothing here, I think the issue is existing systems, not brand new systems. The barrier to updating an existing system becomes greater the more and the longer things depend on it.

deleted 16y ago
[deleted]

acqq 16y ago

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. Just because he downloaded to his computer whatever later version he likes he can't expect from all distros and all users to have exactly the same version across of all the currently running computers, it's more than unrealistic, it's simply impossible and always will be.

ubernostrum 16y ago
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.
DannoHung 16y ago
Maybe he's got a whole shit load of code for this thing? I was able to do a 1,000 line project that was 2.4 compatible just by looking at the 2.7 docs and avoiding anything that said it was introduced in 2.5 or later. Not fun, mind you, because I really would have rather been doing it in 2.7 or 3.1, but not impossible or even very hard.
vidarh 16y ago
That doesn't solve his second issue, though, of user not wanting to touch something that depends on Python. Rewriting in C fixed both.
- acqq 16y ago
  The config file written in the subset of Python, the only thing users would have to touch, hasn't changed! (edit: see http://news.ycombinator.com/item?id=1712269 http://news.ycombinator.com/item?id=1712269) He just changed how the file is processed, by implementing in C what would be certainly easier to implement in Python 2.4, (edit: 2.2) the lowest version he mentions. If he insisted that users install Python 3.1 only to run his config script and they complained, I don't blame them. If he had users that haven't had Python at all, then I fully understand what he did. But then he can't blame distros and users for not having the latest and greatest Python version, it's just about the existence of Python on the target platform.

joelmichael 16y ago

Actually, the linked search shows 2.6.5 is the default Python package. The current version is "lucid".

Goladus 16y ago

Just from my personal experience: Red Hat Enterprise Linux 5.1 ships with Python 2.4.3. Solaris 10/4 does not ship with python at all. OpenCSW provides Python 2.6.5 but virtualenv doesn't seem to work with it.

zedshaw 16y ago

It was a fairly small chunk of Ubunutus that had problems with Python versions. I made sure m2sh-py worked with 2.5 (since I had an OSX around with 2.5) and I ran into a couple people with what was a recent Ubuntu, but with a 2.4 Python. Boggled the mind, but then again people do really weird stuff with their systems. If your application is going to depend on Python then you definitely need to evaluate who's using it. If it's like mongrel2 where sysadmins will need to install it on various Linux distros they might not control, then you're screwed. You'll need some kind of installer that hooks up the right kind of python in a safe area. If it's more like a Desktop application, then just get it to work on the latest of the desktop Linux variants, and then have it bomb out if they don't have the right python. People on Desktop systems are used to having to upgrade to use software.