[Python-Dev] PEP 370 and IronPython

[Brett Cannon]

On Sat, Oct 10, 2009 at 10:31, Michael Foord <fuzzyman at voidspace.org.uk>wrote:

> Brett Cannon wrote:
>
>>
>>
>> On Fri, Oct 9, 2009 at 11:32, Michael Foord <fuzzyman at voidspace.org.uk<mailto:
>> 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.
>>
>
> The IronPython team currently have legal issues distributing modified
> versions of the standard library (Dino can correct me if I'm wrong here).
>
> That aside, I think that were a Python feature is implemented in such a way
> as to preclude compatibility with other implementations then we should see
> it as a bugfix to correct it.
>
> I can't see why you should feel uncomfortable (beyond general principle),
> it seems clear that this change can't affect users of ClassicPython. It is
> not only IronPython that will benefit but also Jython when they port to
> Python 2.6.
>

It's just principle. I'm not going to fight this as no one else has spoken
up with my view and both Dino and Frank would like this to happen.

The one unfortunate thing about this proposal is how this is going to mean I
have to install a package potentially four times if I want it available to
all possible Python interpreters. Then again, the chances of anyone beyond
the people on this mailing list using more than a single interpreter
regularly is so small that bothering to add support for yet another user
directory that works on any Python interpreter will not be worth it.

-Brett




> As a general rule the alternative implementations will only start a serious
> port once a version is released and into maintenance mode. If we aren't able
> to fix compatibility issues then the implementations will always have to
> maintain their own patch sets that may or may not get merged back in (or in
> the case of implementations with awkward legal departments they'll have to
> ship bugs).
>
> All the best,
>
> Michael
>
>
>
>
>>    On 9 Oct 2009, at 19:00, Brett Cannon <brett at python.org
>>    <mailto:brett at python.org>> wrote:
>>
>>
>>>
>>>    On Fri, Oct 9, 2009 at 04:53, Michael Foord
>>>    <fuzzyman at voidspace.org.uk <mailto: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.dont_write_bytecode 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
>>>
>>
>>
>>
>
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091010/9828898b/attachment-0001.htm>