With less than 200 days until Python 2 end of life just an update on the transitions on other platforms and a question...

On Windows, check out at 9 minutes into https://pythonbytes.fm/episodes/show/130/python.exe-now-shipping-with-windows-10 -- Hint: Very impressive!

On the Mac, the next release of XCode will bundle Python 3 instead of Python 2 https://developer.apple.com/documentation/xcode_release_notes/xcode_11_beta_release_notes

The question... Would any of you be distressed if Python 2 compatibility disappeared from a future version of Pythonista? If so, why?!?

@ccc Hi, it doesn't worry me too much because I think I will continue to use my personal Python 2 scientific scripts (for work and hobby) that usually don't require any Python 3 features, but I have often asked myself some questions that I have never been able to answer.

Really I never understood why it was useful to develop a different version of Python (why create a new big version of Python, from 2 to 3, instead to give Python 2 the same useful features of Python 3? maybe too complicated the upgrade of the existing Python 2 and more easy the develompment from zero of a new programming language that is Python 3?).

Has Python 3 started to be developed due to several requests by users about usage of Python 2 programming language? I mean, what had prompted developers to start creating Python 3 instead of upgrading Python 2 with the additions (new/different features) requested by users that now are implemented in Python 3?

Was it not enough to modify Python 2 with the purpose of interpreting the new Python 3 syntax, in order to have Python 2 updated with the most interesting things provided for Python 3?

And apart from some syntax differences between Python 2 and 3 (for example the different syntax of the "print" function), what features are really more efficient in Python 3 to justify the abandonment of Python 2, and the consequent abandonment of innumerable Python 2 libraries which are no longer updated to Python 3 by the developers?

Bye

@ccc I also oppose dropping python 2 from pythoniststa 3 for several reasons.
1. I still have a huge amount of py2 code which i do not want to port
2. I do not want to be forced to adapt py3. While i am slowly, but steadily switching over to py2 and py3 compatible source and later to only py3, i want to do this on my own pace and not suddenly because one of my most used apps dropped support for py2.
3. Pythonista 3 is advertised on the appstore as being both py2 and py3 compatible. Some people, including me, probably would not have bought pythonista3 if it did not support py2. Before @omz announced that pythonista3 would support both versions, I had not even considered buying pythonista3. Chances are, that a few people may be outraged if py2 was dropped. You may argue that they do not have to update, but maybe some people have automatic updates on and will know py2 was dropped before it is too late. And i do not want to see that shitstorm.
4. Why should we even drop py2? Just because it is officialy EOL does not mean we have to drop support for py2. While it would be nice if we would have a faster start-up time, a simple do not load py2/py3 switch would also do the job.
5. I sometimes work on py2 code on my iPhone and like it.
6. Py3 is an abomination which i will fight until my very last breath.

Well, in the end it is the decision of @omz .

@bennr01, disable switch sounds like a sensible idea.

https://datawhatnow.com/things-you-are-probably-not-using-in-python-3-but-should

@ccc Hi, interesting thank you for sharing it, but I keep wondering why it was necessary to create Python 3 instead of implementing all these new features (like "f-strings", "Pathlib", "Type hinting" and others listed in the site you shared) in Python 2 with a progressive numbering in its versions (for example: in Python 2.7.15 implemented "f-strings", in Python 2.7.16 implemented "Pathlib" and "Type hinting", and so on...).

I suppose that all the new features in Python 3 could be implemented also in Python 2 if Python 2 had the same low level features of Python 3. I mean: if "f-strings", to work properly, needs some new low level features implemented only in Python 3 core, why not implement this low level feature also in Python 2 in order to have a Python 2 capable to use "f-strings" and also the "old" format?

In this way no need to completely change a full programming language and no problems when people want to run with Python some python 2 or 3 scripts or entire libraries. Python users could have had a single Python distribution, updated progressively, with all the new features that we find only in Python 3.

With the hypothetical single Python distribution, user could execute directly, for example, a script where somewhere in the source there are some pieces of code that use "f-strings" and somewhere else other pieces of code that use the standard format version, without problems (the interpreter of the single Python distribution would be able to interpret/understand, in the same source script/library, the code with "f-strings" and the code with format without syntax errors).

Thank you for sharing
Bye

Python 3 was created to overhaul Unicode support, that's it.
https://www.google.com/amp/s/snarky.ca/why-python-3-exists/amp/

Every other new feature could have been implemented in 2.x ( as many have been backported, including f strings).

Arguably Unicode was not broken in 2.x, just took conscious effort that most people didn't bother with.

@JonB Hi, thank you for info, so synthesizing Python 3 was born for Unicode support and Python 2 will die because Python 3 exists, in order to avoid redundancy.

Unfortunately I'm not very expert in programming but it is a world that fascinates me so I ask you what does it mean (in link you posted ".../why-python-3-exists/amp/") that a file containing 'abcd' in Python 3 is a string and in Python 2 can be both a text file (like for Python 3) and a binary file (with bytes) that represents 97, 98, 99, 100.

Thanks
Bye

The ASCII character for the integer 99 is 'a'. In C, and other languages, a char is synonymous with an uint8, and you could represent it either as the numeric value or the quoted character.

In a recent CppCast interview, Herb Sutter describes how he would change C/C++ types if he could go back in time. This is almost exactly how things were changed from Python 2 to Python 3 (str split into Unicode strings and byte arrays)

I would be distressed. I use a file transfer program that runs only under Python 2, and so I have this line at the top of the file:

!/usr/bin/python2

at the top of the file.

Sure, I could take some time and rewrite the file transfer program for Python 3, although given that I often want to transfer ASCII, that would take time away from the actual programming I want to do - and I barely have enough time for that. I want to work on my primary application, not on tools.

I also wrote python 2 programs for many years, and I like being able to transfer them and just run them. That's one reason I purchased Pythonista 2 separately before I purchased Pythonista 3. (Or whatever the official product names are - you get the idea).

I don't care if Python 2 is never improved, but I do hope it never goes away.

@technoway, ”never” sounds like a long time, especially if we consider that the next major security vulnerability discovered in Python 2 will not be fixed.

But, considering the mostly small, offline and transient hobby projects we build in Pythonista, with no budget for refactoring, being able to take advantage of all the IP in old projects is certainly an important feature.

@ccc I too am absolutely oppose to the removal of Python 2 support from future releases of Pythonista. I couldn’t care less about the innumerable functions and syntaxes being constantly added to python or any other language for that matter. I implement models and solve problems using whatever language that is available in a specific system using the most basic construct possible. Any complex program can be reduced to statement, decision and iteration. If complexity arises, unless it is really extensive or not directly related to my code (such as a GUI), I tend to handle it myself and my way. It is nice to have sympy preinstalled but I would do fine without it. That said, I still mainly use “print” as a statement instead of a function and so many other concepts that might be evolving endlessly within the Python framework that I do not care about. It is therefore easier to place the shebang “#!python2” on top my scripts instead of unnecessarily correcting codes that already work.

@JonB Hi, thank you for your reply, and thanks to everyone for the comments about this interesting matter (Python 2 or not Python 2...).

I personally feel lucky because in case there will be no Python 2 in Pythonista 3 in future, on my iphone I still have Pythonista 2 which I purchased a few years ago, so I could virtually use my scripts written in Python 2 forever.

I am sorry for those who do not have Pythonista 2, and I am sad that Apple does not allow user to install more versions of the same application on idevices (the only way is to use TestFlight but for a limited time); if Apple would allow this, there would be not problems because any user could decide to keep the current version of Pythonista 3 (which includes Python 2 and Python 3) for running scripts written in Python 2 and install also an updated version of Pythonista with only Python 3 and new and interesting features.

Thanks
Bye

@Matteo, your post gives the impression that Python 2 will be removed from Pythonista, even though there is no information that that would happen. @ccc just started a (valuable) user community discussion on the topic.

To summarize all of the above, it would seem sensible if future versions of Pythonista included current Python 2 support, but as an opt-in option to avoid security concerns.

@mikael Hi, yes you are right :-) , but also who has Pythonista 2 has no problems in any case, maybe only security problems, since Python 2.7.12 (inside Pythonista 2, that will be not update anymore) probably doesn't have all the security problems already solved in Python 2.7.16.
I'm agree with you that the best thing is to have Pythonista with only one core (with Python 3, because it is the future...) and with site-packages folder with only libraries for it and not for Python 2 (in order to avoid taking up space with repeated libraries for both) but also with a Python 2 core available only as an option in Pythonista settings.

Regards
Bye

@mikael I am not sure that I understand your point. Are you asserting that Python 2 is so “unsafe” that even if you are not using it through a shebang or otherwise, a remote rogue process can bypass IOS, guess that Python 2 is installed within Python 3, access the Pythonista sandbox and execute a script that will make your device explode or some other nefarious aim? If that is the case we should all uninstall any version of Pythonista at once. Otherwise, let the system stand as it is in all future releases without any extra complexity for the user and @OMZ.

I believe that @mikael's words were very similar to the messages from the CPython core development team: https://twitter.com/raymondh/status/1080961135493316608 No one is implying that your iPad will blow up in your hands but security issues can be real nevertheless.

@ccc With all due respect to you and @mikael, there is no way that Python 2 can be an issue if it is not activated. Even a file containing a virus is harmless if it is not executed. Fifteen years ago, I used to be fascinated by “Nimda” when it just came out and made all that damage. I used to open it (not execute it) and examine its object code without any problem. If Python 2 pauses some risk if it just sits within some Python 3 directory then Python 3 is more dangerous than its older sibling. I am just advocating to uphold the traditional Python 3 distribution model (with Python 2 included) and let a user decide if they want to be “safe” or not.

The first thing to ask is this: what exactly changed in Python 3? And, how easily can you move from Python 2 to Python 3? Or, how can you modify your Python 2 programs so they'll continue to work in Python 2, but then also work unmodified in Python 3? This last question is probably the most important one for my clients, and possibly for your business as well, during this transition period.

On the face of things, not very much actually changed in Python 3. It's a cleaner, more efficient and modern language that works like more modern Python developers want and expect. Things that Python developers were doing for years, but that weren't defaults in the language, are now indeed defaults. Sure, there are things I'm still getting used to after years of bad habits, such as failing to use parentheses around the arguments passed to print, but on the whole, the language has stayed the same.

However, this doesn't mean that nothing has changed or that you can get away with not changing your code.

thanks for question.

@ittraining what exactly is a modern Python developer and what does he/she want and expect? Using “print” as a statement is not a bad habit but a valid proven concept dictated by an equally sound programming paradigm. I also happen to harbor the awful tradition of conceiving strings as arrays of ASCII values, a practice I do not intend to give up until a future new year resolution. These are among a slew of old fashion, deprecated (are they?) abstractions around which I built a substantial library that I do not want to “correct” according to the fancy of a few designers. In fact Python 3.xx is not an evolution of Python 2.xx but a drastic divergence. Usually, when such a paradigm shift is warranted, designers create a brand new language. Ritchie did not go with “B v2” but started “C”. So did Wirth by setting aside “Pascal” and starting “Modula”. I do want modern Python developers (whatever that means) to ride into the sunshine with their shiny Python 3.x. I just want them to live Python 2.x alone by not advocating to remove it from future releases of Pythonista. By the way, I do write codes that are compatible from Python 2.7 up to latest releases of Python 3.x when my targeted audience is varied. They are also GUI compatible across different platforms without changing any code. A few of my postings in this forum can attest to that. However, for my private routines, that work flawlessly, I want to keep them backward compatible with Python 1.x. Because sometimes I take them to my virtual computers running Windows 3.11 or Mac system 7 or OS 8 to prove to myself that I could have solved certain problems decades ago if I was not much dumber then. In my book real programmers don't eat quiche.

You are responding to a spam post ;-)

They are just trying to sell training or get you to click the link.

From 2016 https://www.linuxjournal.com/content/transitioning-python-3

he fell into the trap as I have already done 😢 but what he says is not bad at all

100 days until Python 2 end of life. For macOS deprecation notices, see:
https://developer.apple.com/documentation/xcode_release_notes/xcode_11_release_notes