[Python-Dev] PEP 370 and IronPython (original) (raw)

Brett Cannon brett at python.org
Fri Oct 9 20:43:06 CEST 2009

On Fri, Oct 9, 2009 at 11:32, Michael Foord <fuzzyman at voidspace.org.uk>wrote:

The only change in semantics I'm proposing is for users of IronPython 2.6 which is not even at final release yet. CPython users would be unaffected.

Then why can't IronPython patch site.py to do what they want? I still feel uncomfortable changing site.py for this in a micro release.

Sorry for top-posting, mobile device.

Aahz was the most adamant hater of top-posting and he isn't subscribed to python-dev anymore, so whatever.

-Brett

Michael

-- http://www.ironpythoninaction.com On 9 Oct 2009, at 19:00, Brett Cannon <brett at python.org> wrote:

On Fri, Oct 9, 2009 at 04:53, Michael Foord < <fuzzyman at voidspace.org.uk> fuzzyman at voidspace.org.uk> wrote: Christian Heimes wrote:

Michael Foord wrote:

I really like this scheme. The important thing for IronPython is that we can get it into Python 2.6 (along with other fixes to make distutils compatible with IronPython - like not attempting to bytecode-compile when sys.dontwritebytecode is True).

I don't think my proposal will land into 2.6. The changes are too severe for a bug fix release. Right, certainly not adding umpteen new sys attributes. :-) The problem is that the alternative implementations run well behind Python-trunk, indeed it doesn't really make sense for them to put a lot of effort into implementing a version that is still in development. The result is that they discover incompatibilites after a version has gone into 'bugfix only' mode. Whilst the fix you have described (add information to sys that is used by site.py and distutils) is ideal it can only go into 2.7. I would still like to see a fix in 2.6 - even if it is simple logic in site.py using sys.platform (if sys.platform == 'cli'; elif sys.platform == 'java' etc). That way IronPython 2.6 is able to be compatible with Python 2.6. This logic might need duplicating in distutils (I haven't looked at how distutils works out where the user site-packages folder is), but it is a 'maintenance only' fix. But it's still a change in semantics. Tossing this into 2.6 would mean that anyone who has worked around the current behaviour is going to have a busted install. -Brett -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20091009/10eba5b7/attachment.htm>

More information about the Python-Dev mailing list