> 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
