> -Original Message-
> From: [EMAIL PROTECTED] [mailto:python-dev-
> [EMAIL PROTECTED] On Behalf Of Martin v. Löwis
> Sent: Wednesday, January 18, 2006 3:36 PM
> To: Jason Orendorff
> Cc: python-dev@python.org
> Subject: Re: [Python-Dev] basenumber redux
>
Jason Orendorff wrote:
> Really this is just further proof that type-checking is a royal pain
> in Python. Or rather, it's not hard to cover the builtin and stdlib
> types, but it's hard to support "duck typing" too. Are we going about
> this the right way?
It's not as bad. There is nothing wron
On 1/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Alex Martelli wrote:
> > But this doesn't apply to the Python Standard Library, for example see
> > line 1348 of imaplib.py: "if isinstance(date_time, (int, float)):".
> [...]
> > Being able to change imaplib to use basenumber instead of (i
Alex Martelli wrote:
> On 1/17/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> Alex, I think you're missing a point here: what you are looking
>> for is an interface, not a base class - simply because the
>
> I expect numbers to support arithmetic operators, &c -- no need for
> basenumber to "spel
On 1/17/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Being able to change imaplib to use basenumber instead of (int, float)
> won't make it SIMPLER, but it will surely make it BETTER -- why should
> a long be rejected, or a Decimal,
> for that matter?
Because there's no guarantee that they'll pr
Alex Martelli wrote:
> But this doesn't apply to the Python Standard Library, for example see
> line 1348 of imaplib.py: "if isinstance(date_time, (int, float)):".
[...]
> Being able to change imaplib to use basenumber instead of (int, float)
> won't make it SIMPLER, but it will surely make it BETT
On 1/17/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Alex, I think you're missing a point here: what you are looking
> for is an interface, not a base class - simply because the
I expect numbers to support arithmetic operators, &c -- no need for
basenumber to "spell this out", i.e., "be an itner
On 1/17/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
[snip]
> I don't see a way around creating an integer recognition tool that
> doesn't conflate its terminology with broadly-held, pre-existing math
> knowledge: complex is a superset of reals, reals include rationals and
> irrationals some of
Alex, I think you're missing a point here: what you are looking
for is an interface, not a base class - simply because the
assumptions you make when finding a "KnownNumberTypes" instance
are only related to an interface you expect them to provide.
A common case class won't really help all that muc
Raymond Hettinger wrote:
> Are you sure? The former has two builtin lookups (which also entail two
> failed global lookups), a function call, and a test/jump for the result.
> The latter approach has no lookups (just a load constant), a try-block
> setup, an add operation (optimized for integers,
Alex Martelli wrote:
>> As I suggested in a different message: Why are you doing that
>> in the first place?
>
>
> Because isinstance is faster and handier than testing with try/except
> around (say) "x+0".
Nit: I think you should not test. Instead, you should starting you mean
to do if the tes
[Me]
> Even if there were a performance edge, I suppose that the type
checking
> is the time critical part of most scripts.
That should be: RARELY the time critical part of most scripts.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
> Because isinstance is faster and handier than testing with try/except
> around (say) "x+0".
Are you sure? The former has two builtin lookups (which also entail two
failed global lookups), a function call, and a test/jump for the result.
The latter approach has no lookups (just a load constant),
On 1/16/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Nothing was said about "different design intent for basestring", as I
> recall (that discussion comes up among the few hits for [basestring
> site:python.org] if you want to check the details).
Please. How many times do I have to say this. *I
On Jan 16, 2006, at 2:01 PM, Martin v. Löwis wrote:
> Alex Martelli wrote:
>> I can't find a PEP describing this restriction of basestring, and I
>> don't see why a coder who needs to implement another kind of
>> character string shouldn't subclass basestring, so that those
>> instances pass an i
Alex Martelli wrote:
> I can't find a PEP describing this restriction of basestring, and I
> don't see why a coder who needs to implement another kind of
> character string shouldn't subclass basestring, so that those
> instances pass an isinstance test on basestring which is quite likely
>
Alex Martelli wrote:
> > As you already suspected, I think a PEP is needed. The intent of
>
> I'll be happy to write it, if it stands any chance.
>
> > basestring was to *only* be used as the base class for *built-in*
> > string types. Clearly what you're proposing is different (Decimal is
> > not
On Jan 16, 2006, at 7:53 AM, Guido van Rossum wrote:
> On 1/15/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
>> Now, today, I have _again_ been bit by the lack of basenumber (by a
>> bug of mine, fixed by adding decimal.Decimal to a long tuple of
>> classes to be passed to an isinstance call -- I
On 1/15/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Now, today, I have _again_ been bit by the lack of basenumber (by a
> bug of mine, fixed by adding decimal.Decimal to a long tuple of
> classes to be passed to an isinstance call -- I hadn't run that
> particular numeric code of mine since the
On Monday 16 January 2006 20:05, Nick Coghlan wrote:
> For example, what's wrong with "hasattr(x, __int__)"? That works
> for all the builtin types, and, IMO, anyone defining a direct
> conversion to an integer for a non-numeric type deserves whatever
> happens to them.
What about something that's
Alex Martelli wrote:
> I'll be happy to draft a PEP if needed (and just as happy to
> eventually provide an implementation patch if the PEP's accepted),
> but wanted to doublecheck on the general issue first!
I haven't really followed the earlier basenumber discussions (aside from the
sidetra
Alex Martelli wrote:
> I'll be happy to draft a PEP if needed (and just as happy to
> eventually provide an implementation patch if the PEP's accepted),
> but wanted to doublecheck on the general issue first!
Please do so. I've browsed somewhat through past discussions,
but wasn't able to find
For the last 2+ years I've been occasionally arguing for the
introduction of a basenumber (and ideally a baseinteger, but that, to
me, is a slightly lesser issue) analogous to basestring. Google
search fo [basenumber site:python.org] for several messages on the
subject, by me and others; i
23 matches
Mail list logo
