> import System > a = > [].GetType().Assembly.GetCustomAttributes(System.Reflection.AssemblyFileVersionAttribute, > False) > if len(a) > 0: > if a[0].Version == "1.0.61005.1977": print "IronPython 1.0.1" > else: print "Unknown version" > else: > print "IronPython 1.0"
Er - what? This isn't even close to a good approach. How on earth can I make code that uses this forward-compatible? Any code I write using this will need to be updated for IronPython1.1, and whenever there is a subsequent version. Please, please at least support sys.subversion to identify the version. I'm thinking something like ('IronPython', 'tags/1.0.1', '61005') or the like. CPython 2.5 is currently ('CPython', 'tags/r25', '51908') Right now, there is no easy way (aside from parsing sys.version) to say "is this code running on CPython or IronPython." And, as I started this thread, the format of sys.version changed from 1.0 to 1.0.1. I'd be open to suggesting some other attribute in sys - but it really does need to be in sys. If there was something like "sys.implementation" I could see we could add that to CPython as well. (But see note below about CPython release schedule) As far as sys.version_info claiming to be Python 2.4 - I can sort of understand that from a pragmatic point of view. But it leaves me with a bad feeling - it's all too similar to almost every http client identifying themselves as "Mozilla 4.0 (Actual Browser Name Here)". The basic problem is that the stuff we have now was designed really for a world where all Python implementations shared a common concept of "version" - that is, Jython 2.2 is feature-compatible with CPython 2.2. It's possible that needs to be addressed, although given we just did CPython 2.5, we're not going to be able to change it for CPython for a good 18 months (the approximate timeframe for a 2.6). Anthony _______________________________________________ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com