On Tue, May 19, 2009 at 7:26 PM, Benjamin Peterson <benja...@python.org> wrote: > 2009/5/19 Michael Foord <fuzzy...@voidspace.org.uk>: >> I have IronPython specific versions of several of these functions which use >> .NET reflection and inspect could fallback to if sys.platform == 'cli'. >> Would it be ok for me to add these to the inspect module? Obviously the >> tests would only run on IronPython... The behaviour for CPython would be >> unaffected. > > I wish we had more of a policy about this. There seems to be a long > tradition of special casing other implementations in the stdlib. For > example, see types.py and tests/test_support.py for remnants of Jython > compatibility. However, I suspect this code has languished with out > core-developers using the trunk stdlib with Jython. I suppose this is > a good reason why we are going to split the stdlib out of the main > repo. > > However that still leaves the question of how to handle putting code > like this in. Should we ask that all code be > implementation-independent as much as possible from the original > authors? Do all all changes against the stdlib have to be run against > several implementations? Should we sprinkle if switches all over the > codebase for different implementations, or should new support files be > added? >
>From my observation (mostly according to jython), such changes easily get out >of sync. The net result is that you have one, outdated, version in stdlib and other implementation, like IronPython is maintaining it's own anyway. IMO it's easy enough to maintain clearly implementation-specific parts out of cpython's stdlib. What I would rather like to see is that stdlib does not contain impl specific parts, even for cpython and cpython maintains it's own things outside of stdlib. This would be in line with what we discussed at pycon I think, please correct me if I'm wrong. Cheers, fijal _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
