[Python-Dev] str vs. unicode (original) (raw)
Walter Dörwald walter at livinglogic.de
Tue Jan 25 23:13:08 CET 2005
- Previous message: [Python-Dev] __str__ vs. __unicode__
- Next message: [Python-Dev] __str__ vs. __unicode__
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
M.-A. Lemburg wrote:
Walter Dörwald wrote:
M.-A. Lemburg wrote:
> [...]
str and unicode as well as the other hooks were specifically added for the type constructors to use. However, these were added at a time where sub-classing of types was not possible, so it's time now to reconsider whether this functionality should be extended to sub-classes as well. So can we reach consensus on this, or do we need a BDFL pronouncement? I don't have a clear picture of what the consensus currently looks like :-) If we're going for for a solution that implements the hook awareness for all hooks, I'd be +1 on that. If we only touch the unicode case, we'd only be created yet another special case. I'd vote -0 on that. [...]
Here's the patch that implements this for int/long/float/unicode: http://www.python.org/sf/1109424
Note that complex already did the right thing.
For int/long/float this is implemented in the following way: Converting an instance of a subclass to the base class is done in the appropriate slot of the type (i.e. intobject.c::int_int() etc.) instead of in PyNumber_Int()/PyNumber_Long()/PyNumber_Float(). It's still possible for a conversion method to return an instance of a subclass of int/long/float.
Bye, Walter Dörwald
- Previous message: [Python-Dev] __str__ vs. __unicode__
- Next message: [Python-Dev] __str__ vs. __unicode__
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]