[Python-ideas] add a single __future__ for py3?

Chris Barker - NOAA Federal chris.barker at noaa.gov
Wed Sep 23 08:09:36 CEST 2015


On Sep 22, 2015, at 6:43 PM, Andrew Barnert <abarnert at yahoo.com> wrote:

On Sep 21, 2015, at 10:59, Gregory P. Smith <greg at krypto.org> wrote:

I think people should stick with *from __future__ import
absolute_import* regardless
of what code they are writing.


If the py3 way of handling Absolute vs relative import isn't better --- why
is it in Py3????

Anyway, the point of a this is to get your py2 code working as similarly as
possible on py3. So better or worse, or not all that different, you still
want that behavior.

But again, it looks like this ship has sailed...

Thanks for indulging me.

-Chris





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. ;)


But they'll get the same problems either way. If calendar.py isn't on
sys.path, it won't interfere with tarfile. And if it is on sys.path, so it
does interfere with tarfile, then it's already an absolute import, so
enabling absolute_import doesn't help.

I suppose if they've done something extra stupid, like putting a package
directory on sys.path as well as putting something called calendar.py in
that package and importing it with an unqualified import, then maybe it'll
be easier for someone to explain all the details of everything they did
wrong (including why they shouldn't have put the package on sys.path) if
they're using absolute_imports, but beyond that, I don't see how it helps
this case.


-gps

On Mon, Sep 21, 2015 at 8:18 AM Guido van Rossum <guido at python.org> wrote:

> 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)
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________
Python-ideas mailing list
Python-ideas at python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150922/3e5100a0/attachment.html>


More information about the Python-ideas mailing list