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
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
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.
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.
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
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
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
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
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
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
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
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
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
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):
.
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
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():
[...]
23 matches
Mail list logo