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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4