Hello, I haven't seen any strong objections, so I would like to go ahead and commit PEP 3155 (*) soon. Is anyone against it? (*) "Qualified name for classes and functions" http://www.python.org/dev/peps/pep-3155/ Thank you Antoine.
On Nov 18, 2011, at 09:14 PM, Antoine Pitrou wrote:
I haven't seen any strong objections, so I would like to go ahead and commit PEP 3155 (*) soon. Is anyone against it?
(*) "Qualified name for classes and functions" http://www.python.org/dev/peps/pep-3155/
I'm still not crazy about the attribute name, although I appreciate you including the discussion in the PEP. Have you identified a BDFOP that might be able to pronounce on the choice? Or perhaps Guido would like to weigh in? The PEP says that the qualified name deliberately does not include the module name, but it doesn't explain why. I think it should (explain why). I'd like the PEP to explain why this is a better solution than re-establishing introspectability that was available through unbound methods. Cheers, -Barry
On Fri, 18 Nov 2011 18:15:28 -0500
Barry Warsaw
On Nov 18, 2011, at 09:14 PM, Antoine Pitrou wrote:
I haven't seen any strong objections, so I would like to go ahead and commit PEP 3155 (*) soon. Is anyone against it?
(*) "Qualified name for classes and functions" http://www.python.org/dev/peps/pep-3155/
I'm still not crazy about the attribute name, although I appreciate you including the discussion in the PEP.
Well, the other propositions still seem worse to me. "Qualified" is reasonably accurate, and "qualname" is fairly short and convenient (I would hate to type "__qualifiedname__" or "__qualified_name__" in full). In the same vein, we have __repr__ which may seem weird at first sight :)
Have you identified a BDFOP that might be able to pronounce on the choice?
No. Perhaps I was irenic in hoping that no opposition == no need to get an official pronouncement :-)
The PEP says that the qualified name deliberately does not include the module name, but it doesn't explain why. I think it should (explain why).
I'd like the PEP to explain why this is a better solution than re-establishing introspectability that was available through unbound methods.
I've added explanations for these two points. Do they satisfy your expectations? cheers Antoine.
19.11.11 01:54, Antoine Pitrou написав(ла):
Well, the other propositions still seem worse to me. "Qualified" is reasonably accurate, and "qualname" is fairly short and convenient (I would hate to type "__qualifiedname__" or "__qualified_name__" in full). In the same vein, we have __repr__ which may seem weird at first sight :)
What about __reprname__?
On Sat, Nov 19, 2011 at 4:48 PM, Serhiy Storchaka
19.11.11 01:54, Antoine Pitrou написав(ла):
Well, the other propositions still seem worse to me. "Qualified" is reasonably accurate, and "qualname" is fairly short and convenient (I would hate to type "__qualifiedname__" or "__qualified_name__" in full). In the same vein, we have __repr__ which may seem weird at first sight :)
What about __reprname__?
Antoine only mentioned 'repr' as being an abbreviation for 'representation', just as 'qualname' will be an abbreviation for 'qualified name'. The "less ambiguous repr()" use case is just one minor aspect of the new qualified names, even if it's the most immediately visible, so using 'repr' in the attribute name would give people all sorts of wrong ideas about the scope of its utility. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I haven't seen any strong objections, so I would like to go ahead and commit PEP 3155 (*) soon. Is anyone against it?
I'm not against it, but I have some questions. Does you a working implementing? Do you have a patch for issue #9276 using __qualname__? Maybe not a fully working patch, but a proof-of-concept? Could you add examples on instances? I suppose that it gives the same result than classes: C.__qualname__ == C().__qualname__ C.f.__qualname__ == C().f.__qualname__ Le 19/11/2011 00:15, Barry Warsaw a écrit :
I'd like the PEP to explain why this is a better solution than re-establishing introspectability that was available through unbound methods.
__qualname__ works also on nested functions. Is it a new feature? Or was it already possible in Python 2 to compute the qualified name? Victor
On Sat, 19 Nov 2011 03:31:09 +0100
Victor Stinner
I haven't seen any strong objections, so I would like to go ahead and commit PEP 3155 (*) soon. Is anyone against it?
I'm not against it, but I have some questions.
Does you a working implementing?
I suppose the question is about a working implementation :) http://hg.python.org/features/pep-3155
Do you have a patch for issue #9276 using __qualname__? Maybe not a fully working patch, but a proof-of-concept?
No. That's part of PEP 3154.
Could you add examples on instances? I suppose that it gives the same result than classes:
C.__qualname__ == C().__qualname__ C.f.__qualname__ == C().f.__qualname__
No. You have to use C().__class__.__qualname__. Same as C().__class__.__name__, really.
Le 19/11/2011 00:15, Barry Warsaw a écrit :
I'd like the PEP to explain why this is a better solution than re-establishing introspectability that was available through unbound methods.
__qualname__ works also on nested functions. Is it a new feature? Or was it already possible in Python 2 to compute the qualified name?
It's a new feature indeed. Regards Antoine.
I've approved the latest version of this PEP. Congrats, Antoine!
--Guido
On Fri, Nov 18, 2011 at 12:14 PM, Antoine Pitrou
Hello,
I haven't seen any strong objections, so I would like to go ahead and commit PEP 3155 (*) soon. Is anyone against it?
(*) "Qualified name for classes and functions" http://www.python.org/dev/peps/pep-3155/
Thank you
Antoine.
-- --Guido van Rossum (python.org/~guido)
participants (6)
-
Antoine Pitrou -
Barry Warsaw -
Guido van Rossum -
Nick Coghlan -
Serhiy Storchaka -
Victor Stinner