>> You have a lot more faith in the errno module than I do. Are you sure
>> the same error codes work on all platforms where Python works?
>
>No, but I'm pretty confident the symbolic names for the errors are
>consistent for any platform I've cared about .
>
>> It's also not exactly readable (exce
On Tue, 2005-02-22 at 19:14, Andrew McNamara wrote:
> >> if e.errno <> errno.EEXIST:
> >> raise
> >
> >You have a lot more faith in the errno module than I do. Are you sure
> >the same error codes work on all platforms where Python works? It's
> >also not exactly readable (except for ol
On Tue, 2005-02-22 at 11:16, Guido van Rossum wrote:
> > Really? I do this kind of thing all the time:
> >
> > import os
> > import errno
> > try:
> > os.makedirs(dn)
> > except OSError, e:
> > if e.errno <> errno.EEXIST:
> > raise
>
> You have a lot more faith in the errno modul
>> if e.errno <> errno.EEXIST:
>> raise
>
>You have a lot more faith in the errno module than I do. Are you sure
>the same error codes work on all platforms where Python works? It's
>also not exactly readable (except for old Unix hacks).
On the other hand, LBYL in this context can resu
On Tuesday 22 February 2005 03:01 am, Guido wrote:
>
> BTW, there's *still* no sign from a PEP 246 rewrite. Maybe someone
> could offer Clark a hand? (Last time I inquired he was recovering from
> a week of illness.)
Last summer Alex, Clark, Phillip and I swapped a few emails about reviving the
On Tue, 22 Feb 2005 08:16:52 -0800, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
> > Really? I do this kind of thing all the time:
> >
> > import os
> > import errno
> > try:
> > os.makedirs(dn)
> > except OSError, e:
> > if e.errno <> errno.EEXIST:
> > raise
>
> You have a lot mor
> Really? I do this kind of thing all the time:
>
> import os
> import errno
> try:
> os.makedirs(dn)
> except OSError, e:
> if e.errno <> errno.EEXIST:
> raise
You have a lot more faith in the errno module than I do. Are you sure
the same error codes work on all platforms where
On Mon, 2005-02-21 at 11:15, Guido van Rossum wrote:
> Right. There are plenty of examples where LBYL is better, e.g. because
> there are too many different exceptions to catch, or they occur in too
> many places. One of my favorites is creating a directory if it doesn't
> already exist; I always
> > Anyway, can you explain why LBYL is bad?
>
> In the general case, it's bad because of a combination of issues. It
> may violate "once, and only once!" -- the operations one needs to check
> may basicaly duplicate the operations one then wants to perform. Apart
> from wasted effort, it may ha
On 2005 Feb 21, at 04:42, Guido van Rossum wrote:
Oh, bah. That's not what basestring was for. I can't blame you or
your
client, but my *intention* was that basestring would *only* be the
base of the two *real* built-in string types (str and unicode).
I think all this just reinforces the notion th
> >> Oh, bah. That's not what basestring was for. I can't blame you or your
> >> client, but my *intention* was that basestring would *only* be the
> >> base of the two *real* built-in string types (str and unicode).
>
> I think all this just reinforces the notion that LBYL is
> a bad idea!
In th
At 04:32 PM 2/21/05 +1300, Greg Ewing wrote:
Alex Martelli wrote:
The need to check "is this thingy here string-like" is sort of frequent,
because strings are sequences which, when iterated on, yield sequences
(strings of length 1) which, when iterated on, yield sequences ad infinitum.
Yes, this
Alex Martelli wrote:
On 2005 Feb 20, at 17:06, Guido van Rossum wrote:
Oh, bah. That's not what basestring was for. I can't blame you or your
client, but my *intention* was that basestring would *only* be the
base of the two *real* built-in string types (str and unicode).
I think all this just rein
On 2005 Feb 20, at 17:06, Guido van Rossum wrote:
[Alex]
I did have some issues w/UserString at a client's, but that was
connected to some code doing type-checking (and was fixed by injecting
basestring as a base of the client's subclass of UserString and
ensuring the type-checking always used isin
[Alex]
> I did have some issues w/UserString at a client's, but that was
> connected to some code doing type-checking (and was fixed by injecting
> basestring as a base of the client's subclass of UserString and
> ensuring the type-checking always used isinstance and basestring).
Oh, bah. That's n
On 2005 Feb 20, at 05:20, Raymond Hettinger wrote:
...
This sort of thing is easy to test for and easy to fix. The question
is
whether we care about updating this module anymore or is it a relic.
Also, is the use case one that we care about. AFAICT, this has never
come up before.
I did have s
I noticed that UserString objects have methods that do not accept other
UserString objects as arguments:
>>> from UserString import UserString
>>> UserString('slartibartfast').count(UserString('a'))
Traceback (most recent call last):
File "", line 1, in -toplevel-
UserString('slartibartfas
17 matches
Mail list logo
