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

Здравствуйте, 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.

On Fri, Aug 27, 2010 at 5:25 AM, 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.

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