from __future__ import doesn't work together with Hy core function imports

[woodrush]

While this works,

(import [__future__ [print_function]])
(setv a 10)

This doesn't work:

(import [__future__ [print_function]])
(setv name 10)

The former compiles to the Python code (using hy2py)

from __future__ import print_function
a = 10

While the latter compiles to

from hy.core.language import name
from __future__ import print_function
name = 10

yielding the error

# ==>
#   File "importbug.hy", line 1
#     (import [__future__ [print_function]])
#     ^
# SyntaxError: from __future__ imports must occur at the beginning of the file

So this is because name is used in the Hy core, and Hy adds from hy.core.language import name at the beginning of the file, preceding from __future__ import print_function.

It also happens with other __future__ module imports such as from __future__ import braces. It also happens with this context, where it is clear that name doesn't refer to hy.core.language.name :

(import [__future__ [print_function]])
(defclass SomeObject [object]
  (defn __init__ [self name]
    (setv self.name name)))

which compiles to

from hy.core.language import name
from __future__ import print_function


class SomeObject(object):

    def __init__(self, name):
        self.name = name
        return None

[Kodiologist]

Is there any __future__ import that's useful in Hy, though? print_function is on by default in Hy on Python 2; it may not show up in the hy2py output, but hy2py is intended as a debugging tool and there's currently no guarantee that it produces working code (see in particular #970).

[koji-kojiro]

What @woodrush mentioned is not a problem of only hy2py.

$ hy -c "(import [__future__ [print_function]]) (def name 10)"
Traceback (most recent call last):
  File "/usr/local/bin/hy", line 9, in <module>
    load_entry_point('hy==0.12.1+101.g5bf9ecf', 'console_scripts', 'hy')()
  File "/usr/local/lib/python3.5/dist-packages/hy/cmdline.py", line 344, in hy_main
    sys.exit(cmdline_handler("hy", sys.argv))
  File "/usr/local/lib/python3.5/dist-packages/hy/cmdline.py", line 313, in cmdline_handler
    return run_command(options.command)
  File "/usr/local/lib/python3.5/dist-packages/hy/cmdline.py", line 193, in run_command
    pretty_error(import_buffer_to_module, "__main__", source)
  File "/usr/local/lib/python3.5/dist-packages/hy/cmdline.py", line 184, in pretty_error
    return func(*args, **kw)
  File "/usr/local/lib/python3.5/dist-packages/hy/importer.py", line 135, in import_buffer_to_module
    eval(ast_compile(_ast, "", "exec"), mod.__dict__)
  File "/usr/local/lib/python3.5/dist-packages/hy/importer.py", line 29, in ast_compile
    return compile(ast, filename, mode, flags)
  File "", line 1
SyntaxError: from __future__ imports must occur at the beginning of the file

[Kodiologist]

Yes, but what I'm saying is that (import [__future__ [print_function]]) is not useful in Hy anyway.

[Kodiologist]

I reviewed the various __future__ features. On Python 3, all of them are already on. On Python 2.7 (which is the only version of Python 2 we support), nested_scopes, generators, and with_statement are forced on by Python itself, and Hy enables division and print_function. That leaves absolute_import and unicode_literals. I propose we turn these on and ban __future__ statements in Hy code. We already fake the effect of unicode_literals; we might as well use it for real. So the only substantive effect this should have on the language is to enable absolute_imports for Python 2.

[gilch]

Turning on all future imports for Python 2 sounds like a good idea. I'm pretty sure this would only affect Hy modules, so it's not like we're forcing anything on the Python side. It will also help with the inevitable migration to Python 3.

Banning __future__ imports altogether even in Python 3 seems less desirable, but moot at the moment if we've got them all on already. I'm worried about other implementations using these though. Does PyPy have any __future__ imports that CPython doesn't?

The real fix would be to get rid of autoimports altogether. #434 / #791. I've been pondering ways to do this. Some kind of hy_builtins would help with a lot of things.

[Kodiologist]

Does PyPy have any __future__ imports that CPython doesn't?

Not any documented ones that I can find.

If Python 3 or PyPy add other __future__ features, or if we decide to support more implementations, in the future (yuk yuk yuk), we can add support for them then. But in the meantime, it's easier and probably less confusing to users to just ban __future__ with an informative error message.

[Kodiologist]

Aw shoot, the Python 3 documentation shows that there is in fact a __future__ feature that doesn't exist in Pythons < 3.5 and won't be forced on till Python 3.7, namely generator_stop (PEP 479). So I guess we need to support __future__ after all, unless we want to force it on in Pythons 3.5 and 3.6 (the only versions in which it is available but not mandatory).