Keyword to disambiguate python version
I would propose that an idiomatic way is created, for instance a pragma or statement, which allows one to disambiguate the used python version in a manner that is both obvious for the human reader, and as well allows python to reject the script, should the wrong version of the interpreter be present. I think this is a quite common problem[1][2], which could be solved in a fairly easy and pragmatic way. Being a python beginner, I'm not well-adversed in the ways of idiomatic python, so feel free to reject or improve on my syntactic examples, these are merely meant to demonstrate my point. Building on [3], I would suggest some syntax like this: #!/usr/local/bin/python # version: python-3 import os, sys ... Alternatively, some syntax could be used that allows one to use basic comparison operators, a range or even simple chained logical statements. #!/usr/local/bin/python # version: [2.4 .. 3.0] and not 2.6.1 # or multiple clauses # version: >= 2.4.2 # version: < 3.0 # version: not 2.6.1 # jpython-version: ... # or multiple keys # min-version: 2.4.2 # min-jpython-version: 2.4.4 # max-version: 2.6.1 import os, sys ... This way it should be fairly obvious to the casual reader which python version the program is intended to run under, and the python interpreter can simply reject to parse/execute the program, should it encounter an incompatible requirement. All comments, thoughts and suggestions welcome. References [1] http://stackoverflow.com/questions/446052/python-best-way-to-check-for-pytho... [2] http://stackoverflow.com/questions/1093322/how-do-i-check-what-version-of-py... [3] http://www.python.org/dev/peps/pep-0263/
On Aug 26, 2010, at 12:25 PM, Jonny wrote:
I would propose that an idiomatic way is created, for instance a pragma or statement, which allows one to disambiguate the used python version in a manner that is both obvious for the human reader, and as well allows python to reject the script, should the wrong version of the interpreter be present. I think this is a quite common problem[1][2], which could be solved in a fairly easy and pragmatic way.
+1. I've found 3rd party libs where I only find out what version its compatible with by tripping over the wrong module. IMO it would be great for a pragma like Jonny mentions to be well supported. Here is a different take on mechanism and semantics. First, I'd like to be able to use: #!/usr/bin/python3 This allows a simple rough cut is a packaging issue, but IIRC the standard Makefile does not create python3. So the specific proposal is for the Makefile start doing that. This thread might be worth reading re: this issue. http://www.mail-archive.com/fedora-devel-list@redhat.com/msg08865.html Second, for the pragma, how about something like: __python__ = '2.4' When a new Python version sees that in the main script, a warning should be issued if __python__ is assigned a value that is lower than the current version or doesn't match the version format. In addition, if a module is imported with a higher version of __python__ than either the importing module or the main script, a warning should be issued. When a lint program sees that, any features not present in the version of python assigned to __python__ should be an error. In addition, lint programs should check the use of modules using the semantics that Python does. -Tony
On Fri, Aug 27, 2010 at 5:56 AM, Tony Lownds <tony@pagedna.com> wrote:
Here is a different take on mechanism and semantics.
First, I'd like to be able to use:
#!/usr/bin/python3
This allows a simple rough cut is a packaging issue, but IIRC the standard Makefile does not create python3. So the specific proposal is for the Makefile start doing that. This thread might be worth reading re: this issue. http://www.mail-archive.com/fedora-devel-list@redhat.com/msg08865.html
The Python 3 bininstall target in the Makefile puts the binary under the python3 name: (cd $(DESTDIR)$(BINDIR); $(LN) python$(VERSION)$(EXE) $(PYTHON)3$(EXE)) (Note the "3" between $(PYTHON) and $(EXE)) So if people want to flag a script specifically as python3, they can already say that in the shebang line either by referencing it directly or by writing "#!/usr/bin/env python3"). This was done so that a "make install" of Py3k on a Linux box wouldn't inadvertently clobber the system Python installation (I believe David Malcolm from Fedora was one of a number of people making that suggestion). For anything else, I've never been a fan of "last version tested" markers embedded in the code. It usually just leads to unnecessary noise and busy-work (cf. Blizzard's "load out of date addons" flag to workaround their own version markers for World of Warcraft addons). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Здравствуйте, Jonny. Вы писали 26 августа 2010 г., 23:25:30:
I would propose that an idiomatic way is created, for instance a pragma or statement, which allows one to disambiguate the used python version in a manner that is both obvious for the human reader, and as well allows python to reject the script, should the wrong version of the interpreter be present. I think this is a quite common problem[1][2], which could be solved in a fairly easy and pragmatic way.
Read sys.version / sys.api_version / sys.version_info / sys.subversion for that kind of information. However, depriving a user from the freedom to do as he pleases (in this case, dictating what environment to use) is a disastrous mistake. 1) It's not version number that matters, it's functionality. There are environments you can't even imagine where your code can be run. There are Python builds and flavours outside the CPython's version sequence. 2) Tracking all possible Python kinds and versions where your code works isn't something worth wasting time on. And if you don't include EVERYTHING IN EXISTENCE that can run it, it will cause trouble on compatible environments that you didn't 'officially approve'. If someone uses a code in an environment where it's unable to perform, it should just break for that very reason. Typical environment incompatibilities are clearly seen in Python: a code adhering to Python Zen ('Errors should never pass silently') raises an error where it's unable to proceed normally. Examples: * ImportError (missing module) * NameError (missing identifier in a module) * TypeError/ValueError (incompatible interface) * DeprecationWarning (exactly what is says) The right place to tell a user the environment your code was written for is documentation. A user just needs to know where to rely on you and where to take responsibility his/herself.
However, depriving a user from the freedom to do as he pleases (in this case, dictating what environment to use) is a disastrous mistake. That's a valid criticism, but maybe python could still warn about the mismatch, even if it would not reject the program by default.
1) It's not version number that matters, it's functionality. There are environments you can't even imagine where your code can be run. There are Python builds and flavours outside the CPython's version sequence. I agree, but there are also environments that I can determine not being able to run my code, and then I could warn on those. As to CPython, etc., maybe those can match against a "normalized" version number that they claim to be compatible with.
The right place to tell a user the environment your code was written for is documentation. A user just needs to know where to rely on you and where to take responsibility his/herself. I guess you are right about that. And for the really important cases, I suppose performing a check in the makefile, or, if everything else fails, directly in the code (yuck) should suffice.
On Fri, Aug 27, 2010 at 8:11 AM, Jonny <jwringstad@gmail.com> wrote:
The right place to tell a user the environment your code was written for is documentation. A user just needs to know where to rely on you and where to take responsibility his/herself. I guess you are right about that. And for the really important cases, I suppose performing a check in the makefile, or, if everything else fails, directly in the code (yuck) should suffice.
Umm, how is an explicit runtime check any uglier than a pragma? You would need to check the pragma at runtime anyway, otherwise pyc files wouldn't get checked reliably. If a module breaks due to version incompatibilities, developers can generally figure it out, especially if you document the tested versions clearly (e.g. by using the relevant PyPI trove classifiers*). Cheers, Nick. * Version specific classifiers for Python modules on PyPI: Programming Language :: Python :: 2 Programming Language :: Python :: 2.3 Programming Language :: Python :: 2.4 Programming Language :: Python :: 2.5 Programming Language :: Python :: 2.6 Programming Language :: Python :: 2.7 Programming Language :: Python :: 3 Programming Language :: Python :: 3.0 Programming Language :: Python :: 3.1 Programming Language :: Python :: 3.2 -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
1) It's not version number that matters, it's functionality. There are environments you can't even imagine where your code can be run. There are Python builds and flavours outside the CPython's version sequence.
Very true, but other Python flavors commonly specify what features they version of CPython's features they support. eg "Jython 2.5 implements the same language as CPython 2.5", "IronPython 2.7 Alpha 1 was released, supporting Python 2.7 features"
2) ... The right place to tell a user the environment your code was written for is documentation. A user just needs to know where to rely on you and where to take responsibility his/herself.
Well if a project you want to use doesn't specify what version they support pretty well, taking responsibility yourself is potentially time consuming... I for one like the idea of having some automated systems take care of that, to lower the cost for projects to support a wider range of python versions. Establishing an idiom like was done for __future__ is only the start of that, and may not even be strictly necessary but it would be a good start. -Tony
On Fri, Aug 27, 2010 at 5:25 AM, Jonny <jwringstad@gmail.com> wrote:
I would propose that an idiomatic way is created, for instance a pragma or statement, which allows one to disambiguate the used python version in a manner that is both obvious for the human reader, and as well allows python to reject the script, should the wrong version of the interpreter be present. I think this is a quite common problem[1][2], which could be solved in a fairly easy and pragmatic way.
Your proposed solution doesn't help with either of the linked Stack Overflow questions. The second one is completely covered by the existing sys.version_info() function, as it is only asking how to obtain the details of the running Python version. The first one is subtler, asking how to deal with code that won't even compile on earlier versions, so it will still fail to compile instead of degrading gracefully on older versions, even if the file is flagged somehow as requiring a later version. So it isn't at all clear what is to be gained here over the try-it-and-see-what-happens try/except approach (often best) or the explicit "sys.version_info() >= required_version" check. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Thu, Aug 26, 2010 at 3:25 PM, Jonny <jwringstad@gmail.com> wrote:
I would propose that an idiomatic way is created, for instance a pragma or statement, which allows one to disambiguate the used python version in a manner that is both obvious for the human reader, and as well allows python to reject the script, should the wrong version of the interpreter be present. I think this is a quite common problem[1][2], which could be solved in a fairly easy and pragmatic way.
-1 from me on this one. The risk of something not working only because some dummy put the wrong version in the pragma outweighs the benefit of version information being enforced problematically rather than merely by documentation.
-1 from me too. You'll need to change (or update) the source code every time a new release went out. Em Thu, 26 Aug 2010 17:59:02 -0400 Mike Graham <mikegraham@gmail.com> escreveu:
On Thu, Aug 26, 2010 at 3:25 PM, Jonny <jwringstad@gmail.com> wrote:
I would propose that an idiomatic way is created, for instance a pragma or statement, which allows one to disambiguate the used python version in a manner that is both obvious for the human reader, and as well allows python to reject the script, should the wrong version of the interpreter be present. I think this is a quite common problem[1][2], which could be solved in a fairly easy and pragmatic way.
-1 from me on this one.
The risk of something not working only because some dummy put the wrong version in the pragma outweighs the benefit of version information being enforced problematically rather than merely by documentation. _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- .:''''':. .:' ` Sérgio Surkamp | Gerente de Rede :: ........ sergio@gruposinternet.com.br `:. .:' `:, ,.:' *Grupos Internet S.A.* `: :' R. Lauro Linhares, 2123 Torre B - Sala 201 : : Trindade - Florianópolis - SC :.' :: +55 48 3234-4109 : ' http://www.gruposinternet.com.br
participants (6)
-
Ivan Pozdeev -
Jonny -
Mike Graham -
Nick Coghlan -
Sérgio Surkamp -
Tony Lownds