ABCs -> infix syntax for isinstance() ?

[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

[bearophileHUGS@lycos.com]

Re: ABCs -&gt; infix syntax for isinstance() ?

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

[bborcic@gmail.com]

Re: ABCs -&gt; infix syntax for isinstance() ?

Bruno Desthuilliers dixit :

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.

(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,cl s) !! :)

Cheers, BB

[Bruno Desthuilliers]

Re: ABCs -&gt; infix syntax for isinstance() ?

bborcic@gmail.c om a écrit :

Bruno Desthuilliers dixit :
>

>Boris Borcic a écrit :
>>

>>Given the ABC innovation, maybe an infix syntax for isinstance() would
>>be good.
>>Possibiliti es :
>>- 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.

>
(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 ?)
>

>Testing a class identity often happens when writing metaclasses

>
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...

[Boris Borcic]

Re: ABCs -&gt; infix syntax for isinstance() ?

Bruno Desthuilliers wrote:

>>Boris Borcic a écrit :
>>>
>>>Given the ABC innovation, maybe an infix syntax for isinstance() would
>>>be good.
>>>Possibilitie s :
>>>- 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. (...)
>>Testing a class identity often happens when writing metaclasses

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

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

[Boris Borcic]

Re: ABCs -&gt; infix syntax for isinstance() ?

Bruno Desthuilliers wrote:

bborcic@gmail.c om a écrit :

...

>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.

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