开发者

why do we invoke print after importing print_function (in Python 2.6)

开发者 https://www.devze.com 2023-02-01 13:19 出处:网络
To get the 3.0 print fun开发者_JS百科ction we do the following in Python 2.6: from __future__ import print_function

To get the 3.0 print fun开发者_JS百科ction we do the following in Python 2.6:

from __future__ import print_function

But to use the function we invoke print() not print_function(). Is this just an inconsistency or is there a good reason for this?

Why not the following:

from __future__ import print


The reason is that when you import from __future__ you're really just setting a flag that tells the interpreter to behave a bit differently than usual -- in the case of print_function, the print() function is made available in place of the statement. The __future__ module is thus "special" or "magic" -- it doesn't work like the usual modules.


print_function is a FeatureName not be confused with the print built-in function itself. It is a feature that is available from the future so that you can use the built-in function that it can provide.

Other Features include:

all_feature_names = [
    "nested_scopes",
    "generators",
    "division",
    "absolute_import",
    "with_statement",
    "print_function",
    "unicode_literals",
]

There are specific reasons as when you migrate your code to next higher version, your program will remain as such as use the updated feature instead of the __future__ version. Also if it were function name or the keyword itself, it may cause confusion to the parser.


In Python 3, the keyword print has been changed from calling a statement to calling a function.

So instead of saying print value you now need to say print(value), or you'll get a SyntaxError.

By doing the import, this change is effected in Python 2, too, so you can write programs using the same syntax as Python 3 (at least as far as print is concerned).


Simple. print is keyword in Python 2.

So a statement like

from somewhere import print

would be an automatic SyntaxError in Python 2.

Allowing (hardcoding it in the syntax)

from __future__ import print

was deemed not worth the effort.


Minimal example

>>> print     # Statement.

>>> from __future__ import print_function
>>> print     # Function object.
<built-in function print>
>>> print()   # Function call.

>>>

As mentioned at: What is __future__ in Python used for and how/when to use it, and how it works from __future__ are magic statements that alter how Python parses code.

from __future__ import print_function in particular changes print from a statement into a built-in function, as shown in the interactive shell above.

Why print(1) works without from __future__ import print_function in Python 2

Because the:

print(1)

is parsed as:

print (1)
^^^^^ ^^^
1     2
  1. print statement
  2. argument

instead of:

print( 1 )
^^^^^^ ^ ^
1      2 1
  1. print() function
  2. argument

And:

assert 1 == (1)

as mentioned at: Python tuple trailing comma syntax rule


For completness, all the currently available features are:

+------------------+-------------+--------------+----------------------------------------------------+
|     feature      | optional in | mandatory in |                       effect                       |
+------------------+-------------+--------------+----------------------------------------------------+
| nested_scopes    | 2.1.0b1     |          2.2 | PEP 227: Statically Nested Scopes                  |
| generators       | 2.2.0a1     |          2.3 | PEP 255: Simple Generators                         |
| division         | 2.2.0a2     |          3.0 | PEP 238: Changing the Division Operator            |
| absolute_import  | 2.5.0a1     |          3.0 | PEP 328: Imports: Multi-Line and Absolute/Relative |
| with_statement   | 2.5.0a1     |          2.6 | PEP 343: The “with” Statement                      |
| print_function   | 2.6.0a2     |          3.0 | PEP 3105: Make print a function                    |
| unicode_literals | 2.6.0a2     |          3.0 | PEP 3112: Bytes literals in Python 3000            |
| generator_stop   | 3.5.0b1     |          3.7 | PEP 479: StopIteration handling inside generators  |
| annotations      | 3.7.0b1     |          4.0 | PEP 563: Postponed evaluation of annotations       |
+------------------+-------------+--------------+----------------------------------------------------+
0

精彩评论

暂无评论...
验证码 换一张
取 消