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