ABCs -> infix syntax for isinstance() ?

B

Boris Borcic

Given the ABC innovation, maybe an infix syntax for isinstance() would be good.

Possibilities :

- stealing "is" away from object identity. As a motivation, true use cases for
testing object identity are rare; forcing the usage of a function or method to
test it, would dissuade abuse.

- allowing containment tests, ie "x in Number" to invoke isinstance() in the
background when the container is of type <type>. My brain is too muddled by flu
at the moment, to see whether Guido's fabled time machine allowed him to already
provide all the necessities in py26.
Any takers ?

- combining both keywords to create a third one, eg "is in"

Whaddyathink ?

BB
 
B

bearophileHUGS

Boris Borcic:
- combining both keywords to create a third one, eg "is in"

A note only on syntax: "isa" seems better for Python. I don't comment
how useful it can be.

Bye,
bearophile
 
B

Bruno Desthuilliers

Boris Borcic a écrit :
Given the ABC innovation, maybe an infix syntax for isinstance() would
be good.

Possibilities :

- stealing "is" away from object identity. As a motivation, true use
cases for testing object identity are rare;

"x is None" is a *very* common test. Using a _marker object as default
arg value when you want to accept None as a meaningfull value is pretty
common. Testing a class identity often happens when writing metaclasses.
 
B

bborcic

Bruno Desthuilliers dixit :
Boris Borcic a écrit :




"x is None" is a *very* common test. Using a _marker object as default
arg value when you want to accept None as a meaningfull value is pretty
common.

(a) Okay, 3to2 can take care of "x is NoneType" and/or "x == None".
The latter could also be a compiler optimization.

(b) Give me None==False and in exchange I will adopt "x is None" as
sacred forever :)

(not quite BTW, how much future do you think is there in turning 2to3
into some usable 3to2 ? What about "NtoM" as a more generic Python
project ?)
Testing a class identity often happens when writing metaclasses

This kind-of-talks for Terry's proposition : adding a __contains__ to
type, looks like easier to pass before lead metaclass-writers. Or if
not easier to pass, easier to write a simple patch for. So "x in
Number" syntax.

A intriguing wider proposition would be to transpose Ruby's notion of
"Open Classes" to Python built-in metaclasses (or just to type
itself ?).

Let's threaten lead metaclass-writers with *that* if they don't settle
on just type.__contains__ = lambda cls,i : isinstance(i,cls) !! :)

Cheers, BB
 
B

Bruno Desthuilliers

(e-mail address removed) a écrit :
Bruno Desthuilliers dixit :


(a) Okay, 3to2 can take care of "x is NoneType" and/or "x == None".
The latter could also be a compiler optimization.

(b) Give me None==False

Why so ?
and in exchange I will adopt "x is None" as
sacred forever :)

(not quite BTW, how much future do you think is there in turning 2to3
into some usable 3to2 ? What about "NtoM" as a more generic Python
project ?)


This kind-of-talks for Terry's proposition : adding a __contains__ to
type,

I said "type identity testing", not isinstance() or issubclass() testing.

(snip)
A intriguing wider proposition would be to transpose Ruby's notion of
"Open Classes" to Python built-in metaclasses (or just to type
itself ?).

No, thanks. Even the Ruby guys start to think making evrything open may
not be such a good idea after all.

And anyway, I don't see how any of the above address the point that your
premise that "true identity testing is rare" is just wrong...
 
B

Boris Borcic

I said "type identity testing", not isinstance() or issubclass() testing.

Yes, but in the thread's context [of choosing between "is" and "in" as infix
syntax for isinstance()] you were in effect raising as an objection to the first
choice that it meant conflict with this use case [of "type identity testing"
which is "common when writing metaclasses"].

This implied "writing metaclasses" as a background experience to decide the
issue, what in turn implied a preference for the second solution ("x in Number")
on *two* counts.

First because it was a proposed alternative to what you were objecting to, and
Second because "x in Number" has this most simple "metaclassy" solution.

(...)
And anyway, I don't see how any of the above address the point that your
premise that "true identity testing is rare" is just wrong...

I wrote "true use cases for identity testing are rare", it was more of an
auxiliary assertion that a premise, and nothing you objected really disproved it
(for an adequate definition of "true use case").

* writing metaclasses is rare, and so is testing class identity in its context.

* "x is None" is arguably not a "true use case", in the sense that it is a case
of testing identity against a constant that

- doesn't compare equal to anything else
- is the single instance of a singleton class

so that there exists both an equality test and an isinstance() test that are
equivalents to the identity test.

Cheers, BB
 
B

Bruno Desthuilliers

Boris Borcic a écrit :
I said "type identity testing", not isinstance() or issubclass() testing.

Yes, but in the thread's context [of choosing between "is" and "in" as
infix syntax for isinstance()] you were in effect raising as an
objection to the first choice that it meant conflict with this use case
[of "type identity testing" which is "common when writing metaclasses"].

This implied "writing metaclasses" as a background experience to decide
the issue, what in turn implied a preference for the second solution ("x
in Number") on *two* counts.

Oops, looks like I failed to read enough of the thread and missed the
point. Sorry.

Anyway...

*If* Python was to grow an infix operator for isinstance, then I'd
indeed rather use 'in' than 'is' (FWIW I'd even prefer an 'isa'
operator, but...)
First because it was a proposed alternative to what you were objecting
to, and
Second because "x in Number" has this most simple "metaclassy" solution.
(...)

I wrote "true use cases for identity testing are rare", it was more of
an auxiliary assertion that a premise, and nothing you objected really
disproved it (for an adequate definition of "true use case").
* writing metaclasses is rare,

For which definition of "rare" ?
and so is testing class identity in its
context.

* "x is None" is arguably

very arguably...
not a "true use case", in the sense that it is
a case of testing identity against a constant
s/constant/object/

that

- doesn't compare equal to anything else
- is the single instance of a singleton class

And ? How does it make it less a 'true use case' ???
so that there exists both an equality test and an isinstance() test that
are equivalents to the identity test.

but are not idiomatic, and way slower.

FWIW, you didn't adress the use of a _marker sentinel object (another
common use case - at least in quite a lot of library code I've been
reading so far). And FWIW, I so far use 'is' *way* more often than
'isinstance' (while this indeed may change with ABCs...).

Ok, you can clearly count me -10 wrt/ "stealing" the identity operator.
If it matters, I'm -0 about using 'in' instead - at least, it makes
sense wrt/ the semantics of 'in'. As far as I'm concerned, and if we
really need an operator here, I'd prefer a new 'isa' one.
 
B

Boris Borcic

Bruno said:
(e-mail address removed) a écrit : ...

No, thanks. Even the Ruby guys start to think making evrything open may
not be such a good idea after all.

Wasn't an all-or-nothing proposition; a good objection is spelled out in PEP
3119 (ABCs) :

<citing>

...but there are some good reasons to keep the built-in types immutable (for
one, they are shared between all Python interpreters running in the same address
space, as is used by mod_python)

</citing>

Cheers, BB
 

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top