Brett Cannon wrote:
On Sat, Oct 10, 2009 at 10:31, Michael Foord
<fuzzy...@voidspace.org.uk <mailto:fuzzy...@voidspace.org.uk>> wrote:
Brett Cannon wrote:
On Fri, Oct 9, 2009 at 11:32, Michael Foord
<fuzzy...@voidspace.org.uk <mailto:fuzzy...@voidspace.org.uk>
<mailto:fuzzy...@voidspace.org.uk
<mailto:fuzzy...@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 <br...@python.org
<mailto:br...@python.org>
<mailto:br...@python.org <mailto:br...@python.org>>> wrote:
On Fri, Oct 9, 2009 at 04:53, Michael Foord
<fuzzy...@voidspace.org.uk
<mailto:fuzzy...@voidspace.org.uk>
<mailto:fuzzy...@voidspace.org.uk
<mailto:fuzzy...@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
_______________________________________________
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
