On Mon, Oct 24, 2011 at 4:36 PM, Steven D'Aprano <steve@pearwood.info> wrote:
Guido van Rossum wrote:
That is putting words in my mouth. There's no intent to unbless x.__name__, period. Also, there's no intent to bless str(x) as x.__name__ if you want the name. The only intent is to make what gets printed if you print a function, class or module to be less verbose.
I'm sorry about that, I was describing the proposal as best I understood it.
Okay.
Once this change goes ahead, under what circumstances would you expect people to continue using cls.__name__ (other than for backwards compatibility)?
Whenever they want to know what the name is, use the name to look something up, to compare it to a list of known names, you name it...
When beginners ask me "how do I get the name of a class?", what answer should I give?
Use .__name__, definitely.
For example, I have code that does things like this:
raise TypeError('expected a string but got %s' % type(arg).__name__)
In the future, I expect that should be written like this:
raise TypeError('expected a string but got %s' % type(arg))
Yes, because here the point is to quickly put some useful info in a message. Likely the code *already* looks like the second form and we've just made it prettier.
That's all I meant by "unbless". I didn't mean to imply that __name__ would go away, only that it would cease to be the One Obvious Way to get the name. If I'm wrong about this, then I'm genuinely confused and don't understand the motivation for this change.
Depends on what you want to do with it. If you're just showing it to a user, str() is your friend. If you want to compute with it, parse it, etc., use .__name__. You may think this violates TOOWTDI, but as I've said before, that was a white lie (as well a cheeky response to Perl's slogan around 2000). Being able to express intent (to human readers) often requires choosing between multiple forms that do essentially the same thing, but look different to the reader. -- --Guido van Rossum (python.org/~guido)