Given we'll be at Python 3.8 next month, I can't help but wonder about Python 4. When it will happen, and how long.
I dont think python 4 will be what you think it will. Most likely it will just be the next version of 3, not a game changing upgrade.
Sunsetting Python 2
321–330 of 733 posts
Re: Sunsetting Python 2
#322Earlier quoted context omitted.
Based on your timeline, a four year gap from "not yet ready to migrate" to "we won't fix security vulnerabilities" is very short. Python is an open source project I've used and contributed nothing to, so I don't have the right to be a back seat driver. Were it a commercial project and I was a customer, I would be quite upset.
It was longer than Apple’s move to 64 bit apps on the iPhone. Actually, depending on what action you pin dates to, it was twice as long. One other thing - you can’t run non-64 bit apps anymore. You can still run Python 2.
It's actually longer than android has been alive...
Re: Sunsetting Python 2
#323What surprises me about this is that the documentation for Python 2 does not explicitly say that the language version is about to be unsupported, see e.g. https://docs.python.org/2/library/zipfile.html Contrast this with the Postgres website, which tells me I'm browsing old docs (because Google still offers old links), see e.g. https://www.postgresql.org/docs/9.2/tutorial-window.html Are there plans to add a banner t…
I'm not sure this is the right place, but maybe open an issue here? https://bugs.python.org/ Or email the mailing list for more help? https://mail.python.org/mailman/listinfo/python-list
I was about to file a bug, but they found out it already exists, just hasn't been merged into the 2.x tree.
- https://github.com/python/cpython/commit/46ed90dd014010703c7... - https://github.com/python/cpython/pull/13638 - https://github.com/python/cpython/blob/master/Doc/README.rst...
Re: Sunsetting Python 2
#324Earlier quoted context omitted.
Your argument ignores that 2.7 was held onto for a decade. Legacy applications did not hold back adoption.
Which still seems like a short period of time, considering timelines in engineering are to support a version for 60 years.
You can keep running Python 2 just like you keep your COBOL systems running, nobody's gonna stop you except common sense.
Re: Sunsetting Python 2
#325Earlier quoted context omitted.
> If we switched from phillips to torx, and your favorite tool brand didn't make torx drivers yet, you've got to either convince them to start, or switch brands. This is the best analogy I have yet read. Thanks - you nailed an argument I have had at multiple gigs/clients way to often. > Professionals don't get to use this as an excuse to badmouth torx, and stick with phillips. D'accord. Exactly. I had very fruitful d…
Well it’s a shitty analogy because a swap to torx is basically a single API change. The switch to py3 is more akin to using a new building material. Easy to start with once you know the differences, but it’s a bitch to retrofit if you depend on a method of construction incompatible with it. “Go change the dependency” is a naive ideal. Most non-tech businesses have no budget for that kind of tech debt work.
[deleted]
Re: Sunsetting Python 2
#326When people mock me for writing long-term projects in Perl 5 ( https://github.com/jwr/ccheck ), I point them to the Python2/3 change. From an outsider's point of view, this change was not coordinated well and the timeline is too short. To clarify: long-term means automotive time scales: I want to be able to run my software in 10 years.
TBF, Perl 5 is not a language with a stated EOL. "Perl 6" is no longer even considered a successor, and if reason prevails, the language-formerly-known-as-Perl=6 will get a fresh name and cut loose, releasing the "one true Perl" from under its shadow.
Re: Sunsetting Python 2
#327Earlier quoted context omitted.
But you could easily write Python 3 compatible code so that upgrading once your dependacies were ready was easy. You also could have contributed to your dependancies to help them become Python 3 compatible.
Quick: run a shell command, split up the reply by line, run a regex on each line, and save the results to a yaml file— now, does what you wrote work correctly on both Python 2.7 and Python 3.3+? Yeah that's what I thought. It's still hard to get bilingual Python correct today, and it was considerably harder before 3.3.
No one is arguing that upgrading would be trivial; the argument is that it's necessary work that could have been started 10 years ago. Also, if you run your unit tests on Python 2 and 3, you'll get pretty good pretty fast at writing 2-3 compatible code.
Re: Sunsetting Python 2
#328I'm happy this finally happened, even though I've been clinging to Python 2.7 for quite some time.
I run a Flask course[0] and from the beginning I coded the app to work for both 2.7.x and 3.x in parallel but it's only been a few months now where Celery supported Python 3.7.
In either case, upgrading from 2.7.x to 3.7.x was super painless. It came down to making sure Celery is using 4.3+ and pytest requires 5+ if you plan to use Python 3.5+. There wasn't any app level changes that had to be done other than optionally removing some dual import try/excepts to work for both 2.x and 3.x. The biggest pain point was remembering to use print with parenthesis but I've been doing that for a while now so it's a non-issue.
This was based on a decently sized Flask app with tens of top level dependencies and many thousands of lines of code.
If someone wants to see how this upgrade process looked in real time, I recorded that and put it up on Youtube[1] the other week. The video also covers some gotchas you might encounter during the upgrade process (especially if you're running in production and deal with sessions).
[0]: https://buildasaasappwithflask.com/
[1]: https://nickjanetakis.com/blog/upgrading-a-dockerized-flask-...
Re: Sunsetting Python 2
#329I long for the day when typing "python" into a shell will bring up a python 3 prompt
And I would add - symlinking or shell aliasing does not count! I want a linux system without a single python2 binary anywhere on the disk! How many more decades must we wait??
As soon as calibre and mercurial finish their ports to python 3, python 2 will vanish from my Arch install. The day approaches!
Re: Sunsetting Python 2
#330One thing that confuses me about Python is just how many projects don't specify if the app is supposed to use 2 or 3, and the correct answer isn't 'either'. Check out something from Github, only to find I actually do need Python 2.7 or something. Is it that Python developers assume everyone will just intuit the version, or is there a default?
If not otherwise specified, I just look for a `print` command and see if its formatted as
print 'my string' indicating Python 2
or print('my string') indicating Python 3.