On Wed, Apr 29, 2015 at 06:12:37PM -0700, Guido van Rossum wrote:
On Wed, Apr 29, 2015 at 5:59 PM, Nick Coghlan firstname.lastname@example.org wrote:
On 30 April 2015 at 10:21, Ethan Furman email@example.com wrote:
From the PEP:
Why not a __future__ import
__future__ imports are inconvenient and easy to forget to add.
That is a horrible rationale for not using an import. By that logic we should have everything in built-ins. ;)
This response is silly. The point is not against import but against __future__. A __future__ import definitely is inconvenient -- few people I know could even recite the correct constraints on their placement.
Are you talking about actual Python programmers, or people who dabble with the odd Python script now and again? I'm kinda shocked if it's the first.
It's not a complex rule: the __future__ import must be the first line of actual executable code in the file, so it can come after any encoding cookie, module docstring, comments and blank lines, but before any other code. The only part I didn't remember was that you can have multiple __future__ imports, I thought they all had to be on one line. (Nice to learn something new!)
'as' went through the "not really a keyword" path, and it's a recipe for complexity in the code generation toolchain and general quirkiness as things behave in unexpected ways.
I don't recall that -- but it was a really long time ago so I may misremember (did we even have __future__ at the time?).
I have a memory of much rejoicing when "as" was made a keyword, and an emphatic "we're never going to do that again!" about semi-keywords. I've tried searching for the relevant post(s), but cannot find anything. Maybe I imagined it?
But I do have Python 2.4 available, when we could write lovely code like this:
py> import math as as py> as <module 'math' from '/usr/lib/python2.4/lib-dynload/mathmodule.so'>
I'm definitely not looking forward to anything like that again.