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():
[...]
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
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
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
Guido van Rossum wrote:
[me]
I'm not sure I understand how basemethod is supposed to work; I can't
find docs for it using Google (only three hits for the query mxTools
basemethod). How does it depend on im_class?
[Marc-Andre]
It uses im_class to find the class defining the (unbound) method:
def ba
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):
.
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
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:
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
Donovan Baarda <[EMAIL PROTECTED]> writes:
> G'day,
>
> I've Cc'ed this to zope-coders as it might affect other Zope developers
> and it had me stumped for ages. I couldn't find anything on it anywhere,
> so I figured it would be good to get something into google :-).
>
> We are developing a Zope2
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
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
Martin v. Löwis wrote:
I think Brett Cannon now also follows this rule; it
really falls short enough in practice because (almost)
nobody really wants to push his patch bad enough to
put some work into it to review other patches.
Yes, I am trying to support the rule, but my schedule is nutty right n
There is a discussion going on at the moment in postgresql-general about
plpythonu (which allows you write stored procedures in Python) and line
endings. The discussion starts here:
http://archives.postgresql.org/pgsql-general/2005-01/msg00792.php
The problem appears to be that things are work
Stuart Bishop wrote:
> I don't think it is possible for plpythonu to fix this by simply translating
> the line endings, as
> this would require significant knowledge of Python syntax to do correctly
> (triple quoted strings
> and character escaping I think).
of course it's possible: that's wh
On 2005 Jan 20, at 00:14, Fredrik Lundh wrote:
Stuart Bishop wrote:
I don't think it is possible for plpythonu to fix this by simply
translating the line endings, as
this would require significant knowledge of Python syntax to do
correctly (triple quoted strings
and character escaping I think).
o
On Thu, 20 Jan 2005 09:03:30 +1000, Stephen Thorne
<[EMAIL PROTECTED]> wrote:
> "Flat is better than nested" has one foot in concise powerful
> programming, the other foot in optimisation.
>
> foo.bar.baz.arr involves 4 hashtable lookups. arr is just one hashtable
> lookup.
I find it amazingly h
At 07:03 PM 1/19/05 -0500, Timothy Fitz wrote:
On Thu, 20 Jan 2005 09:03:30 +1000, Stephen Thorne
<[EMAIL PROTECTED]> wrote:
> "Flat is better than nested" has one foot in concise powerful
> programming, the other foot in optimisation.
>
> foo.bar.baz.arr involves 4 hashtable lookups. arr is just o
Uh, life has been busy.
Will probably send this one out this weekend some time so please get
corrections in before then.
=
Summary Announcements
=
PyCon_ 2005 is well underway. The schedule is in the process of being
f
On Wed, 2005-01-19 at 13:37 +, Michael Hudson wrote:
> Donovan Baarda <[EMAIL PROTECTED]> writes:
[...]
> You've left out a very important piece of information: which version
> of Python you are using. I'm guessing 2.3.4. Can you try 2.4?
Debian Python2.3 (2.3.4-18), Debian kernel-image-2.6.
Stuart> I don't think it is possible for plpythonu to fix this by simply
Stuart> translating the line endings, as this would require significant
Stuart> knowledge of Python syntax to do correctly (triple quoted
Stuart> strings and character escaping I think).
I don't see why not.
Phillip> Actually, this is one of those rare cases where optimization
Phillip> and clarity go hand in hand. Human brains just don't handle
Phillip> nesting that well. It's easy to visualize two levels of nested
Phillip> structure, but three is a stretch unless you can abstract at
On Wed, 19 Jan 2005 19:03:25 -0500, Timothy Fitz <[EMAIL PROTECTED]> wrote:
> On Thu, 20 Jan 2005 09:03:30 +1000, Stephen Thorne
> <[EMAIL PROTECTED]> wrote:
> > "Flat is better than nested" has one foot in concise powerful
> > programming, the other foot in optimisation.
> >
> > foo.bar.baz.arr in
23 matches
Mail list logo
