msg148087 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2011-11-21 20:53 |
Here is an issue covering PEP 3155 implementation. Hopefully a "review" link will appear in front of the hg repo URL. |
|
|
msg148090 - (view) |
Author: STINNER Victor (vstinner) *  |
Date: 2011-11-21 21:18 |
I just have a comment: "XXX" should be replaced in "Python 3.3a0 3200 XXX". |
|
|
msg148121 - (view) |
Author: Éric Araujo (eric.araujo) *  |
Date: 2011-11-22 15:25 |
Nothing to say; waiting for a doc update. |
|
|
msg148214 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2011-11-23 23:29 |
New patch addressing Benjamin's and Victor's comments. |
|
|
msg148217 - (view) |
Author: STINNER Victor (vstinner) *  |
Date: 2011-11-24 00:13 |
Ah, PyFunction_NewWithQualName is now public. Why an upper P in "PyFunction_NewWithQualName"? If you use an upper P, it should use an underscore in Python: __qual_name__ to be consistent. So I suggest to change the C name :-) PyFunction_NewWithQualname or PyFunction_NewWithQualifiedName. I don't have a preference between these two choices. |
|
|
msg148219 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2011-11-24 00:28 |
> Why an upper P in "PyFunction_NewWithQualName"? If you use an upper P, > it should use an underscore in Python: __qual_name__ to be consistent. __getattr__ / PyObject_GetAttr. |
|
|
msg148254 - (view) |
Author: Éric Araujo (eric.araujo) *  |
Date: 2011-11-24 14:07 |
Doc patch looks good. |
|
|
msg148289 - (view) |
Author: Richard Oudkerk (sbt) *  |
Date: 2011-11-24 21:50 |
Is it intended that pickle will use __qualname__? |
|
|
msg148290 - (view) |
Author: Alyssa Coghlan (ncoghlan) *  |
Date: 2011-11-24 22:49 |
Yes, but that can be a separate patch - step 1 is to make the attribute available, then relevant modules can subsequently be updated to use it as appropriate. |
|
|
msg148294 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2011-11-25 00:33 |
> Is it intended that pickle will use __qualname__? That's part of the plan for PEP 3154, yes. |
|
|
msg148345 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2011-11-25 18:03 |
New changeset e1dbc72bd97f by Antoine Pitrou in branch 'default': PEP 3155 / issue #13448: Qualified name for classes and functions. http://hg.python.org/cpython/rev/e1dbc72bd97f |
|
|
msg148347 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2011-11-25 18:44 |
Now committed together with docs and a what's new entry. Thanks for the reviews! |
|
|
msg148368 - (view) |
Author: Richard Oudkerk (sbt) *  |
Date: 2011-11-25 23:52 |
There are some callables which are missing __qualname__: method_descriptor wrapper_descriptor builtin_function_or_method For the descriptors, at least, obj.__qualname__ should be equivalent to obj.__objclass__.__qualname__ + '.' + obj.__name__ Were these overlooked? PS C:\Repos\cpython> .\PCbuild\python_d Python 3.3.0a0 (default, Nov 25 2011, 22:14:28) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle [66213 refs] >>> attribs = ('__class__', '__name__', '__qualname__') [66220 refs] >>> for o in (pickle.Pickler, pickle.Pickler.dump, object.__init__, min): ... print([getattr(o, a, None) for a in attribs]) ... [<class 'type'>, 'Pickler', 'Pickler'] [<class 'method_descriptor'>, 'dump', None] [<class 'wrapper_descriptor'>, '__init__', None] [<class 'builtin_function_or_method'>, 'min', None] [66265 refs] Also I notice that bound methods have a misleading __qualname__: >>> class A: ... def f(self): pass ... [66348 refs] >>> A().f.__qualname__ 'A.f' Maybe this should be 'A().f' instead. |
|
|
msg148372 - (view) |
Author: Richard Oudkerk (sbt) *  |
Date: 2011-11-26 00:22 |
For builtin_function_or_method it seems obj.__qualname__ should be obj.__self__.__qualname__ + '.' + obj.__name__ |
|
|
msg148375 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2011-11-26 00:31 |
> There are some callables which are missing __qualname__: > > method_descriptor > wrapper_descriptor > builtin_function_or_method > > For the descriptors, at least, obj.__qualname__ should be equivalent to > > obj.__objclass__.__qualname__ + '.' + obj.__name__ > > Were these overlooked? Indeed, they were overlooked. Due to the way they are instantiated, though, it would be quite a bit harder to devise a __qualname__ for them. > Also I notice that bound methods have a misleading __qualname__: > > >>> class A: > ... def f(self): pass > ... > [66348 refs] > >>> A().f.__qualname__ > 'A.f' > > Maybe this should be 'A().f' instead. I am a bit surprised that this works at all. Apparently attribute lookups are redirected to the underlying function. |
|
|
msg149203 - (view) |
Author: Jesús Cea Avión (jcea) *  |
Date: 2011-12-11 01:54 |
I am evaluating the use of "__qualname__" in my dtrace probes (issue #13405) and I see things like this: """ >>> def a() : ... class b() : ... pass ... return b() ... >>> c=a() >>> c <__main__.a..b object at 0xfe37f3ac> >>> c.__qualname__ Traceback (most recent call last): File "", line 1, in AttributeError: 'b' object has no attribute '__qualname__' >>> a <function a at 0xfe3800bc> >>> a.__qualname__ 'a' """ I guess the class should have a __qualname__ too, haven't it? |
|
|
msg149205 - (view) |
Author: Alyssa Coghlan (ncoghlan) *  |
Date: 2011-12-11 02:18 |
No, it's only class objects that have __name__ and __qualname__, not class instances. |
|
|
msg156235 - (view) |
Author: Matt Joiner (anacrolix) |
Date: 2012-03-18 07:47 |
Doc/library/dis.rst wasn't updated for the extra pop introduced to MAKE_CLOSURE opcode. |
|
|