EOL Python 2.7 issues

[shkhln]

Heh, running a Python program usually turns into a wild goose chase for a whole slew of dependencies. By the time I have managed to capture them all I am too exhausted to execute the actual program XD

Yes, that's one very compelling reason to avoid anything Pythonic.

 

[Crivens]

The fun starts when you do medical software and can't produce statically linked binaries. The worst is then when you have to deal with code that is loaded from 'somewhere else'. Have fun with certification and/or when something goes wrong.

 

[20-100-2fe]

I am not a fan of dependency focused languages. NodeJS, Python and (unfortunately) Rust are the worst offenders!

I've had the occasion to discover the sado-masochistic delights of NodeJS-based frameworks (Angular and React)...

The only sensible explanation I found to the advent of such a mess is that IT has reached full maturity and the only way to achieve continued economic growth is through self-destruction and re-creation cycles. :/

 

[ralphbsz]

The fun starts when you do medical software and can't produce statically linked binaries.

You can produce statically linked binaries of python code. It is not easy, and it is not efficient for small programs, but it is certainly possible.

The worst is then when you have to deal with code that is loaded from 'somewhere else'.

That problem is the same in any language. If you use code in a certified product that comes from somewhere else, you need to worry about the certification of it. Whether you #include some <foo.h> files in C++ and then link against foo.lib, or whether you import foo.py makes in practice little difference.

One interesting difference is: In C++, you nearly always have a make file, and that make file makes the dependencies very explicit (although it is a bit hard to parse). In Java or Python you typically do not need makefiles, so dependencies need to be inferred from the behavior of the code at run time. And scripting languages where code can be dynamically generated make this non-obvious. The solution to this is either programming discipline (like a coding rule that says: all imports will be at the top of the file, before any executable code), or run the code in a specialized execution environment that requires a makefile-like system.

So I know it is possible to create statically linked python programs with fully explicit dependencies. One could wonder whether this is a good idea, or whether it is antithetical to the design spirit of the language, but that's a question of personal taste.

 

[ralphbsz]

Sinking deeper and deeper in this EOL rabbit hole I noticed that things are just not true about the statements on python3statement.org. The statement is that Python 3 is needed “to simplify our code and take advantage of the many new features”. First of all: new features can be backported to Python 2.7. And modules improved in Python 3 can also be improved in Python 2.7. The new-features-statement about Python 3 is false.

Nonsense. You are looking at the wrong thing. Look at the viewpoint of Python developers: Anytime they backport something into Python2, they have to do extra work, and they end up with roughly twice as much code or code churn: the same feature has to be there twice. This is the exact opposite of simplicity. Keeping Python2 around and updated adds complexity, and it adds extra work. The Python developers have decided that the extra work is not worth it TO THEM. Therefore they will stop doing it. And I fully support them, because that decision is not capricious, it is sensible from an engineering point of view, and it had sufficient warning.

The print function is the most widely known change in Python 3. If you look in to the print function the code is not made more simple in Python 3.

First, you are looking at it again from the wrong point of view. This is mostly about the complexity of the Python infrastructure (the thing the python developers worry about), not the complexity of your code.

Second:

In Python 3 you have to code more to get the same output.
...
Print in Python 2:
code: print 'Python', python_version()
...
Print in Python 3:
code: print('Python', python_version())

Other than one traililng closing paren, it is the same amount of code. You replaced one space (the one between the keyword "print" and the argument list) with an opening paren, which doesn't change either the complexity nor the amount of code (if measured in characters or lines), and you had to add one closing paren, which is a tiny addition to the amount of code.

But think about what you get: a simpler language, with one fewer keywords. From a developer viewpoint, every keyword adds having to think about the syntax, having to consider special cases (like what does a trailing comma mean, how do line breaks in parameter lists work). From a python implementor viewpoint, one fewer keyword simplifies the parser considerably.

Furthermore: that particular change (of adding parens around the argument list of print) actually causes developers nearly no work, since 2to3 handles it perfectly. The real work of the Python3 transition is elsewhere, for example in the bytes versus strings area (which was a very good change and way overdue, but one that can not be handled automatically).

What a fool I must be to believe that live is simpler now with Python 3.

You want simple? BASIC still exists. You want productive?

 

[Juronski]

The Python developers have decided that the extra work is not worth it TO THEM.

That is why I migrate to Tauthon as much I can. Tauthon does care about its users. Tauthon does more than Python does for more users with different needs.

 

[20-100-2fe]

In Java or Python you typically do not need makefiles, so dependencies need to be inferred from the behavior of the code at run time.

Maybe you forgot to append 'Script' to Java?

In Java, you have Maven, Gradle and other similar tools to describe your project structure, including dependencies, and your have a central repository for open source libraries. Furthermore, Java is a strongly typed language, which significantly reduces developer stress factors.

JavaScript (now ECMAscript) tends to follow the same direction with package.json to describe project structure and dependencies, and has its own central repository but the language remains weakly typed (despite TypeScript, eslint, etc), so no bug can be fixed before run time (provided you test all execution paths - remember JavaScript is used to create user interfaces).

Moreover, JavaScript is a fake object-oriented language (you even sometimes have to set the value of 'this' yourself!!!), frameworks are very unstable and there is no standard class library, so a simple hello-world.js causes the download of 30,000+ small dependencies weighing around 200 MB...
There is a reason for all this, though: guess who steers the ECMAscript standard evolutions?

 

[takeda]

Juronski, I found this thread (and others) you created about Python 2.7 EOL, if instead of complaining you would just put that effort into migrating your app, you most likely would be done by now.

 

[Nicola Mingotti]

Juronski I kind of undertand you frustration. A few days ago I wanted to install Python on a bit dated OpenBSD box (2-3 years). The fastest way was simply to download and compile the source. Which I did in 30 minutes on a PCEngines Alix2 (a very small box).

So, if you don't need a gazillion packages just getting the Python2.X source and compile it maybe the least effort solution.

Making a port is not too difficult, you may get your first one in a time horizon of 1-3 days, there are several factors that may slow you down. Compliing Python2.X would probably be much much faster.

(extra. for fun). It is well known that most languages die by the cancer of semicolons. They start lean and slim to become fat monsters over time. Python is no exception.
young python: print "hello world"
adult python: print("hello world")

(extra2) Some years ago I red that Tanenbaum favourite language is AWK. I was really surprised. When T. was asked the reason for that choice the first answer was: "AWK is not going to change anymore".

 

[sidetone]

Redoing something often makes it more efficient. When something is piled on, because of new features, it has to have a lot to make up for something that can be made simpler. It's like math or a city that was not planned well enough into the future from the beginning.

Python 2.7's license is Python Software Foundation (PSF), which is BSD like, so it could be maintained by another party for security, to be limited to older programs. As others suggest, would that be worth it or how practical is that? Maybe for maintaining older programs only, rather than redoing them. According to the makefile, the port's expiration is at the end of this year.

I like when there are fewer versions of a dependency, so I wouldn't have to have so many. But they'll need a newer one with newer features or improvements, so there will still be a few versions, which isn't so bad.

 

[kpedersen]

Some years ago I red that Tanenbaum favourite language is AWK. I was really surprised. When T. was asked the reason for that choice the first answer was: "AWK is not going to change anymore".

This is so true! And guaranteed to be in base on any POSIX OS. Because of this I do most of my scripting tasks in it these days (i.e mounting USB drives, xrandr output, wifi).

It's biggest bonus is that it is *not* extensible. You will never be suggested "oh, just download this random package from PIP, NPM, CPAN to do that basic task".

It is like a mini scriptable version of C. Stable and as boring as hell . It is very underrated.

 

[CraigHB]

I didn't know awk was that powerful, going to have to learn more about it. I use it here and there for single line stuff in shell scripts, but never looked into it that heavily.

 

[Deleted member 63539]

Build fine for me:

$ ./tauthon --version
Python 2.8.2+

The problem is contacting ports maintainers to replace python2 with it. Core developers have nothing to do with it as python (any versions) is not even in base.

 

[SirDice]

The problem is contacting ports maintainers to replace python2 with it.

It needs to be added to the ports tree first. You cannot use dependencies that aren't in the ports tree.