1

My understanding is that importing from __future__ lets me use functions that are not yet part of the released python. This sounds like they are still works in progress, like the beta (seed) releases of apps or OS's. If they were totally finished, and thoroughly tested for all anticipate interactions and edge cases, then they would already be in an official release of python, right? Am I right that if I use a function I imported from __future__, then I'm risking something not working the way I had hoped/expected? Not working as advertised?

Karl Knechtel
  • 62,466
  • 11
  • 102
  • 153
Kim Silverman
  • 25
  • 4
  • If the question is "can I be assured that the behaviour I currently get by importing `__future__` will be the default in a later version of Python?" - as far as I know, they deliberately design around that and have a perfect track record so far. – Karl Knechtel Feb 02 '22 at 23:18

2 Answers2

4

That's not the purpose. You should read the PEP that introduced this feature.

The purpose is to allow for a grace period when an incompatible change is made to the language. We can't release such a change without breaking existing code. But people still want the new feature "right now".

So there's a compromise: people who want it right now can import it "from the future", while people who aren't yet ready for it can see deprecation warnings pointing out where the meaning of code will change in a later release (when the feature in question becomes part of the language, period).

Tim Peters
  • 67,464
  • 13
  • 126
  • 132
  • I understand and respect the purpose of `import from __future__`, but that is not my question. My question is that, since I am enabling new features, is it possible that they are not yet 100% reliably implemented? And I think I see the answer in that PEP: I am right to be concerned. In `lib/__future__.py` each feature is listed as being alpha, beta, candidate or final. So for each feature I might want to import from `__future__`, I can (and jolly well ought to) check the reliability right there (i.e. is it final?). Is this correct? – Kim Silverman Feb 03 '22 at 01:33
  • There's no difference between new behaviors introduced with `__future__` and those introduced without it, except whether they require using `__future__` to get at them. _All_ new behaviors, for example, are first introduced in an alpha or beta release (`alpha` etc refer to Python releases, not to features). By the time they're in a final release, they've been tested as well as practically possible, but that's irrelevant to whether `__future__` is involved. Of course there are no guarantees regardless. That said, it's hard to get a large number of people to try any form of pre-final release. – Tim Peters Feb 03 '22 at 02:54
0

The __future__ module doesn't really let you use new functions, but rather lets you enable new or changed features which have the potential to break existing code. It's intended to let developers ensure their code will adapt to future versions of Python, with the option of keeping them disabled in production until the code is entirely updated to work with the feature.

Most of the features listed in the __future__ are actually enabled by default as the version they were enabled in was reached. Currently, the only feature not enabled by default now is annotations, which causes all type hints to be interpreted as strings, which prevents circular references and allows circular imports due to static typing to be prevented.

So the new features in __future__ are perfectly safe to use, and you don't risk breaking your code if you choose to use them.

Miguel Guthridge
  • 1,444
  • 10
  • 27
  • I interpret your answer as meaning that new features in `__future__`: (1) are indeed new code, because they are "new or changed features", and (2) might not be 100% reliable because you say MOST are enabled in the new version, but for example at the moment `Annotations` is indeed not final. I see that I can check whether features are final in `lib/__future__.py`. – Kim Silverman Feb 03 '22 at 01:35
  • Most are enabled means that the features aren't worth importing since the feature is fully integrated. The features are 100% reliable, it's just that they're disabled by default as they could break existing code due to them changing existing behaviours. – Miguel Guthridge Feb 04 '22 at 03:24