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
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
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
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
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.7
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,
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
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
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 what
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 hard to
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 one
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
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
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. If
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 involves 4
18 matches
Mail list logo
