Re: [Python-Dev] Changes to decimal.py
Tim Peters wrote: > can wait a couple months, I'd be happy to own it. A possible saving > grace for ln() is that while the mathematical function is one-to-one, I'm working right now in making the old operation to pass the new tests ok. Soon I'll cut a branch to work publicly on this (good idea from Raymond), and I'll be pleased to get your help here. Two months is ok: the "updated decimal" won't be finished before that. Thank you! -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new subscriber looking for grunt work
Martin v. Löwis wrote: > an activity that is always worthwhile is bug and patch review. Pick a > patch or a bug report that hasn't seen any feedback (there are, > unfortunately, plenty of them), and try to analyse it. Sergio, welcome. As Martin said, bugs and patch revision is a fruitful activity, for Python, and for you. You can use these pages to have a grand vision of which bugs and patchs we have still open and start choosing your first: http://www.taniquetil.com.ar/facundo/py_bugs_00.html http://www.taniquetil.com.ar/facundo/py_patchs_00.html Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_normalization failures across communitybuildbots
On 4/16/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Collin Winter] > > This should be fixed in r54844. The problem was that the availability > > of the urlfetch resource wasn't being checked early enough and so > > test_support.run_suite() was converting the ResourceDenied exception > > into a TestError instance. This wasn't showing up on other machines > > since the urlfetch'd files weren't being cleaned out between test > > runs. > > Can you add code to clean them out between runs? I'll see what I can do. Collin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] distutils mixes 32/64bit binaries
On the platforms that can run both 32 and 64bit python, such as
x86_64, distutils builds both 32 and 64 bit libraries in the same
directory such as build/lib.linux-x86_64-2.5.
This can be easily fixed by placing 64 bit libraries in
build/lib64.linux-x86_64-2.5 instead.
On the other hand it may be time to revisit use of os.uname in
distutils' get_platform to determine the target directory. In the
environments that can run python interpreters compiled for different
architectures, distutils' get_platform should return the platform for
which the interpreter was built, not the platform on which it runs.
Similar problem exists with the default install directory
$prefix/lib/python2.5/lib-dynload. 64-bit libraries should probably go
to $prefix/lib/python2.5/lib64-dynload instead.
I've noticed that there was a similar proposal to use $prefix/lib64
for 64bit binary components, but it was quickly rejected:
http://mail.python.org/pipermail/python-dev/2006-November/070044.html
In my view, following LSB spirit would suggest splitting pythonX.Y
tree into platform dependent part (*.so) that would go under
$prefix/lib or $prefix/lib64 and a platform independent part
(*.py{,c,o}) that would go under $prefix/share. This, of course, would
be a much bigger change than the lib64-dynload band aid that I am
proposing here.
PS: As a data point, the R project has made the following changes to
their program to deal with this issue:
"""
o LDFLAGS now defaults to -L/usr/local/lib64 on most Linux
64-bit OSes (but not ia64). The use of lib/lib64 can be
overridden by the new variable LIBnn.
o The default installation directory is now ${prefix}/${LIBnn}/R,
/usr/local/lib64/R on most 64-bit Linux OSes and /usr/local/lib/R
elsewhere.
"""
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] minidom -> new-style classes?
I'm working on minidom's DOM Level 1 compliance, targeting Python 2.6. We have some bugs involving DOM property behavior. For example, setting the nodeValue attribute of an Element is supposed to have no effect. We don't implement this. The right way to implement these quirks is using new-style classes and properties. Right now minidom uses old-style classes and lots of hackery, and it's pretty broken. (Another example--there is an Attr._set_prefix method, but it is *not* called from __setattr__.) Surely nobody is subclassing these classes. You don't subclass DOM interfaces--the DOM doesn't work that way. So this change should be OK. Right? -j ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] minidom -> new-style classes?
On 4/17/07, Jason Orendorff <[EMAIL PROTECTED]> wrote: > Surely nobody is subclassing these classes. You don't subclass DOM > interfaces--the DOM doesn't work that way. So this change should be > OK. Right? People are definitely subclassing those classes: http://www.google.com/codesearch?hl=en&lr=&q=class%5Cs%2B.%2B%5C%28.*minidom%5C.&btnG=Search Whether any of those uses will break if switched to new-style class, I can't say. Collin Winter ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] minidom -> new-style classes?
On Tuesday 17 April 2007 22:37, Jason Orendorff wrote: > The right way to implement these quirks is using new-style classes and > properties. Right now minidom uses old-style classes and lots of > hackery, and it's pretty broken. (Another example--there is an > Attr._set_prefix method, but it is *not* called from __setattr__.) Yes, it's truly vile. Better than it used to be, but There's also some vague attempt at supporting the Python CORBA IDL mapping, since the W3C DOM specifications use that. I expect the support is incomplete at best. > Surely nobody is subclassing these classes. You don't subclass DOM > interfaces--the DOM doesn't work that way. So this change should be > OK. Right? There are people who've tried building new DOM implementations by subclassing the minidom classes to get most of the behavior. I'm don't know the status of any of these implementations, but changes to these classes have proved difficult due to this and the possibility of breaking pickles (amazed me, that one did!). I'd love to see a sane implementation, using new-style classes and properties, but as long as we've got to support existing applications, we're pretty well hosed as far as xml.dom.minidom is concerned. A new DOM implementation conforming to the W3C recommendations would be nice, but I'd really rather see an XML object model that doesn't suck, but that supports as much of the information found in the W3C DOM as possible. Something based more on the ElementTree API, perhaps. The value of the W3C-approved API has certainly turned out to be more decoy than anything. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] minidom -> new-style classes?
Perhaps a rewrite could target 3.0 and 2.6 could use a backported version of this *if* py3k compatibility mode is enabled? I'd love to see at least the 3.0 version cleaned up. --Guido On 4/17/07, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote: > On Tuesday 17 April 2007 22:37, Jason Orendorff wrote: > > The right way to implement these quirks is using new-style classes and > > properties. Right now minidom uses old-style classes and lots of > > hackery, and it's pretty broken. (Another example--there is an > > Attr._set_prefix method, but it is *not* called from __setattr__.) > > Yes, it's truly vile. Better than it used to be, but > > There's also some vague attempt at supporting the Python CORBA IDL mapping, > since the W3C DOM specifications use that. I expect the support is > incomplete at best. > > > Surely nobody is subclassing these classes. You don't subclass DOM > > interfaces--the DOM doesn't work that way. So this change should be > > OK. Right? > > There are people who've tried building new DOM implementations by subclassing > the minidom classes to get most of the behavior. I'm don't know the status > of any of these implementations, but changes to these classes have proved > difficult due to this and the possibility of breaking pickles (amazed me, > that one did!). > > I'd love to see a sane implementation, using new-style classes and properties, > but as long as we've got to support existing applications, we're pretty well > hosed as far as xml.dom.minidom is concerned. > > A new DOM implementation conforming to the W3C recommendations would be nice, > but I'd really rather see an XML object model that doesn't suck, but that > supports as much of the information found in the W3C DOM as possible. > Something based more on the ElementTree API, perhaps. The value of the > W3C-approved API has certainly turned out to be more decoy than anything. > > > -Fred > > -- > Fred L. Drake, Jr. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
