On Sep 22, 2015, at 6:43 PM, Andrew Barnert <abarnert@yahoo.com> wrote: On Sep 21, 2015, at 10:59, Gregory P. Smith <greg@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@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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/