2

I have discovered that I can't use the flush argument in the new print function if I use Python 2.7.11. I have used:

from __future__ import print_function

print('Hello', flush=True)

but it complains with the error:

Traceback (most recent call last):
  File "print_future.py", line 3, in <module>
    print('Hello', flush=True)
TypeError: 'flush' is an invalid keyword argument for this function

After looking at the documentation for print I discovered that it doesn't work even though it is an argument. My inference is that it doesn't work because flush was only added in version 3.3, thus the special from __future__ import statement is probably importing an older version of the function. The comments suggest it's using 2.7.11 but I don't understand why it's doing this.

I did see Need Python 3.4 version of print() from __future__, whose answer just wraps print and manually adds the flush parameter. Even though that works, it seems more of a hack than addressing the real problem, that we don't have the most recent version of print.

Is there a way to import specific versions of Python functions (I want to use the Python 3.5 print function, specifically) to my current Python script? If this is not possible, why not?

It seems (surprisingly) its not clear to people how my question is different even though I wrote it. I will say it differently.

  1. It seems that my issue is that its importing the python function that I am not expecting (since it doesn't find the flush argument). Therefore, the most natural and the first thing I'd like to do and know is, which print function is it importing. The comments suggest its using 2.7.11 but I don't understand why its doing this.
  2. I understand that the from future statement changes how my compiler works. It seems I assumed that since it was a future statement it also brought in the print function from a future release. It seems it only changes the behaviour of my interpreter. If I were able to see what print function its using I would know that its not importing a function from a future release but only acting like a future python interpreter. Thats what it seems but I don't know for sure and I'd like to know for sure whats going on.
  3. Last but not least, is there not a natural way to import future python functions to my current python script? I want to use python 3.5 print statement, is it not possible to use that function apart from just making the compiler behave like a future python interpreter but also behave like a future python version? It was (at least to me) counter intuitive to have the parser act like future python but still act like a 2.7.11. The solution I want is not a wrapper but a import of the recent python. If this is not possible, then a answer to my question should explain why its not possible.
Community
  • 1
  • 1
Charlie Parker
  • 5,884
  • 57
  • 198
  • 323
  • 2
    When you `from future import print_function` you get the 2.7.11 version of the print function. It doesn't read any python3 code; it doesn't get a version from any python 3. You can't import the python3 print builtin into python2. The only correct solution, if you need "flush" is to use wrapper: hence the duplicate. – James K Aug 28 '16 at 18:50
  • 2
    You've asked the same question again, the fact that you've linked it doesn't make much difference. If that's the answer, that's the answer; if you don't understand why, consider a comment, and if you need a different one, consider a bounty. – jonrsharpe Aug 28 '16 at 18:50
  • 1
    @jonrsharpe I did not ask the same question. I even wrote what the difference is. First I already said that a solution with a wrapper is not a solution to my question. My question is to essentially import the print statement from python 3.4 or more. I understand that the future statement just changes how my python parses my file at compile time, but is there no way to get it to use the print function I am requesting? I also asked how do I check version of the print function its using, I'd like to know and check that. If the answer is you can't do it with a wrapper even if you use future, I'd.. – Charlie Parker Aug 28 '16 at 19:00
  • @jonrsharpe like to know why. I read that solution and it doesn't address all dimensions of my question. Why doesn't future work, why can't I import a more recent version of my thing with future and how do I check which print version I am using. – Charlie Parker Aug 28 '16 at 19:01
  • But the rest of your question doesn't make much sense. *"Why doesn't future work"* - it does work. *"why can't I import a more recent version of my thing with future"* - because you can, inevitably, only import the version it comes with. *"how do I check which print version I am using"* - again, it's the one it comes with. *"I already said that a solution with a wrapper is not a solution"* - no you didn't, you just opined that it's a hack. – jonrsharpe Aug 28 '16 at 19:03
  • 1
    @jonrsharpe I am allowed to describe what I count as an answer. In the specs of my answer a wrapper is a hack. It might not be in any other context, but in this question it is not the solution since it doesn't explain to me what I want to know. I have updated my question with more details. Hope it clarifies what I want to ask. Saying "its not possible to do it with your constraints" is a perfectly acceptable answer. I have clarified what I meant by future too. I'm fine being wrong, but I just want to know why I can't do it the way I am requesting. – Charlie Parker Aug 28 '16 at 19:10
  • 1
    Why didn't you just read the docs that [actually correspond to what you're using](https://docs.python.org/2/library/functions.html#print)? They clearly show that there's no `flush`. `from __future__ import` doesn't search your whole machine for alternative implementations, and it's not at all clear why you'd ever think it would, it uses the specific version that is bundled with the Python version you're using (otherwise it wouldn't work at all if you didn't also have 3.x installed). If you want 3.5's `print`, or another new feature, just use 3.5, there are very few reasons to still be on 2.x. – jonrsharpe Aug 28 '16 at 19:22

1 Answers1

0

  1. its importing the python function that I am not expecting

    I don't see why, this is the version of print that's documented in 2.7.x.

    which print function is it importing.

    The version bundled with 2.7.11, which is the version that was introduced in 3.0 (see PEP-3105).

    The comments suggest its using 2.7.11 but I don't understand why its doing this

    ...because that's the version of Python you're using? from __future__ import ... doesn't search your computer for alternative implementations, it uses the one that's bundled with the version of Python you're using. If you think about it this is inevitable, as otherwise future imports would fail on machines that don't have 3.x installed.

  2. The majority of this made little sense to me, but:

    I assumed that since it was a future statement it also brought in the print function from a future release.

    That's exactly what it's doing. You don't get to choose which future release, though. You get the version that was planned for release at the time it was added into __future__.

  3. is there not a natural way to import future python functions to my current python script?

    Yes, and it's the way you're using, as long as that functionality is supported in __future__.

    is it not possible to use that function

    not the 3.3-onwards version of it in the version of Python that you're using, no*. If you want the functionality offered by more recent versions of Python, use a more recent version of Python. 2.x is running out of road.

    It was (at least to me) counter intuitive to have the parser act like future python but still act like a 2.7.11

    It's not "[acting] like a 2.7.11". It's using the print function from 3.x rather than the print statement from 2.x. If you try to print 'hello' after the import of print_function, you'll get a SyntaxError as you would in 3.x.

    * assuming you're not planning to get into hacking your installation

jonrsharpe
  • 115,751
  • 26
  • 228
  • 437
  • 1
    When an uninformed python user (me or the OP in this case) comes across `from future import X` the natural thing to assume is that you're importing functionality from a release *other* than the one you're using - e.g. an actual future release (I wonder what would give us that idea?). I understand now `__future__` is really a misnomer - perhaps `__testing__` or `__planned__` would have been better. It's not a magical keyword, but just another package included with your version. Your answer has the right information, but the snarkiness and condescension doesn't really belong on SO. – argentum2f Mar 16 '18 at 17:51
  • @argentum2f it's not just another package, it changes how the interpreter works – jonrsharpe Mar 16 '18 at 17:58