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.
New features planned for python 4.0: http://charlesleifer.com/blog/new-features-planned-for-pytho...
You missed a /s there.
Sunsetting Python 2
201–210 of 733 posts
Re: Sunsetting Python 2
#202Some shared hosting providers are still offering Python 2.6 as their main offering.[1] Optionally, there's Python 3.2, probably the worst 3.x version. [1] https://www.hostgator.com/help/article/what-software-and-pro...
HostGator moves slow as frozen molasses but they do when they have to. Case-in-point, they rolled out Let's Encrypt support like the week that Chrome starting marking HTTP pages insecure.
Re: Sunsetting Python 2
#203What 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 cannot agree enough. As a casual python user, it is quite common to stumble in some issue, after somme googling land in a doc page, try my solution, and find it does not work. Then googling after the failed solution, noticing that the previous doc page was describing a Python 2 feature that do not exists (or works different) in Python 3.
Me three! It happens all too often that an example Python script fails in one, then succeeds in the other. I'm also a casual Python user, trying to ramp up because of its obvious popularity and utility. I wish that the basic syntactical changes could have been designed to be more backward-compatible. But, eventually I suppose, python2 will just be a footnote in history.
Re: Sunsetting Python 2
#204Earlier quoted context omitted.
> But you could easily write Python 3 compatible code so that upgrading once your dependacies were ready was easy. This sounds a bit like telling someone, oh, you could've easily started driving an EV, so that once charging stations were actually out there, you'd have been ready...
> This sounds a bit like telling someone, oh, you could've easily started driving an EV, so that once charging stations were actually out there, you'd have been ready... While car analogies are notoriously bad, it's much more like "I'm going to buy a plug-in hybrid and use gasoline until charging stations are widely available". You can write code that works in Python 2 that takes zero effort to run in Python 3. I (an…
I try to write compatible code myself too, and the only reason it's "zero effort" to run in Python 3 is that I've already invested said effort when making it compatible. Getting strings and paths and stdio to be cross-compatible and working correctly in both 2 and 3 can be quite painful in my experience. Which was kind of my point with the vehicle analogy. It requires a significant investment that you're ignoring, and lack of enough underlying support to justify it during that time.
Re: Sunsetting Python 2
#205Earlier quoted context omitted.
This is incorrect. https://cloud.google.com/appengine/docs/standard/python3/
I have numerous apps on their original standard environment. I'd have to rebuild huge parts of every single one of them for this completely different environment.
The original standard environment has a free tier and doesn't require billing and as such is great for everyone who can't or don't want to enter their credit card information.
Re: Sunsetting Python 2
#206In 2015, there was no way I could have moved to Python 3. There were too many libraries I depended on that hadn't ported yet. In 2019, I feel pretty confident about using Python 3, having used it exclusively for about 18 months now. For my personal use case at least, this timeline worked out well for me. Hopefully it works out for most everyone. I can't imagine they made this decision without at least some data backi…
> I can't imagine they made this decision without at least some data backing it up. Mind that there is a feedback loop between data of current usage and an eol announcement. If they announce an EOL close by this creates pressure to migrate.
In my mind, I kinda hope that data they used to back this decision up was asking "Hey, all you other volunteer Python language devs? How many of you want to work on the old Python2 codebase still? How many of you would prefer to be working on Python3? OK, that's just about unanimous. How about we all get drunk on Newyears and shut it down on Jan 1st?"
You can still get Microsoft Windows XP support today. If you're prepared to pay enough.
I wonder how many of the people who're upset by this have ever or ever worked for companies that've ever sent anything more than pocket change to the people Python?
Re: Sunsetting Python 2
#207And now remind yourself that there are self driving cars out there and autonomous digging equipment that is based on ROS, which doesn't have any plan or intent to move to python 3. Fun stuff...
ROS 1.1 (next release) will target Python3 only.
https://discourse.ros.org/t/versioning-roadmap-moveit-1-0-re...
Re: Sunsetting Python 2
#208Earlier quoted context omitted.
I cannot agree enough. As a casual python user, it is quite common to stumble in some issue, after somme googling land in a doc page, try my solution, and find it does not work. Then googling after the failed solution, noticing that the previous doc page was describing a Python 2 feature that do not exists (or works different) in Python 3.
This issue is part of why Haskell is so hard to learn. Haskell's package database Hackage keeps all old deprecated incompatible versions of packages, with documentation pages all well indexed by Google, with higher page rank because they are longer lived than the current package version, with no indication that they are deprecated and incompatible with current Haskell deployments.
Try Hoogle.
Re: Sunsetting Python 2
#209 rising
Re: Sunsetting Python 2
#210Great stuff. But what about alternative python interpreters that have been lagging behind? Jython is 2.7.1 and IronPython is 2.7.9
They are effectively both dead or moribund. Jython has had a py3 experimental branch for ages but the entire project is basically starved of money and effort. To be honest, the whole “Python on other runtimes” movement, as a concept, is more or less over. It’s just too much effort for too little reward, now that CPython has good libraries for pretty much anything you can think of.
Does that view include PyPy? I'm not deep into Python (aside from the Monty kind) but it seems to be maintained and makes performance claims.