PEP suggestion: Uniform way to indicate Python language version

[Steve D'Aprano]

On Mon, 22 Aug 2016 08:32 pm, rocky wrote:

> On Monday, August 22, 2016 at 1:36:07 AM UTC-4, Steven D'Aprano wrote:
[...]
>> But... I don't understand what this proposal actually is. We already have
>> a uniform way to indicate the Python language version: check sys.version,
>> or sys.version_info, or sys.hexversion, whichever is more appropriate for
>> your needs.
> 
> The fact that you mention 3 different ways says to me this isn't uniform.

What do you mean? Of course it is uniform -- every compliant Python
interpreter must support sys.version, sys.hexversion and sys.version_info.

sys.version and sys.hexversion go back to at least Python 1.5 and possibly
older. I'm not sure when version_info was introduced, but anything offering
Python 2.4 or better must support it. So as far as current and future
versions of Python go, you can trust that *any* version of *any*
implementation will support those three attributes, be it CPython, PyPy,
Nuitika, Jython, IronPython, Stackless, or something else. 

Perhaps you mean "unique" rather than uniform -- but of course you cannot
have a unique way of doing this, since people can simply test for the
existence of features, or inspect the version number, whichever they
prefer. Adding something like Perl's "use" won't change that -- it still
won't be unique.


>> Could somebody (the OP?) please explain what is the purpose of this
>> proposal, what it does, how it works, and when would people use it?
> 
> All of the ways you mention involve running the program. Suppose you have
> a tool that analyzes source code. It reads the code, but doesn't run it.
> For example possibly code climate. 

What is "code climate"?


> How it it figure out which dialect of Python is being used?

In general, you can't, because Python code will run under many different
versions and implementations.

I'm not strongly opposed to this suggestion. I just don't see the point.
I've never found myself missing this feature. And I don't like version
testing except as an absolute last resort: I much prefer feature detection.

But the biggest problem with this suggestion is the practical issue that the
absolute earliest it could be introduced will be Python 3.6, and more
likely 3.7. Python 3.6 has only a couple of weeks left before feature
freeze, and all older versions are likewise frozen or out of support.

Realistically, by the time you convince people this is a useful feature,
write a patch and have the patch reviewed, you'll be looking at Python 3.7.
So 3.7 will have this new syntax "use version", and *no other version*.
That means you can't use it until you are ready to abandon Python 2.4
through 3.6.

I'm assuming you want a new syntactic feature like Perl's "use version". If
its just a function, then you can use a version check to test for it first:

if sys.version_info > (3, 7):
    sys.use("v3.7")

but that makes "use" completely redundant. (If you have to test the version
before you can test the version, what's the point of the second test?)

If this feature had been built into Python from the start, it would merely
be an attractive nuisance, encouraging people to test the version instead
of doing feature-detection. But since it wasn't, I don't see any point to
add it now: if we added it to Python 3.7, it wouldn't be until (probably)
2028 or significantly later that folks could rely on it being available.

(Currently, I think that Red Hat offer the longest paid commercial support
for Python versions: ten years. Suppose they start using Python 3.6 as
their standard Python next year, it won't fall out of support until 2028.
That's the absolute earliest pre-3.7 versions could be considered out of
support.)



Earlier, in a previous email, Rocky also wrote:

> Right. People are focusing on specific code instead of the problem: a
> simple and uniform way to indicate a specific Python dialect in force for
> that program. 

That's not describing the problem. That's describing one specific solution
to some unknown problem. The *solution* is "a simple and uniform way to
indicate..." but what is the problem? Under what circumstances would people
use this? Why would they use it?

Normally, there's no question about what version of Python a module is meant
to use:

- if it is a script, it has a hash-bang line at the top which specifies the
location of the Python interpreter;

- if its a library, it will be installed in the site-packages directory of a
specific version of the interpreter;

- and more importantly, many (possibly even most) Python code will run under
multiple versions.

There are exceptions to this of course. Sometimes libraries will be just
dumped any old place, and scripts may not have hash-bang lines. Neither of
these are compulsory. But neither will your proposed "use version".


> The language continues to evolve over time: there are many 
> Python 2.7 programs that won't work on Python 2.5 or earlier and vice
> versa. When you expand the range from Python 1.5 to Python 3.6 the
> likelihood of the program running becomes even smaller.

None of those versions can possibly support this "use" syntax or function.
There's just barely a tiny chance that it could be added to Python 3.6.


> Furthermore, I am not aware of any program that when given a Python source
> code will tell you which or versions or dialects of Python it will run on.

In general, you can't have such a program. But even if you could, why would
you want it?

> The fact that there has been all this much discussion over specific code
> to me enforces the need for a simple an uniform mechanism.

There's only been this much discussion because you raised the issue and were
not clear about what it was. I have been a regular here for over a decade,
and this is the first time I've seen anyone asking about this sort of
feature. If you hadn't raised the issue, we wouldn't be discussing it.





-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.