Bug 7183 and Python 2.6.4
I'd like to get a second opinion on bug 7183:
http://bugs.python.org/issue7183
The Boost folks have reported this as a regression in 2.6.3, making it a candidate for Python 2.6.4. IIUC, the latest version of Boost fixes the problem in their code, but if it really is a regression it could affect other projects and should probably be fixed.
Robert Collins from the Bazaar team pinged me on IRC and originally thought that they'd been bitten by this problem too, though he looked around and determined it probably did /not/ affect them after all. So we have only anecdotal evidence of a problem, and no reproducible test case.
If the Python 2.6.4 release is to be held up for this issue, we need to know today or tomorrow. Come the weekend, I'm going ahead with the tag and release. Holding up the release will mean another release candidate, and a wait of another week for the final.
So does anybody else think bug 7183 should be a release blocker for 2.6.4 final, or is even a legitimate but that we need to fix?
Thanks, -Barry
2009/10/22 Barry Warsaw barry@python.org:
So does anybody else think bug 7183 should be a release blocker for 2.6.4 final, or is even a legitimate but that we need to fix?
I think it cannot hold up a release with out a reproducible code snippet.
On Oct 22, 2009, at 10:47 AM, Benjamin Peterson wrote:
2009/10/22 Barry Warsaw barry@python.org:
So does anybody else think bug 7183 should be a release blocker for 2.6.4 final, or is even a legitimate but that we need to fix?
I think it cannot hold up a release with out a reproducible code snippet.
It may not be reproducible in standard Python, see David's follow up to the issue. If that holds true and we can't reproduce it, I agree we should not hold up the release for this.
-Barry
On Oct 22, 2009, at 11:04 AM, Barry Warsaw wrote:
On Oct 22, 2009, at 10:47 AM, Benjamin Peterson wrote:
2009/10/22 Barry Warsaw barry@python.org:
So does anybody else think bug 7183 should be a release blocker for 2.6.4 final, or is even a legitimate but that we need to fix?
I think it cannot hold up a release with out a reproducible code snippet.
It may not be reproducible in standard Python, see David's follow up to the issue. If that holds true and we can't reproduce it, I agree we should not hold up the release for this.
class Foo(property):
... __slots__=[] ...
x=Foo() x.__doc__ = "asdf"
Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'Foo' object attribute '__doc__' is read-only
You can't add arbitrary attributes to instances, since some instances don't have the slot to put them in.
Is that an equivalent demonstration to that which boost runs into? (except, it's using a C type not a python type).
James
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Barry Warsaw wrote:
On Oct 22, 2009, at 10:47 AM, Benjamin Peterson wrote:
2009/10/22 Barry Warsaw barry@python.org:
So does anybody else think bug 7183 should be a release blocker for 2.6.4 final, or is even a legitimate but that we need to fix?
I think it cannot hold up a release with out a reproducible code snippet.
It may not be reproducible in standard Python, see David's follow up to the issue. If that holds true and we can't reproduce it, I agree we should not hold up the release for this.
The fix for 5890 has a funny "smell" to me: copying __doc__ into the instance dict just feels wrong. How does that work with a pure Python class using slots? E.g.:
class MyProp(property): pass
class Foo(object): @property def bar(self): '''Get a bar.'''
@MyProp def baz(self): '''Get a baz.'''
print Foo.bar.__doc__ print Foo.baz.__doc__
class SlottedFoo(object): __slots__ = () @property def bar(self): '''Get a bar.'''
@MyProp def baz(self): '''Get a baz.'''
print SlottedFoo.bar.__doc__ print SlottedFoo.baz.__doc__
That being said, I can't this bug as a release blocker: people can either upgrade to super-current Boost, or stick with 2.6.2 until they can.
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com
On Thu, 22 Oct 2009 at 13:16, Tres Seaver wrote:
The fix for 5890 has a funny "smell" to me: copying __doc__ into the instance dict just feels wrong. How does that work with a pure Python class using slots? E.g.:
It doesn't. There's even a test to make sure it doesn't :) (It raises an attribute error.)
__doc__ is a funny beast. If someone can come up with a better fix for 5890, that would be great.
--David
Tres Seaver schrieb:
Barry Warsaw wrote:
On Oct 22, 2009, at 10:47 AM, Benjamin Peterson wrote:
2009/10/22 Barry Warsaw barry@python.org:
So does anybody else think bug 7183 should be a release blocker for 2.6.4 final, or is even a legitimate but that we need to fix?
I think it cannot hold up a release with out a reproducible code snippet.
It may not be reproducible in standard Python, see David's follow up to the issue. If that holds true and we can't reproduce it, I agree we should not hold up the release for this.
The fix for 5890 has a funny "smell" to me: copying __doc__ into the instance dict just feels wrong. How does that work with a pure Python class using slots? E.g.:
class MyProp(property): pass
class Foo(object): @property def bar(self): '''Get a bar.'''
@MyProp def baz(self): '''Get a baz.'''print Foo.bar.__doc__ print Foo.baz.__doc__
class SlottedFoo(object): __slots__ = () @property def bar(self): '''Get a bar.'''
@MyProp def baz(self): '''Get a baz.'''print SlottedFoo.bar.__doc__ print SlottedFoo.baz.__doc__
Works just fine. I think you meant
class MyProp(property): __slots__ = ()
Georg
On Thu, 2009-10-22 at 13:16 -0400, Tres Seaver wrote: ...
That being said, I can't this bug as a release blocker: people can either upgrade to super-current Boost, or stick with 2.6.2 until they can.
Thats the challenge Ubuntu faces: https://bugs.edge.launchpad.net/ubuntu/+source/boost1.38/+bug/457688
We've just announced our Karmic RC, boost 1.40 isn't released, and python 2.6.3 doesn't work with a released boost :(
-Rob
2009/10/22 Robert Collins robertc@robertcollins.net:
On Thu, 2009-10-22 at 13:16 -0400, Tres Seaver wrote: ...
That being said, I can't this bug as a release blocker: people can either upgrade to super-current Boost, or stick with 2.6.2 until they can.
Thats the challenge Ubuntu faces: https://bugs.edge.launchpad.net/ubuntu/+source/boost1.38/+bug/457688
We've just announced our Karmic RC, boost 1.40 isn't released, and python 2.6.3 doesn't work with a released boost :(
?? Boost 1.40 was released on 27th August, according to www.boost.org...
Paul.
On Thu, 2009-10-22 at 21:27 +0100, Paul Moore wrote:
2009/10/22 Robert Collins robertc@robertcollins.net:
On Thu, 2009-10-22 at 13:16 -0400, Tres Seaver wrote: ...
That being said, I can't this bug as a release blocker: people can either upgrade to super-current Boost, or stick with 2.6.2 until they can.
Thats the challenge Ubuntu faces: https://bugs.edge.launchpad.net/ubuntu/+source/boost1.38/+bug/457688
We've just announced our Karmic RC, boost 1.40 isn't released, and python 2.6.3 doesn't work with a released boost :(
?? Boost 1.40 was released on 27th August, according to www.boost.org...
Oh bah, teach me to trust comments in bug reports :)
Still, a full release is high risk, one of the Ubuntu devs is looking for the single patch they added to fix things.
-Rob
On Oct 22, 2009, at 3:53 PM, Robert Collins wrote:
On Thu, 2009-10-22 at 13:16 -0400, Tres Seaver wrote: ...
That being said, I can't this bug as a release blocker: people can either upgrade to super-current Boost, or stick with 2.6.2 until they can.
Thats the challenge Ubuntu faces: https://bugs.edge.launchpad.net/ubuntu/+source/boost1.38/+bug/457688
We've just announced our Karmic RC, boost 1.40 isn't released, and python 2.6.3 doesn't work with a released boost :(
Aren't we stuck either way though? :(
-Barry
On Oct 22, 2009, at 3:53 PM, Robert Collins wrote:
On Thu, 2009-10-22 at 13:16 -0400, Tres Seaver wrote: ...
That being said, I can't this bug as a release blocker: people can either upgrade to super-current Boost, or stick with 2.6.2 until they can.
Thats the challenge Ubuntu faces: https://bugs.edge.launchpad.net/ubuntu/+source/boost1.38/+bug/457688
We've just announced our Karmic RC, boost 1.40 isn't released, and python 2.6.3 doesn't work with a released boost :(
If I were running a Linux distro, I'd revert the patch in 2.6.3.
And if I were running a Python release process, I'd revert that patch for python 2.6.4, and reopen the bug that it fixed, so a less-breaky patch can be made.
James
While I think there is some risk of exposure on this bug, I haven't yet heard a compelling argument for delaying 2.6.4 final for it. I think we should go ahead and do the release this Sunday as planned with the code from 2.6.4rc2.
If you strongly disagree, please private email me. Otherwise... there's always 2.6.5! :)
-Barry
Speaking of the __doc__ property, I just noticed the following thing on py3k:
class C: pass
...
C.__doc__ = "hop"
Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: attribute '__doc__' of 'type' objects is not writable
Is this deliberate?
Antoine.
Speaking of the __doc__ property, I just noticed the following thing on py3k:
class C: pass
...
C.__doc__ = "hop"
Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: attribute '__doc__' of 'type' objects is not writable
Happens also with new style classes in python 2.x:
Python 2.5.1 (r251:54863, Oct 30 2007, 13:45:26) [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
class C(object): pass
...
C.__doc__ = 'hello'
Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: attribute '__doc__' of 'type' objects is not writable
But not with old style classes:
Python 2.5.1 (r251:54863, Oct 30 2007, 13:45:26) [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
class C: pass
...
C.__doc__ = 'hello'
Cheers, Daniel
On Thu, Oct 22, 2009 at 9:45 AM, Antoine Pitrou solipsis@pitrou.net wrote:
Speaking of the __doc__ property, I just noticed the following thing on py3k:
class C: pass
...
C.__doc__ = "hop"
Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: attribute '__doc__' of 'type' objects is not writable
Is this deliberate?
Yes.
Guido van Rossum <guido <at> python.org> writes:
On Thu, Oct 22, 2009 at 9:45 AM, Antoine Pitrou <solipsis <at> pitrou.net>
wrote:
Speaking of the __doc__ property, I just noticed the following thing
on py3k:
class C: pass
...
C.__doc__ = "hop"
Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: attribute '__doc__' of 'type' objects is not writable
Is this deliberate?
Yes.
I might add why I was asking this question. I was trying to demonstrate the use of class decorators and the simplest example I found was to add a docstring to the class. And I was surprised when I saw the following fail with the aforementioned exception:
def classdeco(cls): cls.__doc__ = "decorated!" return cls
@classdeco class C: pass
Regards
Antoine.
On Thu, Oct 22, 2009 at 1:25 PM, Antoine Pitrou solipsis@pitrou.net wrote: ..
I might add why I was asking this question. I was trying to demonstrate the use of class decorators and the simplest example I found was to add a docstring to the class.
I always thought that read-only __doc__ was an artifact of new classes evolving from (C-implemented) types. IIRC, NumPy project implemented a somewhat elaborate hack to allow docstrings to be added to C-implemented classes in a .py file.
Well __doc__ isn't a normal attribute -- it doesn't follow inheritance rules.
On Thu, Oct 22, 2009 at 10:25 AM, Antoine Pitrou solipsis@pitrou.net wrote:
Guido van Rossum <guido <at> python.org> writes:
On Thu, Oct 22, 2009 at 9:45 AM, Antoine Pitrou <solipsis <at> pitrou.net>
wrote:
Speaking of the __doc__ property, I just noticed the following thing
on py3k:
class C: pass
...
C.__doc__ = "hop"
Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: attribute '__doc__' of 'type' objects is not writable
Is this deliberate?
Yes.
I might add why I was asking this question. I was trying to demonstrate the use of class decorators and the simplest example I found was to add a docstring to the class. And I was surprised when I saw the following fail with the aforementioned exception:
def classdeco(cls): cls.__doc__ = "decorated!" return cls
@classdeco class C: pass
Regards
Antoine.
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/guido%40python.org
On Oct 22, 2009, at 1:58 PM, Guido van Rossum wrote:
Well __doc__ isn't a normal attribute -- it doesn't follow inheritance rules.
Maybe we could add a ticket to flag this in the docs.
Is __doc__ not normal due to its general underscorishness, or is it not normal because it isn't?
Any others that deserve special notice, while we're at it?
Thanks,
S
On Thu, Oct 22, 2009 at 11:18, ssteinerX@gmail.com ssteinerx@gmail.comwrote:
On Oct 22, 2009, at 1:58 PM, Guido van Rossum wrote:
Well __doc__ isn't a normal attribute -- it doesn't follow inheritance
rules.
Maybe we could add a ticket to flag this in the docs.
Sure, go for it.
Is __doc__ not normal due to its general underscorishness, or is it not normal because it isn't?
I honestly don't follow that sentence. But __doc__ is special because of its use; documenting how to use of an object. In this case when you call something like help() on an instance of an object it skips the instance's value for __doc__ and goes straight to the defining class and stops there as you don't care how a subclass says to use itself as that is not what you are working with.
Any others that deserve special notice, while we're at it?
Don't know.
On Oct 22, 2009, at 2:39 PM, Brett Cannon wrote:
On Thu, Oct 22, 2009 at 11:18, ssteinerX@gmail.com <ssteinerx@gmail.com
wrote:
On Oct 22, 2009, at 1:58 PM, Guido van Rossum wrote:
Well __doc__ isn't a normal attribute -- it doesn't follow inheritance rules.
Maybe we could add a ticket to flag this in the docs. Sure, go for it.
Filed: http://bugs.python.org/issue7186
Is __doc__ not normal due to its general underscorishness, or is it not normal because it isn't?
I honestly don't follow that sentence.
It means, is it special because it's a "special" i.e. __X__ type attribute or because of something special about __doc__ itself, independent of it being a "special attribute".
But __doc__ is special because of its use; documenting how to use of an object. In this case when you call something like help() on an instance of an object it skips the instance's value for __doc__ and goes straight to the defining class and stops there as you don't care how a subclass says to use itself as that is not what you are working with.
Any others that deserve special notice, while we're at it?
Don't know.
Ok, issue recorded.
Thanks,
S
Brett Cannon <brett <at> python.org> writes:
I honestly don't follow that sentence. But __doc__ is special because of its use; documenting how to use of an object. In this case when you call something like help() on an instance of an object it skips the instance's value for __doc__ and goes straight to the defining class and stops there as you don't care how a subclass says to use itself as that is not what you are working with.
I don't really understand how this explains the read-only __doc__. I am talking about modifying __doc__ on a class, not on an instance. (sure, a new-style class is also an instance of type, but still...)
Antoine.
On Thu, Oct 22, 2009 at 1:49 PM, Antoine Pitrou solipsis@pitrou.net wrote:
Brett Cannon <brett <at> python.org> writes:
I honestly don't follow that sentence. But __doc__ is special because of its use; documenting how to use of an object. In this case when you call something like help() on an instance of an object it skips the instance's value for __doc__ and goes straight to the defining class and stops there as you don't care how a subclass says to use itself as that is not what you are working with.
I don't really understand how this explains the read-only __doc__. I am talking about modifying __doc__ on a class, not on an instance. (sure, a new-style class is also an instance of type, but still...)
Antoine, it's not clear from the questions you're asking whether you've read the code in typobject.c that implements __doc__ or not.
Le jeudi 22 octobre 2009 à 13:59 -0700, Guido van Rossum a écrit :
I don't really understand how this explains the read-only __doc__. I am talking about modifying __doc__ on a class, not on an instance. (sure, a new-style class is also an instance of type, but still...)
Antoine, it's not clear from the questions you're asking whether you've read the code in typobject.c that implements __doc__ or not.
Ah, well I haven't :-/ My bad.
Regards
Antoine.
On Fri, 23 Oct 2009 05:39:53 am Brett Cannon wrote:
Is __doc__ not normal due to its general underscorishness, or is it not normal because it isn't?
I honestly don't follow that sentence. But __doc__ is special because of its use; documenting how to use of an object. In this case when you call something like help() on an instance of an object it skips the instance's value for __doc__ and goes straight to the defining class and stops there as you don't care how a subclass says to use itself as that is not what you are working with.
Classes don't normally inherit behaviour from their subclasses. Presumably you meant superclass.
I expected __doc__ to be just like the other double-underscore objects: lookup skips the instance and goes to the class, then follows the normal rules of inheritance. Consequently I've just discovered that a few of my classes, which I assumed inherited __doc__, don't actually have a docstring. This has consequences beyond help(obj) not working as expected: doctests which I thought were running aren't.
Magic behaviour like this is nasty because it breaks the Rule of Least Astonishment. I thought I understood Python's object model and it's rules of inheritance, but not only do double-underscore attributes follow a different rule for inheritance than other attributes, but __doc__ follows a different rule than other double-underscore attributes.
Steven D'Aprano wrote:
On Fri, 23 Oct 2009 05:39:53 am Brett Cannon wrote:
Is __doc__ not normal due to its general underscorishness, or is it not normal because it isn't?
I honestly don't follow that sentence. But __doc__ is special because of its use; documenting how to use of an object. In this case when you call something like help() on an instance of an object it skips the instance's value for __doc__ and goes straight to the defining class and stops there as you don't care how a subclass says to use itself as that is not what you are working with.
Classes don't normally inherit behaviour from their subclasses. Presumably you meant superclass.
I expected __doc__ to be just like the other double-underscore objects: lookup skips the instance and goes to the class, then follows the normal rules of inheritance. Consequently I've just discovered that a few of my classes, which I assumed inherited __doc__, don't actually have a docstring. This has consequences beyond help(obj) not working as expected: doctests which I thought were running aren't.
Magic behaviour like this is nasty because it breaks the Rule of Least Astonishment. I thought I understood Python's object model and it's rules of inheritance, but not only do double-underscore attributes follow a different rule for inheritance than other attributes, but __doc__ follows a different rule than other double-underscore attributes.
This actually breaks a recipe I recently suggested in python-ideas, where I recommended inheriting from a namedtuple instance in order to insert additional argument validity checks in __new__.
Probably not invalid for it to break there though - in the case of that recipe, the default docstring from the parent class really should be replaced with one that details the additional constraints being placed on the arguments. Then again, the parent class docstring wouldn't have been wrong - merely incomplete.
The point you mentioned about doctests silently failing to run strikes me as a pretty major glitch due to this behaviour though. Having a base class that defines the doctests to run in its docstring and then creating subclasses to specialise the test execution sounds like a perfectly reasonable use case to me (even though I personally tend to write unittest based test rather than doctest based ones).
Cheers, Nick.
participants (17)
-
Alexander Belopolsky -
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Brett Cannon -
Daniel Fetchinson -
Georg Brandl -
Guido van Rossum -
James Y Knight -
Nick Coghlan -
Paul Moore -
R. David Murray -
Robert Collins -
ssteinerX＠gmail.com -
Steven D'Aprano -
Tres Seaver -
Yuvgoog Greenle