add a single __future__ for py3?
Hi all, the common advise, these days, if you want to write py2/3 compatible code, is to do: from __future__ import absolute_import from __future__ import division from __future__ import print_function from __future__ import unicode_literals https://docs.python.org/2/howto/pyporting.html#prevent-compatibility-regress... I'm trying to do this in my code, and teaching my students to do it to. but that's actually a lot of code to write. It would be nice to have a: from __future__ import py3 or something like that, that would do all of those in one swipe. IIIC, l can't make a little module that does that, because the __future__ imports only effect the module in which they are imported Sure, it's not a huge deal, but it would make it easier for folks wanting to keep up this best practice. Of course, this wouldn't happen until 2.7.11, if an when there even is one, but it would be nice to get it on the list.... -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On Sat, 19 Sep 2015 at 10:51 Chris Barker <chris.barker@noaa.gov> wrote:
While in hindsight having a python3 __future__ statement that just turned on everything would be handy, this runs the risk of breaking code by introducing something that only works in a bugfix release and we went down that route with booleans in 2.2.1 and came to regret it. -Brett
On Sat, Sep 19, 2015 at 11:21 AM, Brett Cannon <brett@python.org> wrote:
It would be nice to have a:
from __future__ import py3
That may well kill the idea then, yes. Guido wrote:
yup, but that is enough to be a able to remember and type... and will there be more? probably not, but ..... But you are right, if we can redude that to a couple, maybe a smaller deal.
sure -- but this one is more for the learners -- these things are confusing -- and getting something that works in one version of python but not another will be more confusing, still. And much as I wish everyone would use a good linter....
- division is important. - print_function is important.
so maybe those two are enough....
hmm -- I find myself doing an unholy mess of u"" and "". And I tried teaching an intro class where I used u"" everywhere -- the students were pretty confused about why they were typing all those u-s, particularly since it didn't seem to make any difference. Sure there is breakage, but there is breakage on some of these between py2 and py3 anway -- APIs that return py2 strings on py2... So unicode_literals is still useful to me. But Brett was probably right -- somethign minor but useful but only works on the very latest bug-fix release is probably an attractive nuisance more than anything else. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
Chris, I don't think students should be worrying about writing code that is Python 2 and Python 3 compatible. That's a concern only for people who write libraries, tools and frameworks for others to use, and I do not think these are the kinds of programs students usually do. Even if they are doing something along those lines, they should be focusing on other more important features of the programs rather than whether they run on Python 2 and on Python 3. Having said that, I'd also like to add that I don't think ``from __future__ import unicode_literals`` is a great idea for making code 2/3 compatible nowadays. It was necessary before the u'' prefix was reinstated in Python 3.3, but since u'' is back it's much better to be explicit in your literals rather than dealing with runtime errors because of the blanket effect of the unicode_literals import. Anyone who cares about 2/3 compatibility should mark every single literal with a u'' or a b'' prefix. But students should not be distracted by this. They should be using Python 3 only ;-). Cheers, Luciano On Sat, Sep 19, 2015 at 3:41 PM, Sven R. Kunze <srkunze@mail.de> wrote:
-- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Professor em: http://python.pro.br | Twitter: @ramalhoorg
Luciano Ramalho writes:
I don't think students should be worrying about writing code that is Python 2 and Python 3 compatible.
I suppose Chris's students, as for many of those who post RFEs to aid in teaching Python programming (vs. using Python to teach programming), are professional programmers, not full-time students. I suspect it's their job to write such code.<wink/> One thing that I've learned in over a decade on this list is that the "consenting adults" attitude is very practical in focusing discussions here. If some posts "I have this use case <explanation>, that I'm addressing with this code: <code>", it's perfectly reasonable and often useful to reply, "Don't use that code: in Python the TOOWTDI is <more code>." But most of the time "that use case is invalid" isn't any help. The use case may even be "stupid", but mandated by employer or by contract with client, or by existing code that nobody knows how to maintain. YMMV, but I've been emparrassed every time I've written something to the effect of "you should make your use case go away." The OP usually cannot make it go away. The most that usually should be said is "it's very difficult to serve that use case elegantly in Python, and here's why."
On 20 September 2015 at 10:59, Luciano Ramalho <luciano@ramalho.org> wrote:
I care to disagree. Anyone writting maintaonable, future-proof code that should sitll run on Python2 should add the "from __future__ import unicode_literals" - and write the code fully aware that each string is text, and not bytes. The "u" prefix is nice for quickly porting projects, without rethinking the flow of every single string found inside.
On Mon, Sep 21, 2015 at 2:28 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Hah! Even if it were made to work, though, it'd mean you suddenly and unexpectedly get backward-incompatible changes when you run your code on a new version. Effectively, that directive would say "hey, you know that __future__ feature, well, I'd rather just not bother - get the breakage right away". Kinda defeats the purpose :) ChrisA
Chris Angelico wrote:
Properly implemented, it would use the time machine module to find every feature that will ever be implemented in Python. So once you had updated your code to be compatible with all of them, it would *never* break again! The neat thing is that it would take just one use of the time machine to backport this feature, and it would then bootstrap itself into existence. -- Greg
On Sep 20, 2015, at 22:15, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Well, I just tested it with 2.7.0, and it doesn't give me any future flags at all. Which proves that Guido is going to reject the feature (because otherwise he will would have useding the time machine, and he hasn't doinged), so there's no point discussing it any further. I thought maybe many-worlds could help, so I tried "from __alternate_timeline__ import *" first, but then I got "parse error on input\nFailed, modules loaded: none", and then my kernel panicked with a type error (needs more monads)".
On Mon, Sep 21, 2015 at 7:56 PM, Andrew Barnert via Python-ideas <python-ideas@python.org> wrote:
I thought maybe many-worlds could help, so I tried "from __alternate_timeline__ import *" first, but then I got "parse error on input\nFailed, modules loaded: none", and then my kernel panicked with a type error (needs more monads)".
Your kernel isn't multitimeline compliant. Try recompiling it with the --with-polyads option, and make sure you don't use an ad-blocker. Dragging this thread back to some semblance of serious discussion... An alias like "py3" could be well-defined, but still rather not - and definitely not the star-import. Even adding an alias would be a problem for compatibility, because there would be Python versions that suddenly fail. Currently, future features monotonically increase as Python versions increase, so if "from __future__ import barry_as_FLUFL" works on 3.3.6, I would expect it to work on 3.4.1 as well. Adding an alias to 2.7.11 would mean adding it also to bugfix releases in the 3.x line, so "from __future__ import py3" would break on certain bugfix releases of all versions of Python until 3.6, at which point it would be available. Do you really want your code to run fine on 3.5.1 and 3.4.3, but not on 3.5.0? That would be a nightmare to deal with, unless you're writing code for 2.7.11+/3.6+. ChrisA
On Mon, Sep 21, 2015 at 02:21:21AM -0400, Random832 wrote:
There will not be an official Python 2.8. https://www.python.org/dev/peps/pep-0404/
Or do we expect *new* __future__ features to be added to maintenance releases of Python 2.7?
No. -- Steve
On Mon, Sep 21, 2015, at 09:08, Steven D'Aprano wrote:
Well, yes, "until Python 2.8 comes out" was meant to be a synonym for "never". But Chris Angelico since pointed out that it would be a problem for Python 3 since it's intended to be used for 2/3 compatible scripts. I think I'd originally read the use case as "make Python 2 as similar to Python 3 as possible so that people learning on Python 2 won't learn as many bad habits", without anything about explicitly running the same scripts on Python 3.
It's just about these four imports, right? from __future__ import absolute_import from __future__ import division from __future__ import print_function from __future__ import unicode_literals I think the case is overblown. - absolute_import is rarely an issue; the only thing it does (despite the name) is give an error message when you attempt a relative import without using a "." in the import. A linter can find this easily for you, and a little discipline plus the right example can do a lot of good here. - division is important. - print_function is important. - unicode_literals is useless IMO. It breaks some things (yes there are still APIs that don't take unicode in 2.7) and it doesn't nearly as much as what would be useful -- e.g. repr() and <stream>.readline() still return 8-bit strings. I recommend just using u-literals and abandoning Python 3.2. -- --Guido van Rossum (python.org/~guido)
I think people should stick with *from __future__ import absolute_import* regardless of what code they are writing. They will eventually create a file innocuously called something like calendar.py (the same name as a standard library module) in the same directory as their main binary and their debugging of the mysterious failures they just started getting from the tarfile module will suddenly require leveling up to be able to figure it out. ;) -gps On Mon, Sep 21, 2015 at 8:18 AM Guido van Rossum <guido@python.org> wrote:
On 20 September 2015 at 03:50, Chris Barker <chris.barker@noaa.gov> wrote:
For folks using IPython Notebook, I've been suggesting to various folks that a "Python 2/3 compatible" kernel that enables these features by default may be desirable. Ed Schofield of python-future.org was the last person I suggested that to, and he was interested in taking a look at the idea, but wasn't sure when he'd be able to find the time. So, if anyone's interested in exploring the creation of new Project Jupyter kernels... :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Mon, Sep 21, 2015 at 2:29 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
That would be nice, yes. And not had to do. But in a way, I struggle with getting new-to-programming scientists to make the transitions from interactive code in a notebook to re-usable module -- one more thing that would break when they did that would be too bad. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On Sat, 19 Sep 2015 at 10:51 Chris Barker <chris.barker@noaa.gov> wrote:
While in hindsight having a python3 __future__ statement that just turned on everything would be handy, this runs the risk of breaking code by introducing something that only works in a bugfix release and we went down that route with booleans in 2.2.1 and came to regret it. -Brett
On Sat, Sep 19, 2015 at 11:21 AM, Brett Cannon <brett@python.org> wrote:
It would be nice to have a:
from __future__ import py3
That may well kill the idea then, yes. Guido wrote:
yup, but that is enough to be a able to remember and type... and will there be more? probably not, but ..... But you are right, if we can redude that to a couple, maybe a smaller deal.
sure -- but this one is more for the learners -- these things are confusing -- and getting something that works in one version of python but not another will be more confusing, still. And much as I wish everyone would use a good linter....
- division is important. - print_function is important.
so maybe those two are enough....
hmm -- I find myself doing an unholy mess of u"" and "". And I tried teaching an intro class where I used u"" everywhere -- the students were pretty confused about why they were typing all those u-s, particularly since it didn't seem to make any difference. Sure there is breakage, but there is breakage on some of these between py2 and py3 anway -- APIs that return py2 strings on py2... So unicode_literals is still useful to me. But Brett was probably right -- somethign minor but useful but only works on the very latest bug-fix release is probably an attractive nuisance more than anything else. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
Chris, I don't think students should be worrying about writing code that is Python 2 and Python 3 compatible. That's a concern only for people who write libraries, tools and frameworks for others to use, and I do not think these are the kinds of programs students usually do. Even if they are doing something along those lines, they should be focusing on other more important features of the programs rather than whether they run on Python 2 and on Python 3. Having said that, I'd also like to add that I don't think ``from __future__ import unicode_literals`` is a great idea for making code 2/3 compatible nowadays. It was necessary before the u'' prefix was reinstated in Python 3.3, but since u'' is back it's much better to be explicit in your literals rather than dealing with runtime errors because of the blanket effect of the unicode_literals import. Anyone who cares about 2/3 compatibility should mark every single literal with a u'' or a b'' prefix. But students should not be distracted by this. They should be using Python 3 only ;-). Cheers, Luciano On Sat, Sep 19, 2015 at 3:41 PM, Sven R. Kunze <srkunze@mail.de> wrote:
-- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Professor em: http://python.pro.br | Twitter: @ramalhoorg
Luciano Ramalho writes:
I don't think students should be worrying about writing code that is Python 2 and Python 3 compatible.
I suppose Chris's students, as for many of those who post RFEs to aid in teaching Python programming (vs. using Python to teach programming), are professional programmers, not full-time students. I suspect it's their job to write such code.<wink/> One thing that I've learned in over a decade on this list is that the "consenting adults" attitude is very practical in focusing discussions here. If some posts "I have this use case <explanation>, that I'm addressing with this code: <code>", it's perfectly reasonable and often useful to reply, "Don't use that code: in Python the TOOWTDI is <more code>." But most of the time "that use case is invalid" isn't any help. The use case may even be "stupid", but mandated by employer or by contract with client, or by existing code that nobody knows how to maintain. YMMV, but I've been emparrassed every time I've written something to the effect of "you should make your use case go away." The OP usually cannot make it go away. The most that usually should be said is "it's very difficult to serve that use case elegantly in Python, and here's why."
On 20 September 2015 at 10:59, Luciano Ramalho <luciano@ramalho.org> wrote:
I care to disagree. Anyone writting maintaonable, future-proof code that should sitll run on Python2 should add the "from __future__ import unicode_literals" - and write the code fully aware that each string is text, and not bytes. The "u" prefix is nice for quickly porting projects, without rethinking the flow of every single string found inside.
On Mon, Sep 21, 2015 at 2:28 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Hah! Even if it were made to work, though, it'd mean you suddenly and unexpectedly get backward-incompatible changes when you run your code on a new version. Effectively, that directive would say "hey, you know that __future__ feature, well, I'd rather just not bother - get the breakage right away". Kinda defeats the purpose :) ChrisA
Chris Angelico wrote:
Properly implemented, it would use the time machine module to find every feature that will ever be implemented in Python. So once you had updated your code to be compatible with all of them, it would *never* break again! The neat thing is that it would take just one use of the time machine to backport this feature, and it would then bootstrap itself into existence. -- Greg
On Sep 20, 2015, at 22:15, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Well, I just tested it with 2.7.0, and it doesn't give me any future flags at all. Which proves that Guido is going to reject the feature (because otherwise he will would have useding the time machine, and he hasn't doinged), so there's no point discussing it any further. I thought maybe many-worlds could help, so I tried "from __alternate_timeline__ import *" first, but then I got "parse error on input\nFailed, modules loaded: none", and then my kernel panicked with a type error (needs more monads)".
On Mon, Sep 21, 2015 at 7:56 PM, Andrew Barnert via Python-ideas <python-ideas@python.org> wrote:
I thought maybe many-worlds could help, so I tried "from __alternate_timeline__ import *" first, but then I got "parse error on input\nFailed, modules loaded: none", and then my kernel panicked with a type error (needs more monads)".
Your kernel isn't multitimeline compliant. Try recompiling it with the --with-polyads option, and make sure you don't use an ad-blocker. Dragging this thread back to some semblance of serious discussion... An alias like "py3" could be well-defined, but still rather not - and definitely not the star-import. Even adding an alias would be a problem for compatibility, because there would be Python versions that suddenly fail. Currently, future features monotonically increase as Python versions increase, so if "from __future__ import barry_as_FLUFL" works on 3.3.6, I would expect it to work on 3.4.1 as well. Adding an alias to 2.7.11 would mean adding it also to bugfix releases in the 3.x line, so "from __future__ import py3" would break on certain bugfix releases of all versions of Python until 3.6, at which point it would be available. Do you really want your code to run fine on 3.5.1 and 3.4.3, but not on 3.5.0? That would be a nightmare to deal with, unless you're writing code for 2.7.11+/3.6+. ChrisA
On Mon, Sep 21, 2015 at 02:21:21AM -0400, Random832 wrote:
There will not be an official Python 2.8. https://www.python.org/dev/peps/pep-0404/
Or do we expect *new* __future__ features to be added to maintenance releases of Python 2.7?
No. -- Steve
On Mon, Sep 21, 2015, at 09:08, Steven D'Aprano wrote:
Well, yes, "until Python 2.8 comes out" was meant to be a synonym for "never". But Chris Angelico since pointed out that it would be a problem for Python 3 since it's intended to be used for 2/3 compatible scripts. I think I'd originally read the use case as "make Python 2 as similar to Python 3 as possible so that people learning on Python 2 won't learn as many bad habits", without anything about explicitly running the same scripts on Python 3.
It's just about these four imports, right? from __future__ import absolute_import from __future__ import division from __future__ import print_function from __future__ import unicode_literals I think the case is overblown. - absolute_import is rarely an issue; the only thing it does (despite the name) is give an error message when you attempt a relative import without using a "." in the import. A linter can find this easily for you, and a little discipline plus the right example can do a lot of good here. - division is important. - print_function is important. - unicode_literals is useless IMO. It breaks some things (yes there are still APIs that don't take unicode in 2.7) and it doesn't nearly as much as what would be useful -- e.g. repr() and <stream>.readline() still return 8-bit strings. I recommend just using u-literals and abandoning Python 3.2. -- --Guido van Rossum (python.org/~guido)
I think people should stick with *from __future__ import absolute_import* regardless of what code they are writing. They will eventually create a file innocuously called something like calendar.py (the same name as a standard library module) in the same directory as their main binary and their debugging of the mysterious failures they just started getting from the tarfile module will suddenly require leveling up to be able to figure it out. ;) -gps On Mon, Sep 21, 2015 at 8:18 AM Guido van Rossum <guido@python.org> wrote:
On 20 September 2015 at 03:50, Chris Barker <chris.barker@noaa.gov> wrote:
For folks using IPython Notebook, I've been suggesting to various folks that a "Python 2/3 compatible" kernel that enables these features by default may be desirable. Ed Schofield of python-future.org was the last person I suggested that to, and he was interested in taking a look at the idea, but wasn't sure when he'd be able to find the time. So, if anyone's interested in exploring the creation of new Project Jupyter kernels... :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Mon, Sep 21, 2015 at 2:29 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
That would be nice, yes. And not had to do. But in a way, I struggle with getting new-to-programming scientists to make the transitions from interactive code in a notebook to re-usable module -- one more thing that would break when they did that would be too bad. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
participants (15)
-
Alexander Belopolsky -
Andrew Barnert -
Brett Cannon -
Chris Angelico -
Chris Barker -
Greg Ewing -
Gregory P. Smith -
Guido van Rossum -
Joao S. O. Bueno -
Luciano Ramalho -
Nick Coghlan -
Random832 -
Stephen J. Turnbull -
Steven D'Aprano -
Sven R. Kunze