Brett C. wrote:
Walter Dörwald wrote:
Brett C. wrote:
Walter Dörwald wrote:
M.-A. Lemburg wrote:
[...]
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 t
Walter Dörwald wrote:
Brett C. wrote:
Walter Dörwald wrote:
M.-A. Lemburg wrote:
[...]
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 __unico
Brett C. wrote:
Walter Dörwald wrote:
M.-A. Lemburg wrote:
[...]
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 b
Walter Dörwald wrote:
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
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
whet
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 functionalit
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
Nick Coghlan wrote:
[...]
I imagine many people are like me, with __str__ being the only one of
these hooks they use frequently (Helping out with the Decimal
implementation is the only time I can recall using the slots for the
numeric types, and I rarely need to deal with Unicode).
Anyway, they
On Wed, Jan 19, 2005, Walter D?rwald wrote:
> M.-A. Lemburg wrote:
>>
>>Maybe the string case is the real problem ... :-)
>
> At least it seems that the string case is the exception.
> So if we fix __str__ this would be a bugfix for 2.4.1.
Nope. Unless you're claiming the __str__ behavior is ne
M.-A. Lemburg wrote:
Those APIs were all written long before there were sub-classes
of types.
Understood. PyObject_Unicode certainly looked like an 'evolved' piece of
code :)
But before we start hacking the function, we need a general
picture of what we think is right.
Aye.
Note, BTW, that there i
Nick Coghlan wrote:
M.-A. Lemburg wrote:
So if we fix __str__ this would be a bugfix for 2.4.1.
If we fix the rest, this would be a new feature for 2.5.
I have a feeling that we're better off with the bug fix than
the new feature.
__str__ and __unicode__ as well as the other hooks were
specificall
M.-A. Lemburg wrote:
So if we fix __str__ this would be a bugfix for 2.4.1.
If we fix the rest, this would be a new feature for 2.5.
I have a feeling that we're better off with the bug fix than
the new feature.
__str__ and __unicode__ as well as the other hooks were
specifically added for the type
Walter Dörwald wrote:
M.-A. Lemburg wrote:
So the question is whether conversion of a Unicode sub-type
to a true Unicode object should honor __unicode__ or not.
The same question can be asked for many other types, e.g.
floats (and __float__), integers (and __int__), etc.
>>> class float2(float):
.
On 2005 Jan 19, at 11:10, Bob Ippolito wrote:
Do you REALLY think this should be True?!
isinstance(foo, unicode) and foo != unicode(foo)
H -- why not? In the generic case, talking about some class B, it
certainly violates no programming principle known to me that
"isinstance(foo, B) and
Bob Ippolito wrote:
On Jan 19, 2005, at 4:40, Walter Dörwald wrote:
[...]
That's cheating! ;)
My use case is an XML DOM API: __unicode__() should extract the
character data from the DOM. For Text nodes this is the text,
for comments and processing instructions this is u"" etc. To
reduce memory foot
M.-A. Lemburg wrote:
Walter Dörwald wrote:
__str__ and __unicode__ seem to behave differently. A __str__
overwrite in a str subclass is used when calling str(), a __unicode__
overwrite in a unicode subclass is *not* used when calling unicode():
[...]
If you drop the base class for unicode, this alr
On Jan 19, 2005, at 4:40, Walter Dörwald wrote:
M.-A. Lemburg wrote:
Walter Dörwald wrote:
__str__ and __unicode__ seem to behave differently. A __str__
overwrite in a str subclass is used when calling str(), a __unicode__
overwrite in a unicode subclass is *not* used when calling unicode():
[...]
Walter Dörwald wrote:
__str__ and __unicode__ seem to behave differently. A __str__
overwrite in a str subclass is used when calling str(), a __unicode__
overwrite in a unicode subclass is *not* used when calling unicode():
---
class str2(str):
def __str__(self):
__str__ and __unicode__ seem to behave differently. A __str__
overwrite in a str subclass is used when calling str(), a __unicode__
overwrite in a unicode subclass is *not* used when calling unicode():
---
class str2(str):
def __str__(self):
return "foo"
x =
19 matches
Mail list logo
