• Welcome to the new COTI server. We've moved the Citizens to a new server. Please let us know in the COTI Website issue forum if you find any problems.
  • We, the systems administration staff, apologize for this unexpected outage of the boards. We have resolved the root cause of the problem and there should be no further disruptions.

[Python] Customer Base?

egor045 ran into an issue based on Python 2.6 testing being different than 2.7 or 3.x. Something we need to consider; I know there are valid reasons for staying on 2.6 and earlier. This may be a simple fix but as a team I'd recommend we think about "What level of effort is spent on compatibility?"

My code works on Python 2.6 and 3.6. Of course, my code is really basic stuff and even with that I have to work to support py2 and py3.

Thoughts?

Properly supporting Python 2.5 (py2-old) or earlier takes effort. I don't believe any current Linux version has a package available for it, and the last binary release for Windows and Mac was in 2008. Getting 2.5 running on a modern system most likely means building it from source.

The issues I ran into with ehex were all to do with unit tests (the module code isn't very complicated). Python 2.6 introduced some changes that could impact module code, not just unit tests (e.g. a new JSON module, string formatting changes, context handlers).

In short, we'd end up supporting py2-old, py2 and py3, and building a development environment for py2-old will take some effort (not to mention building py2-old into a continuous integration pipeline). I'm happy to support py2-old on a best effort basis, but testing and issue repro will be difficult.
 
Won't be of much use to someone using Python 2.5. Old YouTube videos are where I go to get quick help.

Dunno, I've got pymongo running with python 2.6.6. The early videos say the underlying pyhon is minimal and you can actually use other languages. The "tests" look for results, not process.
 
I'd be shocked if any university still supported Python 2.5. I recommend any Traveller code repository be written/maintained using the latest version of whatever software it's being written in. When Python 3.4 came out, Python 3.0 was dumped by users. When Python 3.5 was released, users dumped Python 3.4.

Python 3.0, 3.4 and 3.5 are just too different from each other to remain compatible with each other. Just like what happened with Python 2.3, 2.5, and 2.7. Incompatible Pythons. And when 4.0 comes out, everything before it will become unusable. The Python "community" likes to change how Python works on a regular basis. The language is typically useful for about one college semester. Then a fresh new install is needed for it to be of any use for another semester.

If one version of Python is chosen and adhered to for writing repository code, no one will bother trying it out a year from now. It would need to be an EXE distrib for anyone to even be able to run the code. That's how fast Python changes. College students don't mind change because they do new installs of Python the first week of their semester. They are not loyal to any previous version.

I don't think any of them are archival programmers that like working with historic code, piecing back together lost libraries built around the same MSVC compiler so that imports work in OldPy.
 
Last edited:
Back
Top