[Python-Dev] PEP 370 and IronPython

[Michael Foord]

Brett Cannon wrote:
>
>
> On Sat, Oct 10, 2009 at 10:31, Michael Foord 
> <fuzzyman at voidspace.org.uk <mailto: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>
>         <mailto: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.
>

It is unfortunate, there are quite a few modules that I use with both 
IronPython and ClassicPython. Unfortunately there are many others where 
I have to make modifications or replace components (especially C 
extensions). It is these modules that require changes that mean separate 
site-packages directories are needed.

To be honest, at the moment I tend to bundle all third party 
dependencies in with my IronPython projects. As distutils support for 
IronPython improves I hope that will change.

All the best,


Michael

> -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>
>            <mailto: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>
>             <mailto: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
>
>
>


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog