How Python 3 Should Have Worked (2012)
aaronsw.com
How Python 3 Should Have Worked (2012)
1–10 of 80 posts
Re: How Python 3 Should Have Worked (2012)
#2One of the top posts on the Python Reddit today:
Re: How Python 3 Should Have Worked (2012)
#3This strategy makes a lot of sense to me. I really like the "deprecated warnings" to "explicit failure" transitions, IMO this works really well, though I only have experience with it at a library level using semver. So cant say much about point #1, except that this is essentially what you're doing when you test agains xlib-head branch.
Aaron implies that this approach was not taken with Python (non-py guy here), could someone tell me what the reasoning was behind that? To much legacy code in Py2 code base, just wanting to start from a clean slate, or what?
EDIT: (to add another question :) could you efficiently accomplish what Aaron is talking about, what would be the best way to go about this? @pak would you really have to load 2 stdlibs, is there no (efficient) way around syntax errors?
Re: How Python 3 Should Have Worked (2012)
#4This strategy makes a lot of sense to me. I really like the "deprecated warnings" to "explicit failure" transitions, IMO this works really well, though I only have experience with it at a library level using semver. So cant say much about point #1, except that this is essentially what you're doing when you test agains xlib-head branch. Aaron implies that this approach was not taken with Python (non-py guy here), coul…
There are pieces of Python 3 that are syntax errors in Python 2. And there are Python 2-isms that are valid syntax in Python 3 but have a different interpretation. It's not as simple as importing certain features (which creates a sort of language version hybrid).
The idea to allow one project to switch between Python 2 and Python 3 for individual files is more interesting, but practically speaking would lead to sort of a mess.
Re: How Python 3 Should Have Worked (2012)
#5This strategy makes a lot of sense to me. I really like the "deprecated warnings" to "explicit failure" transitions, IMO this works really well, though I only have experience with it at a library level using semver. So cant say much about point #1, except that this is essentially what you're doing when you test agains xlib-head branch. Aaron implies that this approach was not taken with Python (non-py guy here), coul…
There are pieces of Python 3 that are syntax errors in Python 2. And there are Python 2-isms that are valid syntax in Python 3 but have a different interpretation. It's not as simple as importing certain features (which creates a sort of language version hybrid). The idea to allow one project to switch between Python 2 and Python 3 for individual files is more interesting, but practically speaking would lead to sort…
>The idea to allow one project to switch between Python 2 and 3 for individual files
Yes, I believe key parts of the standard object model changed between the two (e.g. strings vs bytes, many of the magic methods and operators) making this nearly impossible. Every time objects would pass back and forth, they'd have to be converted, which is wasteful and bug-prone (and this is a whole mess of library code that the python3 guys probably did not want to write). You'd also need to load two different standard libraries, which would waste memory.
You only need to scan through the upgrade feature list to see how hard intercompatibility would have been. http://docs.python.org/3.0/whatsnew/3.0.html
Although I totally agree with Aaron that this would have allowed people to actually use Python 3 without fear, anything short of forcing the entire program and all of its modules to run in v3 mode as opposed to v2 mode would have been a disaster from a reliability and technical design standpoint. And that's closer to how things actually went down with 2to3, etc.
Re: How Python 3 Should Have Worked (2012)
#6I think the strategy Aaron talks about makes a lot of sense. I especially like the idea of simply shipping future interpereters that can work with both 2.x and 3.x code. Seriously, it makes it even more dead-simple to get started with Python 3.
We can extend Aaron's ideas to even more radical ideas, for example, instead of allowing Python 3 and 2 code to be mixed on a per-file basis, allow it to be mixed on a per-function basis. In fact, allow running Python 3 code, and drop in "backwards incompatible" blocks inside of a function to let you program things that will be backwards-compatible. In other words, let people program in Python 3 as much as they want, but allow them a way to use libraries that only support Python 2 without making a mess. I'm not saying this will be easy at all, but it will definitely make Py3k adoption actually happen.
On the meta level, I'm really glad people are now discussing how to get the Python 3 rollout happening, because we really are dangerously close to having a "dead" language in Python if nothing changes.
Re: How Python 3 Should Have Worked (2012)
#7I agree with this 100%.
Python 3 is a disaster. The problem is they made the entire thing out to be a Big Deal, but they didn't really offer any compelling reason to upgrade. I mean, the unicode is... kinda better, and iterators are a bit improved, but couldn't those things have been point releases? 2.8? They basically said that python 3 was a new language, and then offered no significant reason you should use this new language. So we all kept using actual python, quirks and all. To me, as a python developer, Python 3 is a failed fork. Harsh but true.
IMO, if they were going to do that sort of thing, they should have had at least one killer feature. Like maybe if python 3 had been based off pypy they could be saying "Look! We're 5x faster! Want to upgrade now?". That would have been compelling. But their message was: "we cleaned up some stuff that most of you don't care about, and broke a bunch of things". Think about pitching that sort of upgrade to your boss. "Well it doesn't solve any of our problems, and it creates a ton of new ones, but it's the right thing to do because it makes some code slightly cleaner arguably! Convinced yet?"
If I were in charge of python, I would do this: announce python 4, have it be based on the pypy interpreter, and keep compatibility with python 2 the language while reforming the C extension APIs to be more future proof (for getting rid of the GIL and so on). (Or maybe get rid of them entirely and just have people use CFFI.)
Re: How Python 3 Should Have Worked (2012)
#8It's also really off putting for beginners that try to learn the language. Python 3 is being served as the main download when you search for it. And while you search for tutorials, most of them are in python 2 - and 80% of them DO NOT state whether they are for python 2 or python 3 ( because most were made during the python 2 times? ).
So people try to learn to code with python 3.x and get frustrated because simplest things don't work.
They should seriously rethink the whole 3.x thing. I must say, introducing it probably did more harm than good for the future of this language.
Re: How Python 3 Should Have Worked (2012)
#9Earlier quoted context omitted.
There are pieces of Python 3 that are syntax errors in Python 2. And there are Python 2-isms that are valid syntax in Python 3 but have a different interpretation. It's not as simple as importing certain features (which creates a sort of language version hybrid). The idea to allow one project to switch between Python 2 and Python 3 for individual files is more interesting, but practically speaking would lead to sort…
>The idea to allow one project to switch between Python 2 and 3 for individual files Yes, I believe key parts of the standard object model changed between the two (e.g. strings vs bytes, many of the magic methods and operators) making this nearly impossible. Every time objects would pass back and forth, they'd have to be converted, which is wasteful and bug-prone (and this is a whole mess of library code that the pyt…
thanks for that link, now I see the problems Text Data vs. Unicode alone would be an enormous overhaul. Though the syntax changes dont seem that problematic.
Re: How Python 3 Should Have Worked (2012)
#10This strategy makes a lot of sense to me. I really like the "deprecated warnings" to "explicit failure" transitions, IMO this works really well, though I only have experience with it at a library level using semver. So cant say much about point #1, except that this is essentially what you're doing when you test agains xlib-head branch. Aaron implies that this approach was not taken with Python (non-py guy here), coul…
This link is posted from the [dead] winstonian: