Re: isinstance()

[Grant Edwards via Python-list]

On 2023-08-04, Chris Angelico via Python-list  wrote:
> On Sat, 5 Aug 2023 at 09:36, dn via Python-list  
> wrote:
>
>> Faced with a situation where an argument may be a scalar-value or an
>> iterable, I'll presume the latter, eg throw it straight into a for-loop.
>> If that fails (because the argument is a scalar), use try-except to
>> re-route the logic.
>
> That's great as long as you aren't expecting to handle strings.

If you do that, you're obviously not expecting to handle strings. The
problem happens when you're not expecting to handle strings, and you
get passed one anyway.

It's like the Spanish Inquisition...

> The string "spam" is sometimes equivalent to the list ["s", "p",
> "a", "m"] and sometimes not.

And b"ABCD" is sometimes equivalent to the list [65,66,67,68] and
sometimes not.

Been there, fell in that hole.

More than a few times. :/

Famous Last Words: "I wasn't expecting to handle strings -- but I
should have been..."

--
Grant



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: isinstance()

[Chris Angelico via Python-list]

On Sat, 5 Aug 2023 at 09:36, dn via Python-list  wrote:
> Faced with a situation where an argument may be a scalar-value or an
> iterable, I'll presume the latter, eg throw it straight into a for-loop.
> If that fails (because the argument is a scalar), use try-except to
> re-route the logic.

That's great as long as you aren't expecting to handle strings. The
string "spam" is sometimes equivalent to the list ["s", "p", "a", "m"]
and sometimes not.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: isinstance()

[dn via Python-list]

On 05/08/2023 11.18, Chris Angelico via Python-list wrote:

On Sat, 5 Aug 2023 at 09:08, dn via Python-list  wrote:


On 03/08/2023 11.38, Jon Ribbens via Python-list wrote:

On 2023-08-02, dn  wrote:

Can you please explain why a multi-part second-argument must be a tuple
and not any other form of collection-type?


The following comment may hold a clue:

  if (PyTuple_Check(cls)) {
  /* Not a general sequence -- that opens up the road to
 recursion and stack overflow. */

https://github.com/python/cpython/blob/main/Objects/abstract.c#L2684

Plus an almost total lack of demand for change I should think.


Thanks for the reference!


Am not proposing a change (have learned 'the rule' and accepted
life-as-it-is), but was curious about the restriction: why not any
(reasonable sequence)?


There are quite a few places where the only option is a tuple.


"spam".startswith(["sp", "h"])

Traceback (most recent call last):
   File "", line 1, in 
TypeError: startswith first arg must be str or a tuple of str, not list

try: 1/0

... except [ValueError, IndexError]: pass
...
Traceback (most recent call last):
   File "", line 1, in 
ZeroDivisionError: division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
   File "", line 2, in 
TypeError: catching classes that do not inherit from BaseException is
not allowed

It simplifies a lot of checks. Either it's a tuple or it's a single
thing. A *lot* of values are iterable, but only tuples are tuples.

As the C comment notes, this also means you don't have to worry about
recursion; otherwise, even core language features like exception
handling would have to iterate over a thing while ensuring that they
don't get stuck in self-referential objects. (Incidentally, it seems
that exception handling doesn't bother with recursion *at all*, and
won't catch "(a, (b, c))" - but even if recursion is handled, it can't
go infinite, short of some serious messing around in ctypes or the C
API.)

Yes. Thanks Chris!

The idea that such 'lists' be immutable (even, hashable), and therefore 
a tuple, makes a certain amount of sense, and @Cameron mentioned 
'frugality'.



My limitation is thinking only at the Python level (which as @Jon 
pointed-out, is only part of the story).


Faced with a situation where an argument may be a scalar-value or an 
iterable, I'll presume the latter, eg throw it straight into a for-loop. 
If that fails (because the argument is a scalar), use try-except to 
re-route the logic. Alternately, in an OOP situation, utilise 
polymorphism so that the 'scalar' and 'iterable' instances both include 
the appropriate method[name]. Accordingly, as long as the argument is an 
iterable (includes an __iter__() method), the actual type/class is 
more-or-less irrelevant.



However, as observed earlier - and with these additions, having learned 
the 'rule', ie use a tuple; the brain is still pondering, but have 
shrugged-shoulders and carried-on regardless...


--
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: isinstance()

[Chris Angelico via Python-list]

On Sat, 5 Aug 2023 at 09:08, dn via Python-list  wrote:
>
> On 03/08/2023 11.38, Jon Ribbens via Python-list wrote:
> > On 2023-08-02, dn  wrote:
> >> Can you please explain why a multi-part second-argument must be a tuple
> >> and not any other form of collection-type?
> >
> > The following comment may hold a clue:
> >
> >  if (PyTuple_Check(cls)) {
> >  /* Not a general sequence -- that opens up the road to
> > recursion and stack overflow. */
> >
> > https://github.com/python/cpython/blob/main/Objects/abstract.c#L2684
> >
> > Plus an almost total lack of demand for change I should think.
>
> Thanks for the reference!
>
>
> Am not proposing a change (have learned 'the rule' and accepted
> life-as-it-is), but was curious about the restriction: why not any
> (reasonable sequence)?

There are quite a few places where the only option is a tuple.

>>> "spam".startswith(["sp", "h"])
Traceback (most recent call last):
  File "", line 1, in 
TypeError: startswith first arg must be str or a tuple of str, not list
>>> try: 1/0
... except [ValueError, IndexError]: pass
...
Traceback (most recent call last):
  File "", line 1, in 
ZeroDivisionError: division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 2, in 
TypeError: catching classes that do not inherit from BaseException is
not allowed

It simplifies a lot of checks. Either it's a tuple or it's a single
thing. A *lot* of values are iterable, but only tuples are tuples.

As the C comment notes, this also means you don't have to worry about
recursion; otherwise, even core language features like exception
handling would have to iterate over a thing while ensuring that they
don't get stuck in self-referential objects. (Incidentally, it seems
that exception handling doesn't bother with recursion *at all*, and
won't catch "(a, (b, c))" - but even if recursion is handled, it can't
go infinite, short of some serious messing around in ctypes or the C
API.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: isinstance()

[dn via Python-list]

On 03/08/2023 11.38, Jon Ribbens via Python-list wrote:

On 2023-08-02, dn  wrote:

Can you please explain why a multi-part second-argument must be a tuple
and not any other form of collection-type?


The following comment may hold a clue:

 if (PyTuple_Check(cls)) {
 /* Not a general sequence -- that opens up the road to
recursion and stack overflow. */

https://github.com/python/cpython/blob/main/Objects/abstract.c#L2684

Plus an almost total lack of demand for change I should think.


Thanks for the reference!


Am not proposing a change (have learned 'the rule' and accepted 
life-as-it-is), but was curious about the restriction: why not any 
(reasonable sequence)?



Such pondering continues in my subversive mind, given such thoughts as:

- "we're all adults here"
(eg frequent justification when arguing about Python not having "private 
attributes" per-se).

So, if we introduce a complexity, on our own heads be it!
(hardly likely given that all we are likely to attempt is the 
application of a simple and short 'list' of [un]acceptable types).
NB understood that the quoted-code is applied in many and other 'scalar 
or tuple' situations.


- Python happily enables recursion, which "opens up the road to 
recursion and stack overflow.".

So, why install a 'nanny' to save us from ourselves here?
Again: seems on-the-surface that such 'lists' (at the code-line level) 
will be mono-dimensional 99.9% of the time.



NB having said that, the underlying mechanism *is* multi-dimensional: 
"direct, indirect, or virtual) subclass thereof" 
(https://docs.python.org/3/library/functions.html#isinstance)


Further: the 'rules' say: "classinfo is a tuple of type objects (or 
recursively, other such tuples)". Thus, can write:


>>> target_object = ...
>>> inner_tuple = float, complex
>>> inner_tuple
(, )
>>> isinstance( target_object, ( str, inner_tuple, int, ), )
False

I can't say I've ever used such construction in-the-wild - either 
defining and then using an "inner_tuple", or even nesting. YMMV!



Any thoughts?

--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: isinstance()

[Jon Ribbens via Python-list]

On 2023-08-02, dn  wrote:
> Can you please explain why a multi-part second-argument must be a tuple 
> and not any other form of collection-type?

The following comment may hold a clue:

if (PyTuple_Check(cls)) {
/* Not a general sequence -- that opens up the road to
   recursion and stack overflow. */

https://github.com/python/cpython/blob/main/Objects/abstract.c#L2684

Plus an almost total lack of demand for change I should think.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: isinstance()

[Cameron Simpson via Python-list]

On 03Aug2023 10:14, dn  wrote:
Can you please explain why a multi-part second-argument must be a 
tuple and not any other form of collection-type?


The signature is: isinstance(object, classinfo)
leading to "classinfo" of:

1/ a single class/type, eg int
2/ a tuple of same, eg ( int, str, )
3/ a union type, eg int | str (v3.10+)


help(isinstance) (in 3.8) says class_or_tuple.

I would speculate that requiring a tuple has two advantages:
- it may lend itself to promotion to a set for comparison with the MRO 
  of object (IIRC the "foo in (a,b,c)" is optimised this way also), and 
  this in turn may hint at the Hashable requirement
- it is _frugal_ in what we expect there, leaving open a future meaning 
  for something else in that place (for example, isinstance well 
  predates type annotations, and a looser kind of argument might have 
  precluded this new usage)


There's similar language in this try/except documentation:
file:///Users/cameron/var/doc/python/3.8.0/reference/compound_stmts.html#index-10

 For an except clause with an expression, that expression is 
 evaluated, and the clause matches the exception if the resulting 
 object is “compatible” with the exception. An object is compatible 
 with an exception if it is the class or a base class of the 
 exception object or a tuple containing an item compatible with the 
 exception.


To my mind the tuple requirement lends itself to a distinct syntax (the 
brackets) and frugal use of the meaning of what values can occur there.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

isinstance()

[dn via Python-list]

Can you please explain why a multi-part second-argument must be a tuple 
and not any other form of collection-type?



The signature is: isinstance(object, classinfo)
leading to "classinfo" of:

1/ a single class/type, eg int
2/ a tuple of same, eg ( int, str, )
3/ a union type, eg int | str (v3.10+)

A question was asked about this at last night's PUG-meeting. The person 
was using the union option, but from Python v3.8. Sorting that out, he 
replaced the union with a list. No-go! Before correcting to a tuple...


Why does the second argument need to be a tuple, given that any series 
of non-keyword arguments is a tuple; and that such a tuple will still 
need to be delimited by parentheses. In other words, other forms of 
delimiter/collection, eg list and set; being a series of 
elements/members would seem no different.


Yes, the underlying C operation appears to only accept a single argument 
(am not C-soned, mea culpa!).


There is some discussion about hashability, but isn't it coincidental 
rather than constructive? (again, maybe I've not understood...)


Enquiring minds want to know...


Web.Refs:
https://docs.python.org/3/library/functions.html?highlight=isinstance#isinstance
https://docs.python.org/3/c-api/object.html?highlight=isinstance#c.PyObject_IsInstance
https://docs.python.org/3/reference/datamodel.html?highlight=isinstance

--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list

[issue532767] isinstance() should respect __class__

[admin]

Change by admin :


--
github: None -> 36297

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue467267] isinstance depends on import form

[admin]

Change by admin :


--
github: None -> 35266

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue464992] Fix abstract isinstance

[admin]

Change by admin :


--
github: None -> 35234

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue402681] issubclass() and isinstance() error messages

[admin]

Change by admin :


--
github: None -> 33554

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue224106] isinstance() doesn't *quite* work on ExtensionClasses

[admin]

Change by admin :


--
github: None -> 33533

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue402630] Don't raise TypeError from isinstance

[admin]

Change by admin :


--
github: None -> 33539

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue402630] Don't raise TypeError from isinstance

[admin]

Change by admin :


--
github: None -> 33539

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue402681] issubclass() and isinstance() error messages

[admin]

Change by admin :


--
github: None -> 33554

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue224106] isinstance() doesn't *quite* work on ExtensionClasses

[admin]

Change by admin :


--
github: None -> 33533

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45665] Problems caused by isinstance(list[int], type) returning True

[Alex Waygood]

Alex Waygood  added the comment:

> We will still allow instantiating e.g. list[int], right?

I certainly hope so! That would be a much more breaking change if we were to 
change that, and I can't personally see any benefit to doing so.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45665] Problems caused by isinstance(list[int], type) returning True

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
nosy:  -pablogsal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45665] Problems caused by isinstance(list[int], type) returning True

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Gentle ping, as the next alpha will be release soon

--
nosy: +pablogsal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45665] Problems caused by isinstance(list[int], type) returning True

[Guido van Rossum]

Guido van Rossum  added the comment:

I now agree with Serhiy's plan. We should execute ASAP so people get a chance 
to try this in the next alpha release.

We will still allow instantiating e.g. list[int], right?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45665] Problems caused by isinstance(list[int], type) returning True

[Alex Waygood]

Alex Waygood  added the comment:

I agree with Serhiy.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45665] Problems caused by isinstance(list[int], type) returning True

[Alex Waygood]

Alex Waygood  added the comment:

Yes, there are a few exceptions to that :(

```
>>> from typing import Annotated
>>> x = Annotated[int, "idk some int"]
>>> x()
0
>>> isinstance(x, type)
False
>>>
>>> from re import Pattern
>>> y = Pattern[str]
>>> y()
Traceback (most recent call last):
  File "", line 1, in 
TypeError: cannot create 're.Pattern' instances
>>> isinstance(y, type)
True
```

--

___
Python tracker 
<https://bugs.python.org/issue45665>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45665] Problems caused by isinstance(list[int], type) returning True

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

My plan was to fix as much bugs in the stdlib and backport workaround to 3.9 
and 3.10, then propose to revert this "feature" in 3.11.

There is a risk of introducing some regressions by this change, but we can 
handle it. I think it is better to do it now and fix potential bugs in 
third-party code (we cannot add workarounds in all third-party code) than keep 
this weird special case forever.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45665] Problems caused by isinstance(list[int], type) returning True

[Guido van Rossum]

Guido van Rossum  added the comment:

Okay, so it is probably here to stay. We could justify it (after the fact :-) 
by saying that you can instantiate list[int], but not Any.

Are there exceptions to that? (I.e. are there other annotation types that have 
isinstance(X, type) return False but can be instantiated, or the other way 
around?)

--

___
Python tracker 
<https://bugs.python.org/issue45665>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45665] Problems caused by isinstance(list[int], type) returning True

[Alex Waygood]

Alex Waygood  added the comment:

`isinstance(list[int], type)` returns `True` in 3.9 as well, so the behaviour 
has been around for a while. (Not a comment on whether the change is worth 
making, just a note.)

--

___
Python tracker 
<https://bugs.python.org/issue45665>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45665] Problems caused by isinstance(list[int], type) returning True

[Guido van Rossum]

Guido van Rossum  added the comment:

So is it too late to change this? This went out with 3.10, Serhiy has argued 
it's a bugfix.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45665] Problems caused by isinstance(list[int], type) returning True

[Ken Jin]

Ken Jin  added the comment:

> It does seem inconsistent that Any is not considered a type but list[int] is

Yeah, almost none of the typing "types" are types ever since PEP 560. 
Issue45755 was a side effect too.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45665] Problems caused by isinstance(list[int], type) returning True

[Joseph Perez]

Joseph Perez  added the comment:

There is also https://bugs.python.org/issue44293 about inspect.isclass

--
nosy: +joperez

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45665] Problems caused by isinstance(list[int], type) returning True

[Guido van Rossum]

Guido van Rossum  added the comment:

See https://github.com/python/mypy/issues/9773#issuecomment-1000975000. I may 
have talked myself into agreeing with Serhiy there! It does seem inconsistent 
that Any is not considered a type but list[int] is:

>>> isinstance(list[int], type)
True
>>> import typing
>>> isinstance(typing.Any, type)

--

___
Python tracker 
<https://bugs.python.org/issue45665>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38085] Interrupting class creation in __init_subclass__ may lead to incorrect isinstance() and issubclass() results

[Carl Friedrich Bolz-Tereick]

Carl Friedrich Bolz-Tereick  added the comment:

Or, in other words, in my opinion this is the root cause of the bug:

class Base:
def __init_subclass__(cls):
global broken_class
broken_class = cls
assert 0
try:
class Broken(Base): pass
except: pass
assert broken_class not in Base.__subclasses__()

The assert fails, which imo it shouldn't.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38085] Interrupting class creation in __init_subclass__ may lead to incorrect isinstance() and issubclass() results

[Carl Friedrich Bolz-Tereick]

Carl Friedrich Bolz-Tereick  added the comment:

hm, I think I figured it out. The root cause is that even though the creation 
of the class Triffid fails, it can still be found via Animal.__subclasses__(), 
which the special subclass logic for ABCs is looking at. Triffid fills its 
_abc_impl data with some content, but Triffid._abc_impl was never successfully 
initialized, therefore it mutates the _abc_impl of its first base class Animal.

My conclusion would be that if a class is not successfully created, it 
shouldn't appear in the .__subclasses__() list of its bases.

See attached script for some illuminating prints.

--
nosy: +Carl.Friedrich.Bolz
Added file: https://bugs.python.org/file50515/x.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38085] Interrupting class creation in __init_subclass__ may lead to incorrect isinstance() and issubclass() results

[hongweipeng]

Change by hongweipeng :


--
keywords: +patch
pull_requests: +28335
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/30112

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29221] ABC Recursion Error on isinstance() with less than recursion limit class hierarchy depth

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It is still reproducible if increase the depth. In 3.8-3.10 it needs 329 nested 
classes, in 3.11 -- 496.

Seems the limit is sys.getrecursionlimit()//k - 4, where k=4 in 3.7 and older, 
k=3 in 3.8-3.10, and k=2 in 3.11. It is much better than was initially, but the 
ideal is k=1.

--
resolution: out of date -> 
stage: resolved -> 
status: closed -> open
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.7, Python 3.5, Python 
3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29221] ABC Recursion Error on isinstance() with less than recursion limit class hierarchy depth

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45665] Problems caused by isinstance(list[int], type) returning True

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
dependencies: +functools' singledispatch does not support GenericAlias

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45665] Problems caused by isinstance(list[int], type) returning True

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
dependencies:  -functools' singledispatch does not support GenericAlias

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45665] Problems caused by isinstance(list[int], type) returning True

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
dependencies: +functools' singledispatch does not support GenericAlias

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45665] Problems caused by isinstance(list[int], type) returning True

[Alex Waygood]

Alex Waygood  added the comment:

#46032 is related to this issue.

--
nosy: +AlexWaygood

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__

[Steven D'Aprano]

Steven D'Aprano  added the comment:

The plot thickens.

I was wrong to say that type() always and only looks at the "real" underlying 
type of the instance. type() does look at __class__ as well. But only sometimes.

>>> class A:
... __class__ = int
... 
>>> type(A())

>>> a = A()
>>> a.__class__ = int
>>> type(a)


So from A, we might think that type() ignores __class__

>>> class B:
... pass
... 
>>> type(B())  # no __class__ to inspect

>>> b = B()
>>> b.__class__ = int
Traceback (most recent call last):
  File "", line 1, in 
TypeError: __class__ assignment only supported for mutable types or ModuleType 
subclasses

How very odd. But okay, let's try something else:

>>> b.__class__ = A  # lie that this is an A not a B
>>> type(b)


So now type() *does* inspect __class__, and believes it.

If we generate the __class__ attribute dynamically with __getattr__, the method 
doesn't even get called. But if we use __getattribute__:

>>> class C:
... def __getattribute__(self, name):
... print('C getattribute:', name)
... if name == '__class__':
... return int
... raise AttributeError
... 
>>> C().__class__
C getattribute: __class__

>>> type(C())


type() ignores the dynamically generated __class__. But isinstance does not:

>>> isinstance(C(), int)
C getattribute: __class__
True


The same applies if we use property:

>>> class D:
... @property
... def __class__(self):
... return int
... 
>>> type(D())

>>> isinstance(D(), int)
True


So the rules appear to be:

- you can set __class__, but only sometimes;
- type() will believe __class__, but only sometimes;
- you can generate __class__ dynamically, but not with __getattr__;
- isinstance() will believe __class__ (always?);
- and there is no indication of how much of this is deliberate language feature 
and how much is an accident of implementation.

--

___
Python tracker 
<https://bugs.python.org/issue32683>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__

[Gabriele N Tornetta]

Gabriele N Tornetta  added the comment:

@rhettinger
Apologies. You're totally right but I wasn't expecting this to become a lengthy 
conversation.

So, to get closer to the initial issue, I believe that this ticket could be 
closed provided that the documentation is improved by making developers aware 
of the potential side effects of isinstance. I was doing some more experiments 
and it looks like

def _isinstance(obj, classinfo):
return issubclass(type(obj), classinfo)

might be considered a "side-effects-free" version of isinstance. So perhaps one 
thing to mention in the documentation is that `isinstance(obj, classinfo) != 
issubclass(type(obj), classinfo)` in general.

--

___
Python tracker 
<https://bugs.python.org/issue32683>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__

[Steven D'Aprano]

Steven D'Aprano  added the comment:

On Fri, Dec 10, 2021 at 12:03:15AM +, Gabriele N Tornetta wrote:

> class Side(object):
> def __getattribute__(self, name):
> ValueError(name)

You forgot to actually *raise* the exception. That will just instantiate
the ValueError instance, and then immediately garbage collect it.

In any case, type() and isinstance() do not work the same way. type()
does not inspect the `__class__` attribute.

--

___
Python tracker 
<https://bugs.python.org/issue32683>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__

[Steven D'Aprano]

Steven D'Aprano  added the comment:

I agree that the rules regarding type and `__class__` and isinstance are 
not clear or well documented.

We have:

https://docs.python.org/3/library/stdtypes.html#instance.__class__

https://docs.python.org/3/library/functions.html#isinstance

but neither discuss the interaction between a class' "real" type and 
it's "fake" type.

To be honest, I'm not even sure I fully understand the interaction 
myself, or how they combine with virtual subclasses. A lot of my 
information comes from this Stackoverflow post:

https://stackoverflow.com/questions/1060499/difference-between-typeobj-and-obj-class

and in particular this comment:

"Some code does this deliberately to lie about the type of objects, such 
as weakref.proxy. Some people think obj.__class__ should be preferred, 
because it believes the lie, while some people think type(obj) should be 
preferred because it ignores the lie. isinstance will return true if an 
object's real class or its lie class is an instance of the second 
argument."

So I think that the behaviour here is correct, but it is not documented 
well and we should fix that.

What I think happens:

* type(obj) always and only returns the actual internal (C-level) type 
  of the object, guaranteed to be a type object.

* isinstance(obj, classinfo) returns True if any of the following hold:

  - the type() of object is a subclass of any of the classes in the
classinfo object (a class, a Union of classes, or a tuple of 
classes);

  - obj.__class__ is a subclass of any of the classes in classinfo;

  - or obj is registered as a virtual subclass of any of the classes
in classinfo, by calling type(ob).__subclasshook__;

* obj.__class__ is determined using the normal attribute lookup 
  mechanism, which means it does not have to be a static attribute
  but can be dynamically generated using properties, __getattr__,
  __getattribute__ or any other similar mechanism.

And for the avoidance of doubt, a class is always considered a subclass 
of itself.

I'm really not sure about the interaction with virtual subclasses, I 
probably have that bit wrong. And it is not clear to me what happens if 
__class__ is a non-type object. It seems to be permitted.

Improving the documentation would be excellent.

--

___
Python tracker 
<https://bugs.python.org/issue32683>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> Changing the way isinstance works internally might prove
> beneficial for such tools.

ISTM you're advocating a design change rather than discussing a bug report.  
The python-ideas mail list would be a better forum than the tracker.

--
nosy: +rhettinger

___
Python tracker 
<https://bugs.python.org/issue32683>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__

[Gabriele N Tornetta]

Gabriele N Tornetta  added the comment:

> Python is very much a language about responsibility.  If Django is overriding 
> `__getattribute__` then it is their responsibility to ensure that everything 
> still works properly.

Perhaps I didn't stress observability enough. A tool like a tracer or a 
profiler, in the ideal world, is not supposed to perturb the tracee in any way. 
The current implementation of isinstance, when used by an observability tool, 
may cause side effects as well as overheads, so it is not safe to use in such 
tools. Working around it may solve the side-effects issue, but leaves the 
problem of overheads. Changing the way isinstance works internally might prove 
beneficial for such tools.

En passant,  I think it should be noted that the built-in "type" doesn't suffer 
from the same problem, i.e.

~~~
class Side(object):
def __getattribute__(self, name):
ValueError(name)


type(Side())
~~~

works as expected.

--

___
Python tracker 
<https://bugs.python.org/issue32683>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__

[Ethan Furman]

Ethan Furman  added the comment:

$ python3
Python 3.8.10 (default, Sep 28 2021, 16:10:42) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

>>> object


>>> import builtins
>>> builtins.object


>>> builtins.object = int
>>> object



Python is very much a language about responsibility.  If Django is overriding 
`__getattribute__` then it is their responsibility to ensure that everything 
still works properly.  If something doesn't, we file a bug report and/or 
implement a work-around.

As for side-effect free -- I'm not sure than anything in Python is guaranteed 
to be side-effect free, except maybe `is`.

There is no bug here, everything is working as intended.

--
nosy: +ethan.furman

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__

[Gabriele N Tornetta]

Gabriele N Tornetta  added the comment:

> I tend to agree with Steven and David here. You define __getattribute__ and 
> so that's the behaviour you get when an attribute of the class is requested 
> (whether by the system or by your code).

I would agree if it was obvious or explicitly stated that isinstance looks up 
__class__ using the object's __getattribute__, and thus prone to cause 
side-effects. It wasn't obvious to me that isinstance would access any 
attributes from the object, but that it would rather get the object's type in a 
more direct way (at the C level for CPython).

> Do you have a real-world example of code that is broken by this behaviour, or 
> is this just a theoretical problem?

I was looking at some profiling data for a real-life project (observability) 
that I'm working on. I was using a simple Django application as a target and 
noticed calls to a __getattribute__ (implemented by a Django class) that I 
wasn't expecting. All my code was doing was to check that a certain object was 
not of "callable" type using isinstance. Whilst I believe no side effects were 
caused by this particular instance of __getattribute__, it should be noted that 
"Django" is a variable here: any other target framework or library might have 
caused side effects in theory. The code that I want to execute must have 
guarantees of being side-effects-free, so using isinstance does not give me 
that. Currently, I have worked around this by using a custom, pure Python 
implementation of isinstance that gets __mro__  (via object.__getattribute__) 
and checks that type(obj) is an element of it (plus caching, for performance 
reasons).

--

___
Python tracker 
<https://bugs.python.org/issue32683>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__

[Paul Moore]

Paul Moore  added the comment:

I tend to agree with Steven and David here. You define __getattribute__ and so 
that's the behaviour you get when an attribute of the class is requested 
(whether by the system or by your code). The documentation (here: 
https://docs.python.org/3/reference/datamodel.html#object.__getattribute__) 
seems to support this view as well.

Do you have a real-world example of code that is broken by this behaviour, or 
is this just a theoretical problem? Is it particularly hard to make the code 
work the way you want it to with the current behaviour? For example,

# Don't intercept __class__
if attr == "__class__":
return object.__getattribute__(self, attr)

--
nosy: +paul.moore

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__

[Steven D'Aprano]

Steven D'Aprano  added the comment:

If you don't want to customise attribute access, don't overload 
`__getattribute__`. The documentation for `__getattribute__` is clear 
about what it does:

"Called unconditionally to implement attribute accesses for instances of 
the class."

https://docs.python.org/3/reference/datamodel.html#object.__getattribute__

That includes lookups for `__class__`, regardless of whether the 
function doing the lookup is isinstance or some other function.

You ask:

"Are there any reasons why __class__ cannot be retrieved with
object.__getattribute__ instead?"

Yes, that would ignore overloaded attribute access, which would be a 
bug in my opinion.

Being able to dynamically generate computed attributes by overloading 
`__getattr__` and `__getattribute__` is not a bug. It is part of 
Python's data model. See the documentation above.

And that includes `__class__`.

I don't believe that it is an accident or a bug that isinstance uses 
ordinary attribute lookup, which goes through the standard mechanism 
including the class' own `__getattribute__` method. But I will ask on 
the Python-Dev mailing list in case Guido or other core developers think 
that it is wrong to do so.

--

___
Python tracker 
<https://bugs.python.org/issue32683>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__

[Gabriele N Tornetta]

Gabriele N Tornetta  added the comment:

I think the issue on display here is that isinstance could cause a side effect, 
which I dare say it's unexpected (and not documented AFAIK). Are there any 
reasons why __class__ cannot be retrieved with object.__getattribute__ instead? 
In fact, considering that __getattribute__ could be overridden, this would be 
the right thing to do imho, else isinstance would break spectacularly, like in 
my previous example.

--

___
Python tracker 
<https://bugs.python.org/issue32683>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__

[Steven D'Aprano]

Steven D'Aprano  added the comment:

I'd be inclined to see this as a bug in your code, if you are causing 
side-effects from `__getattribute__`. If you don't want attribute access to 
cause side-effects, then don't put code in `__getattribute__` that causes 
side-effects :-)

isinstance has to check the object's `__class__`, if it has one. To do that it 
has to look at obj.__class__, which your class intercepts using 
`__getattribute__` and causes a side-effect.

Overloading `__getattribute__` is perilous, because it intercepts *all* 
instance attribute lookups. In my opinion, one should (almost?) never overload 
the `__getattribute__` method, it is safer to overload `__getattr__`.

In any case, I don't think there is anything to fix here. Dan has not responded 
since his initial bug report nearly four years ago, so I'm inclined to close 
this as "Not A Bug". Unless somebody gives a more convincing reason why the 
current behaviour is wrong, I think we should close it.

--

___
Python tracker 
<https://bugs.python.org/issue32683>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__

[Gabriele N Tornetta]

Gabriele N Tornetta  added the comment:

The following example shows isinstance causing a side effect


class Side:

class Effect(Exception):
pass

def __getattribute__(self, name):
raise Side.Effect()


isinstance(Side(), str)


I'd be inclined to see this as a bug as I wouldn't expect isinstance to cause 
any side effects.

--
nosy: +Gabriele Tornetta

___
Python tracker 
<https://bugs.python.org/issue32683>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29221] ABC Recursion Error on isinstance() with less than recursion limit class hierarchy depth

[Irit Katriel]

Irit Katriel  added the comment:

I am unable to reproduce this on 3.11. Is it still a problem?

--
nosy: +iritkatriel

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45891] bool variable isinstance of int

[noobie1000]

Change by noobie1000 :


--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45891] bool variable isinstance of int

[noobie1000]

noobie1000  added the comment:

Hello Steven,

Sorry, this is my first ever post and was lost in the enormity of 
issues/documentation. Noted your points :)

Thank you.

--
resolution: not a bug -> 
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45891] bool variable isinstance of int

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Hi noobie1000, 

This is not a general forum for asking questions about Python's design or 
language, this is for reporting bugs.

There are many forums where you can ask "Why" questions and ask for the 
community to "shed some light on this", such as Reddit's r/python, the various 
mailing lists, Discuss, IRC, etc. In future please use them rather than the bug 
tracker.

Regarding bool, you can start by reading this:

https://www.python.org/dev/peps/pep-0285/

If that doesn't answer your questions, please feel free to take them to the 
many different forums here:

https://www.python.org/community/forums/

https://www.python.org/community/lists/

https://www.python.org/community/irc/

--
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45891] bool variable isinstance of int

[Christian Heimes]

Christian Heimes  added the comment:

This is the expected behavior. The bool type is a subtype of int. True is int 1 
in disguise and False is int 0.

>>> bool.__mro__
(, , )

>>> True == 1
True
>>> True == 2
False

>>> False == 0
True

--
nosy: +christian.heimes

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45891] bool variable isinstance of int

[noobie1000]

New submission from noobie1000 :

Hello,

Recently I observed that isinstance(x, int) returns True, even when x is 
defined as a bool. While I understand that internally, a bool is treated as an 
int with values 0 and 1; to me, this is a bit misleading that the python 
interpreter returns True when we perform the isinstance() check. May be I'm 
missing some deeper explanation. Could someone please shed some light on this. 
Has this been discussed by the community in the past. Thank you very much for 
reading this ticket.

>>> x = True
>>> isinstance(x, int)
True

--
components: IO
messages: 406926
nosy: noobie1000
priority: normal
severity: normal
status: open
title: bool variable isinstance of int
type: behavior
versions: Python 3.6

___
Python tracker 
<https://bugs.python.org/issue45891>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45665] Problems caused by isinstance(list[int], type) returning True

[Martin Rueckl]

Martin Rueckl  added the comment:

Sorry for the noise: 
- Literal['a', 'b'],
- TypeVar('T')
Behave like Optional/Union

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45665] Problems caused by isinstance(list[int], type) returning True

[Martin Rueckl]

Martin Rueckl  added the comment:

One thing that probably should be considered in this context:

isinstance(arg, type) == issubclass(type(arg), type)

Holds True for arg in (Optional[X], Union[X, Y]). Both sides evaluate to False. 
(v3.10.0)

While I still think both sides evaluating to True would be more intuitive, this 
supports the proposed change.

Small test snippet:

```
from typing import Dict, List, Set, Tuple, Optional, Union

import pytest


@pytest.mark.parametrize('arg', [
list, List[int], list[int],
dict, Dict[str, int], dict[str, int],
set, Set[int], set[int],
tuple, Tuple[str, int], tuple[str, int],
Optional[int],
Union[int, str]
])
def test_invariant(arg):
same = isinstance(arg, type) == issubclass(type(arg), type)
result = "Check" if same else "Failed"
print(f"\n{result}: Testing: {arg=} with {type(arg)=}: {isinstance(arg, 
type)=} <> {issubclass(type(arg), type)=}")
assert same

```

Any other commonly used annotations that could be added to the checklist?

--
nosy: +martinitus

___
Python tracker 
<https://bugs.python.org/issue45665>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45665] Problems caused by isinstance(list[int], type) returning True

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
title: Problems caused by isinstance(list[int]) returning True -> Problems 
caused by isinstance(list[int], type) returning True

___
Python tracker 
<https://bugs.python.org/issue45665>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45665] Problems caused by isinstance(list[int]) returning True

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

isinstance(x, type) returns True for instances of types.GenericAlias (like 
list[int]). While it may help in some cases related to typing, in many 
unrelated cases it causes problems if the value which is not a type passes 
checks for types.

Also, isinstance(x, type) been not equal to issubclass(type(x), type) can cause 
other problems. No matter what the result should be, it should be consistent.

There are many occurrences of isinstance(..., type) in the code.

$ find Lib -name '*.py' \! -path '*/test*' -exec egrep 'isinstance.*,
type\)' '{}' + | wc -l
55

And all of them can potentially be broken if pass a types.GenericAlias 
instance. Many of them are safe, but every case should be analyzed.

--
dependencies: +Incorrect repr of InitVar of a type alias, help(list[int]) 
fails, inspect not capturing type annotations created by __class_getitem__, 
is_dataclass() does not work for dataclasses which are subclasses of 
types.GenericAlias, resolve_bases() and new_class() do not work with type alias 
of a built-in type
nosy: +gvanrossum, kj

___
Python tracker 
<https://bugs.python.org/issue45665>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45665] Problems caused by isinstance(list[int]) returning True

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

This is a meta-issue for problems caused by isinstance(list[int]) returning 
True.

See also discussion in issue45438.

--
components: Library (Lib)
messages: 405290
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Problems caused by isinstance(list[int]) returning True
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue45665>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44640] Fix punctuation in isinstance() error message

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset 39c4fe5e2b2ae5ac45c380b0a83e86bac3d7129c by Pablo Galindo (Miss 
Islington (bot)) in branch '3.10':
bpo-44640: Improve punctuation consistency in isinstance/issubclass error 
messages (GH-27144) (GH-28436)
https://github.com/python/cpython/commit/39c4fe5e2b2ae5ac45c380b0a83e86bac3d7129c


--

___
Python tracker 
<https://bugs.python.org/issue44640>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45282] isinstance(x, typing.Protocol-class) unexpectedly evaluates properties

[Alex Waygood]

Alex Waygood  added the comment:

Related: https://bugs.python.org/issue44904

--
nosy: +AlexWaygood

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45282] isinstance(x, typing.Protocol-class) unexpectedly evaluates properties

[Daisuke Takahashi]

New submission from Daisuke Takahashi :

Because __instancecheck__ of _ProtocolMeta uses hasattr() and getattr(), both 
of which evaluate property attributes, calling isinstance() with an object and 
a class that inherits typing.Protocol evaluates the input object's properties 
in some cases.

The attached testcases include three cases of checking subtype relationship of 
an instance (having a property "x" that may raise RuntimeError on evaluation) 
and following three protocol classes;
  (1) a protocol class having "x" as a property,
  (2) a protocol class having "x" as a data attribute, and
  (3) a protocol class having "x" as a class property that raises
   RuntimeError on evaluation (>= python 3.9 only).

Expected behavior:
1. The isinstance(obj, Protocol_class) does not evaluate anything but just 
checks existence of attribute names.
2. All cases in the attached testcases run without any error

Thank you very much in advance.

--
files: test_protocol_property.py
messages: 402562
nosy: daitakahashi
priority: normal
severity: normal
status: open
title: isinstance(x, typing.Protocol-class) unexpectedly evaluates properties
type: behavior
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50303/test_protocol_property.py

___
Python tracker 
<https://bugs.python.org/issue45282>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44640] Fix punctuation in isinstance() error message

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44640] Fix punctuation in isinstance() error message

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset 9c23a1ebade19f20c7d6e592a7d0329545a9a746 by Miss Islington (bot) 
in branch '3.10':
bpo-44640: Improve punctuation consistency in isinstance/issubclass error 
messages (GH-27144) (GH-28436)
https://github.com/python/cpython/commit/9c23a1ebade19f20c7d6e592a7d0329545a9a746


--
nosy: +pablogsal

___
Python tracker 
<https://bugs.python.org/issue44640>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44640] Fix punctuation in isinstance() error message

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset f4813388b4506b2fafb0089848c5b11cd503758c by wyz23x2 in branch 
'main':
bpo-44640: Improve punctuation consistency in isinstance/issubclass error 
messages (GH-27144)
https://github.com/python/cpython/commit/f4813388b4506b2fafb0089848c5b11cd503758c


--
nosy: +lukasz.langa

___
Python tracker 
<https://bugs.python.org/issue44640>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44640] Fix punctuation in isinstance() error message

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +26841
pull_request: https://github.com/python/cpython/pull/28436

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38085] Interrupting class creation in __init_subclass__ may lead to incorrect isinstance() and issubclass() results

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Confirmed that this weird behavior is still present.  Am not sure when someone 
will have the time and inclination to drill into the cause.

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38085] Interrupting class creation in __init_subclass__ may lead to incorrect isinstance() and issubclass() results

[Raymond Hettinger]

Change by Raymond Hettinger :


--
nosy: +lukasz.langa

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38085] Interrupting class creation in __init_subclass__ may lead to incorrect isinstance() and issubclass() results

[xitop]

xitop  added the comment:

2nd anniversary. Any reaction from developers would be appreciated. Thank you.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44932] `issubclass` and `isinstance` doesn't check for all 2nd argument types

[Guido van Rossum]

Guido van Rossum  added the comment:

Agreed. Thanks, Serhiy.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44932] `issubclass` and `isinstance` doesn't check for all 2nd argument types

[Ken Jin]

Ken Jin  added the comment:

Thank you for the examples Serhiy. I agree.

--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44932] `issubclass` and `isinstance` doesn't check for all 2nd argument types

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It is not specific to typing.

>>> isinstance(1, (int, 1))
True
>>> isinstance(1, (1, int))
Traceback (most recent call last):
  File "", line 1, in 
TypeError: isinstance() arg 2 must be a type or tuple of types
>>> issubclass(int, (int, 1))
True
>>> issubclass(int, (1, int))
Traceback (most recent call last):
  File "", line 1, in 
TypeError: issubclass() arg 2 must be a class or tuple of classes

isinstance() and issubclass() with tuples always stopped on first positive 
match. I don't think there is need to change this.

--

___
Python tracker 
<https://bugs.python.org/issue44932>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44932] `issubclass` and `isinstance` doesn't check for all 2nd argument types

[Ken Jin]

Ken Jin  added the comment:

@Paul, Steve, Tim and Zach, I've removed y'all from nosy as this isn't a 
Windows issue (but a typing/builtin types one). If you feel that I shouldn't 
have done that: my apologies and please do tell me.

To summarize what OP said:

>>> isinstance(bool, (bool, list[bool]))
TypeError: isinstance() argument 2 cannot be a parameterized generic

>>> issubclass(bool, (bool, list[bool]))
True

@OP, this seems like a bug. issubclass should raise according to PEP 585. In 
this case it's short-circuiting so it doesn't check the 2nd arg. Swapping the 
arguments around gives the expected TypeError.

>>> issubclass(bool, (list[bool], bool))
TypeError: issubclass() argument 2 cannot be a parameterized generic

At the same time, I'm hesitant to run a check through everything in the types 
tuple first. That would hurt issubclass performance (I'm not sure by how much). 
What do you think, Guido and Serhiy?

--
components: +Library (Lib) -Tests, Windows
nosy: +gvanrossum, kj, serhiy.storchaka -paul.moore, steve.dower, tim.golden, 
zach.ware
versions: +Python 3.11, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue44932>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44932] `issubclass` and `isinstance` doesn't check for all 2nd argument types

[theeshallnotknowethme]

New submission from theeshallnotknowethme :

When I tried using `isinstance` with a type (e.g. `bool`) as the 1st argument 
and a parameterized generic in a tuple (e.g. '(`bool`, `list[bool]`)') as the 
2nd argument, it raised a `TypeError`, 'isinstance() argument 2 cannot be a 
parameterized generic'. But when I did the same thing in `issubclass`, it 
returned a boolean and did not raise any `TypeError`s. Using `isinstance` with 
an object as the 1st argument and the same tuple 2nd argument also returned a 
boolean, and did not raise any `TypeError`s. Is this expected behaviour, or 
should this be fixed? This was tested in Python 3.10.0rc1 in a 64-bit system.

--
components: Tests, Windows
messages: 399717
nosy: February291948, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: `issubclass` and `isinstance` doesn't check for all 2nd argument types
type: behavior
versions: Python 3.10

___
Python tracker 
<https://bugs.python.org/issue44932>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44922] isinstance breaks on imported dataclasses

[Eric V. Smith]

Eric V. Smith  added the comment:

You're importing main.py twice. The first is when you run "python main.py", 
where it has the module name '__main__'. The second time is in codegen.py, 
where it has the name 'main'. You create the AtomX instance as __main__.AtomX, 
but the isinstance check is against main.AtomX. Because the objects have 
different modules, they're not equal.

You can see this if you change the isinstance check to:

=
from main import AtomX
import sys

def inheritance_map(candidate):
    assert isinstance(candidate, sys.modules['__main__'].AtomX)
==

Another way to see this if you add a print statement to the original codegen.py:

==
from main import AtomX

def inheritance_map(candidate):
print(f'{candidate=} {type(candidate)=} {AtomX=}')
    assert isinstance(candidate, AtomX)
==

Which will print:
candidate=AtomX(my_symbol='qwerty', quantity='') type(candidate)= AtomX=
Notice the types refer to different modules, so they are distinct and unequal.

The easiest way around this is to not do any work in main.py, but instead 
create another module, import it from main.py, and do the work there.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue44922>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44922] isinstance breaks on imported dataclasses

[Oleg Baskakov]

Oleg Baskakov  added the comment:

Sorry, I forgot to add if __name__ line:
```
import codegen
from dataclasses import dataclass

@dataclass
class AtomX:
my_symbol: str
quantity: str = ""


if __name__ == "__main__":
codegen.inheritance_map(AtomX("qwerty"))

```

So the output:
```
Traceback (most recent call last):
  File "/Users/baskakov/PycharmProjects/main.py", line 11, in 
codegen.inheritance_map(AtomX("qwerty"))
  File "/Users/baskakov/PycharmProjects/codegen.py", line 5, in inheritance_map
assert isinstance(candidate, AtomX)
AssertionError

```

--
Added file: https://bugs.python.org/file50221/main.py

___
Python tracker 
<https://bugs.python.org/issue44922>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44922] isinstance breaks on imported dataclasses

[Eric V. Smith]

Eric V. Smith  added the comment:

I get a circular import error:

Traceback (most recent call last):
  File "main.py", line 1, in 
import codegen
  File "/cygdrive/c/home/eric/codegen.py", line 1, in 
from main import AtomX
  File "/cygdrive/c/home/eric/main.py", line 9, in 
codegen.inheritance_map(AtomX("qwerty"))
AttributeError: partially initialized module 'codegen' has no attribute 
'inheritance_map' (most likely due to a circular import)

So I can't reproduce this problem.

--
nosy: +eric.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44922] isinstance breaks on imported dataclasses

[Oleg Baskakov]

New submission from Oleg Baskakov :

Hey I was trying to import dataclasses from another file and somehow isinstance 
doesn't work anymore:
main.py:
```
import codegen
from dataclasses import dataclass

@dataclass
class AtomX:
my_symbol: str
quantity: str = ""

codegen.inheritance_map(AtomX("qwerty"))

```
codegen.py:
```
from main import AtomX

def inheritance_map(candidate):
    assert isinstance(candidate, AtomX)
```

PS the same code with `assert candidate.__class__.__name__ == "AtomX"` works 
fine


Python 3.9.6 (v3.9.6:db3ff76da1, Jun 28 2021, 11:49:53) 
[Clang 6.0 (clang-600.0.57)] on darwin
I'm running inside of PyCharm

--
messages: 399628
nosy: baskakov
priority: normal
severity: normal
status: open
title: isinstance breaks on imported dataclasses
type: behavior
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue44922>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36881] isinstance raises TypeError for metaclass with metaclass=ABCMeta

[Irit Katriel]

Irit Katriel  added the comment:

PR27648 fixes this, but it also breaks test_abc.test_issubclass_bad_arguments 
so it's not quite right.


I don't know this area, but I think the problem is in the place the PR changes, 
and that the issue is due to this difference in the type of __subclasses__ 
between C and Meta2:

>>> class C: pass
... 
>>> from abc import ABCMeta
>>> class AbstractMeta(type, metaclass=ABCMeta): pass
... 
>>> class Meta2(AbstractMeta): pass
... 
>>> C.__subclasses__

>>> Meta2.__subclasses__


--
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36881] isinstance raises TypeError for metaclass with metaclass=ABCMeta

[Irit Katriel]

Change by Irit Katriel :


--
keywords: +patch
nosy: +iritkatriel
nosy_count: 7.0 -> 8.0
pull_requests: +26142
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/27648

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44640] Fix punctuation in isinstance() error message

[wyz23x2]

Change by wyz23x2 :


--
title: Typos in error messages of isinstance() & issubclass() -> Fix 
punctuation in isinstance() error message

___
Python tracker 
<https://bugs.python.org/issue44640>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44640] Typos in error messages of isinstance() & issubclass()

[wyz23x2]

wyz23x2  added the comment:

Changed to only 2).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44640] Typos in error messages of isinstance() & issubclass()

[Jack DeVries]

Jack DeVries  added the comment:

The current string is correct. The word "union" is actually an exception to the 
"a/an" rule. Here is more detail:

https://english.stackexchange.com/questions/266309/why-is-union-an-exception-to-the-a-an-rule

--
nosy: +jack__d

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44640] Typos in error messages of isinstance() & issubclass()

[wyz23x2]

Change by wyz23x2 :


--
keywords: +patch
pull_requests: +25686
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/27144

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44640] Typos in error messages of isinstance() & issubclass()

[wyz23x2]

New submission from wyz23x2 :

>>> isinstance(2, 1)
Traceback (most recent call last):
  ...
TypeError: isinstance() arg 2 must be a type, a tuple of types or a union
>>> issubclass(int, 1)
Traceback (most recent call last):
  ..
TypeError: issubclass() arg 2 must be a class, a tuple of classes, or a union.

1) It should be "an union", not "a union".
2) The punctuation marks aren't the same -- there's a comma before "or" in 
issubclass, but not isinstance(). And issubclass()'s ends with a period, which 
isn't the same with other builtins' messages.

--
components: Interpreter Core
messages: 397499
nosy: wyz23x2
priority: normal
severity: normal
status: open
title: Typos in error messages of isinstance() & issubclass()
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue44640>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44606] Discrepancy between isinstance() and issubclass() for union types

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44606] Discrepancy between isinstance() and issubclass() for union types

[miss-islington]

miss-islington  added the comment:


New changeset b42eee78e7651693aa38c390f577e5d499dcf55d by Miss Islington (bot) 
in branch '3.10':
bpo-44606: Fix __instancecheck__ and __subclasscheck__ for the union type. 
(GH-27120)
https://github.com/python/cpython/commit/b42eee78e7651693aa38c390f577e5d499dcf55d


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44606] Discrepancy between isinstance() and issubclass() for union types

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 81989058de381108dfd0a4255b93d4fb34417002 by Serhiy Storchaka in 
branch 'main':
bpo-44606: Fix __instancecheck__ and __subclasscheck__ for the union type. 
(GH-27120)
https://github.com/python/cpython/commit/81989058de381108dfd0a4255b93d4fb34417002


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44606] Discrepancy between isinstance() and issubclass() for union types

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +25675
pull_request: https://github.com/python/cpython/pull/27132

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44606] Discrepancy between isinstance() and issubclass() for union types

[Ken Jin]

Ken Jin  added the comment:

> 3. There is also a crash in isinstance():

That's unfortunate :(.

Serhiy, thanks for catching all these bugs in union. I recently realized you 
probably made 50% of all bug reports for union and they're very much 
appreciated :).

> Converting None to type(None) will be done in other PR.

Alright. Do tell me if you're too busy and want me to take it up instead. I'll 
be glad to help.

--

___
Python tracker 
<https://bugs.python.org/issue44606>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44606] Discrepancy between isinstance() and issubclass() for union types

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

PR 27120 fixes __instancecheck__ and __subclasscheck__. Converting None to 
type(None) will be done in other PR.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44606] Discrepancy between isinstance() and issubclass() for union types

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
type: behavior -> crash

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44606] Discrepancy between isinstance() and issubclass() for union types

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +25665
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/27120

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44606] Discrepancy between isinstance() and issubclass() for union types

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

3. There is also a crash in isinstance():

>>> class BadMeta(type):
... def __instancecheck__(cls, inst):
... 1/0
... 
>>> x = int | BadMeta('A', (), {})
>>> isinstance([], x)
Fatal Python error: _Py_CheckFunctionResult: a function returned a result with 
an exception set
Python runtime state: initialized
Traceback (most recent call last):
  File "", line 3, in __instancecheck__
ZeroDivisionError: division by zero

The above exception was the direct cause of the following exception:

SystemError:  returned a result with an exception set

Current thread 0x7f024beb1280 (most recent call first):
  File "", line 1 in 
Aborted (core dumped)

--

___
Python tracker 
<https://bugs.python.org/issue44606>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44606] Discrepancy between isinstance() and issubclass() for union types

[Ken Jin]

Ken Jin  added the comment:

@Serhiy, can I work on converting None to type(None) please?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44606] Discrepancy between isinstance() and issubclass() for union types

[Guido van Rossum]

Guido van Rossum  added the comment:

Converting None to type(None) is fine, as long as the str() /repr()
converts it back, e.g. repr(int | None) should print just that, not
NoneType.--
--Guido (mobile)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com