7 ms·
Python 2.7 Countdown
- paulgb 9y agoIs Python 3 an officially supported language at Google yet?
- 33degrees 9y agoAs far as i know yes? Are there any services that don’t support it?
- lazypenguin 9y agoApp engine is 2.7 (standard runtime)
- paulgb 9y agoI mean internally, as one of the "approved four" (Java, C++, Python, and JavaScript, not counting Google's own languages)
- jhanschoo 9y agoThe old school (sandboxed, not containerized) google app engine still only supports 2.7.
- euroclydon 9y agoI’m just starting a GAE app for the first time ever and I chose what you call “old school”, but they call “standard” because my understanding is that it’s more cost effective in that when you have no traffic, you have little to no costs. Also, standard has start up time of like a second vs minutes for the “flexible” version. Basically standard, with Python 2.7 is a true app engine, where flexible is just a container service which runs almost whatever you want. People really shouldn’t try to position flexible as a new version of GAE. It’s a totally different service. If everyone who’s currently using standard had to switch to flexible, Many if their bills would go up. Is Google EOLing standard?
- filleokus 9y agoI was using GAE Standard with Python on my last gig for a couple of years, and now I'm using GAE Flexible, and I totally agree with you. My guess have always been that the naming choice was an attempt at rescuing the somewhat bad PR they had with GAE Standard by "polluting" (improving) the GAE brand with this new thing. (I was seriously concerned when I was told during the interview that they were using GAE on this job, but reliefed when it turned out to be GAE Flexible. However, I do miss some of the magic provided by Standard, but do not miss Python 2.7 and some of the restrictions.)
- dude01 9y agoYeah I'm still using the "standard" GAE, because it's simpler and still has better features -- but old Python :-(. I'm hoping they will eventually upgrade it, but I don't work there, so who knows?
- deleted 9y ago[deleted]
- Radim 9y ago"…hereby suggesting we throw a massive party to celebrate all that Python 2 has done…" Perhaps it's that ominous counter, but these words really evoked Poe's "The Masque of the Red Death" for some reason.
- eesmith 9y agoI think of it more like a wake. In "The Masque of the Red Death" they shut themselves away from the rest of the world. There's no correspondence from that to the end of core developer supported Python 2.
- FartyMcFarter 9y agoThe big problem is that migrating to Python 3 can result in silent runtime bugs. Here's a scary case: https://stackoverflow.com/questions/22288604/lambda-functions-unequal-behaviors-in-python-3-and-python-2 https://stackoverflow.com/questions/22288604/lambda-function...
- bhaavan 9y agoMacOS still ships with Python 2 as the default python.
- toyg 9y agoMacos still ships an outdated openssl, bash, etc etc... Apple are the definition of “lag” for developer tools.
- jeremiep 9y agoIt has to do with licenses. They're shipping the last GPLv2 version of bash for one, the new versions are on GPLv3. I don't get why people bash things when they clearly don't understand the full context (pun intended ;)
- toyg 9y agoThey've always been slow, even when licensing was not an issue. OpenSSL is not GPL3. They still shipped a very old version, then apparently switched to LibreSSL... and promptly shipped an old version of that. They lag. Licensing is an issue for a subset of tools, but lagging is very much an issue for all of them.
- stephenr 9y agoYou're letting logic and facts get in the way of a chance to complain about something Apple does.
- kodablah 9y agoWhat makes you think GP didn't understand the context? I don't get why people bash other people for saying objective truths just because they think the other person doesn't understand why. If they can't/won't ship up to date third party software, they shouldn't ship the third party software at all.
- eesmith 9y agoBecause "lag" implies that Apple is going to catch up, which is not the case. jeremiep's response is that Apple won't ever (under current management) update to GPLv3. It's not a lag, it's a deliberate avoidance.
- alergico 9y agoGuess the community (or a company like RedHat) will have to step in and fork 2.7. There is no way that people who haven't switched, will want to switch, unless absolutely forced to (for example: no security patches).
- guitarbill 9y agoThis old chestnut. Yeah, if there's enough people who are willing to pay for it (time or money), sure, Python 2.7 support will continue. I just hope those same people have used the past years to do calculate the cost of moving to Python 3 vs the cost of Python 2 support. Expecting Python 2 support to be free or even easy is delusional/selfish though.
- hungerstrike 9y agoPffft. Nice strawman. Who said it would be free or easy? Expecting that everyone will just hop over Python 3 because one group of people doesn't want to maintain Python 2 anymore is delusional.
- kstrauser 9y agoAt some point a CFO will ask why a company is spending $X to use ancient, unhireable versions of their tools when new, free, attractive versions exist. It will be explained - not exactly in these words - that it's basically because their senior devs refuse to learn new stuff. Senior management arguments will ensue. At the end, there will be a plan to save $X with One Simple Trick. Displaced senior devs will find themselves making nice paychecks at other shops with obsolete codebases, at least until those CFOs start to notice a funny line item in the engineering budget...
- hungerstrike 9y agoPython 3 has been out for how long? None of this has happened yet. What is going to make 2.7 so unmaintainable? It’s there, it works and what is going to change that?
- faragon 9y agoIf there is Python 4, please, make it backwards compatible. Thank you.
- eropple 9y agoA major version bump does tend to imply breaking changes.
- faragon 9y agoWhy?
- eropple 9y agoWhat exactly does the term "major version update" mean to you if not for a break in backwards compatibility? That's what a major version update is.
- faragon 9y agoHow many mainstream programming languages do you know having equivalent issues as Python 2.x to 3.x? Do you think it is reasonable to rewrite your code base on every programming language "major version update"? One thing is deprecation of features, because of not thinking an API properly back in the day, and another, involving an important rewrite in order to get your code base working. My point was: I expect Python 4 avoiding the mistakes of Python 3 regarding breaking backwards compatibility. Just that.
- majewsky 9y agoBecause that's what distinguishes major versions from minor versions (at least traditionally). https://en.wikipedia.org/wiki/Software_versioning#Change_significance https://en.wikipedia.org/wiki/Software_versioning#Change_sig...
- yeukhon 9y agohttp://www.curiousefficiency.org/posts/2014/08/python-4000.html http://www.curiousefficiency.org/posts/2014/08/python-4000.h... It will be backward compatible (unless there is an absolute need to break), but just keep Python 4 out of your head. For now, they predict just 3.10+
- sametmax 9y agoLet's take all a minute to thanks the awesome cpython team. Most of the devs work on it for free. They have very little budget as opposed to corporation backed projects like go, c# or js. Yet. The language has helped us since 5 years before java was born. You can find it in websites like youtube and instagram, OS stacks like linux and mac, wall street and NASA analytics, popular GIS, dropbox UI, blender and maya, sublimetext... Also thanks for having provided almost 15 years and many tools to migrate from 2 to 3. I know few languages that managed such a big update, but none that gave so much to help with the transitions. Guys and gals, you rock. And it needs to be said because we hear the people complaining the most loudly. Never all the people that are so grateful for it.
- Sir_Cmpwn 9y agoI made a similar, albiet more vulgar website a while ago: http://stfupy3.org/ http://stfupy3.org/
- rcarmo 9y agoMy experience over the past year has been that 80% of what I need for new projects is already available on 3 (with the remaining 20% being swappable for other stuff), and that asyncio is a massive (if controversial) boost in performance for some things. I do wish that some of the gevent/Cython stuff was 100% compatible on occasion, but it's manageable. That said, 2.7 is still the default in many environments, and we're likely to have to live with it for 12+ years.
- redsymbol 9y agoI teach online workshops on intermediate Python to several hundred developers each month, scattered globally. Since these are engineers in the work force, I start each class with a quick poll about which version they primarily use on their jobs: 2.7, or 3.x. 18 months ago, the results were typically 20% Python 3, and 80% Python 2. Over time, the ratio shifted. In recent months, it's VERY consistently 60-70% Python 3; one class it was 80%. As I tell those students: sooner than you think, having only Python 2 on your resume will make it look dated.
- Walkman 9y agoWho on Earth would write "Python2" in their resume? I have "Python".
- nas 9y agoFor those still running 2.7 because migrating is too hard, consider using my "ppython" version (https://github.com/nascheme/ppython https://github.com/nascheme/ppython). It is a modified version of 3.6 with extra backwards compatibility features. After running your code through 2to3, it should mostly work with ppython. After fixing all the runtime warnings, your code should work with regular 3.6.
- yegle 9y agoI took some time try to make an old codebase to work with python2/3. Some wat moment from the effort: 1. `StringIO.StringIO` is a PITA. There's no equivalent in Python3 (for a good reason), and you must choose between `io.StringIO` (which only support unicode) and `io.BytesIO` (which only support bytes string). A possible solution is to use `six.StringIO` but it's simply bury the problem. It would be a good idea to think about what string you are dealing with before doing any change around StringIO. 2. The `stat` module contains some helper functions to test st_mode. In Python2, the function will happily accept negative numbers but in Python3 an exception will throw: $ python2 -c 'import stat; print(stat.S_ISDIR(-1))' False $ python3 -c 'import stat; print(stat.S_ISDIR(-1))' Traceback (most recent call last): File "<string>", line 1, in <module> OverflowError: can't convert negative value to unsigned int 3. You can do `def foo(a, (b, c), d)` in Python2: https://www.python.org/dev/peps/pep-3113/ https://www.python.org/dev/peps/pep-3113/ 4. You can compare slice with int in Python2: $ python2 -c 'print(slice(1) > 1)' True $ python3 -c 'print(slice(1) > 1)' Traceback (most recent call last): File "<string>", line 1, in <module> TypeError: unorderable types: slice() > int()
- kstrauser 9y agoI think those are all improvements in Python3, even if they can be a hassle to fix: 1. Lots of legacy code incorrectly treats strings and byte arrays as the same thing. If you're dealing 100% with all ASCII all the time that might be mostly OK, but it's the wrong model for anything involving Unicode (which is pretty much everything now). 2. Modes are defined on Linux and macOS at least as uint32_t. -1 isn't a valid value of that type. 3. That bit me a few time. I've accepted that `def foo(a, b_and_c, d): b, c = b_and_c` is an alright substitute. 4. I like the new version better. `'a' > 5` doesn't even make sense and the 3.x way avoids accidental nonsensical comparisons.
- jpz 9y agof-strings were the killer feature for me - it’s a pity Python 3.6 isn’t in Debian yet. I do hope macOS get onboard next year also...