Implicit type aliases not recognised with PEP 604 + import cycles #11887
Comments
|
I think you miiiiight be able to use PEP 613 as a workaround. |
|
Import cycles involving builtins can do some scary things, here's a bug I ran into: #11535 |
|
I did some tracing of the code involved. Looking at semanal's Line 2190 in 1beed9a If we encounter If we encounter This check succeeds for the left side ( So mypy knows that So two things that could mechanically fix this:
Unfortunately, I'm not yet sure what the best way to ensure either of those. The secret to both lies back in Line 2070 in 1beed9a I don't fully understand the reference tagging thing, but tldr the import cycle causes us to skip calling Moreover, the placeholder's Line 2075 in 1beed9a I'm not sure how we could know becomes_typeinfo=True at this point, although we could know could_become_type.
.... 🤷 Anyway, for typeshed purposes, maybe just use PEP 613 :-) (works because we don't need the result of |
It's defined here in my branch, no? 🙂 note that my branch doesn't make any kind of sense from a typing perspective, I was just trying to delete as many modules as possible while still being able to reproduce the bug!! |
Thanks for taking the time to look into it!! This is a great rundown.
Unfortunately, I think PEP 613 may still be unuseable for typeshed purposes — I'm not sure if pytype supports it yet 😕 (google/pytype#787) but, worth a shot! For this specific instance of the bug, it seems like it can be fixed just by doing |
hauntsaninja
changed the title
When debugging python#11887 I realised `can_be_type_alias` can do non-trivial amounts of work. It's unlikely to ever show up on a profile, but reordering the check means we do less work. Changed the order of some other checks for consistency.
Oh wait, yes, lol — I was experimenting to see if the I left that in by mistake when I pushed to my remote branch — sorry for the confusion!! |
"smol typeshed" should now be fixed by AlexWaygood/typeshed@79f1d16 -- the only error from mypy is now: |
Okay, this is very strange. If I'm in the branch of typeshed with nearly all modules deleted, and But if I just run Any idea why mypy 0.930 is succeeding, but stubtest 0.930 is failing with "mypy build errors"?? |
Currently python/typeshed#6819 has the same problem. |
|
You should now be able to reproduce the bug in "smol typeshed" by simply running |
|
Okay, I think I have managed to create a repro for this issue that is only 11 lines of code, spread over 6 files. SO, to reproduce:
Here's what the minimal repro looks like: # _typeshed.pyi
import mmap
WriteableBuffer = mmap.mmap
ReadableBuffer = str | WriteableBuffer
# abc.pyi: empty file
# builtins.pyi
import typing
from _typeshed import ReadableBuffer
class str: ...
class ellipsis: ...
Foo: ReadableBuffer
# collections.pyi: empty file
# mmap.pyi
class mmap: ...
# typing.pyi
import abc
import collections |
…ython#11904) When debugging python#11887 I realised `can_be_type_alias` can do non-trivial amounts of work. It's unlikely to ever show up on a profile, but reordering the check means we do less work. Changed the order of some other checks for consistency. Co-authored-by: hauntsaninja <>
|
To clarify current state, this issue is patched for stubs, but remains for py files (where we can't blindly treat If you run into this, your best option is likely using an explicit type alias ( |
This bug was originally surfaced by python/typeshed#6612. It is hard to tell if it is the only bug that was revealed by that PR, or if there are other PEP 604-related bugs in mypy.
Top-line summary
If a single line in
typeshed/stdlib/_typeshed/__init__.pyiis changed from usingUnionto PEP 604-style syntax, a large number of errors are output by mypy:Mypy errors
Investigation
This bug is hard to pin down. I have not managed to reproduce it outside of the typeshed repo.
I have managed to reproduce the bug in a branch of typeshed in which the vast majority of the stdlib has been deleted. This indicates to me that the bug has something to do with an interaction between
builtins,_typeshedandmmap. In this "slimmed-down" version of typeshed, I see the following errors from mypy:Notes on the bug
The bug can be reproduced if
ReadableBufferis defined like this in_typeshed:However...
(1) It cannot be reproduced if
ReadableBufferis defined like this intypeshed:(2) Nor can it be reproduced if
ReadableBufferis defined like this intypeshed:(3) If the definition of
ReadableBufferis moved tobuiltins, the errors inbuiltinsandiothat you see in "slimmed-down typeshed" continue to be reported by mypy.(4) The errors in the
iomodule that you see in "slimmed-down typeshed" do not exist ifiodefines its own version ofReadableBuffer, instead of importing the definition from_typeshedorbuiltins.Expected behaviour
No error should be reported; the semantics of
typing.Unionand PEP 604 union-type expressions should be identical.mypy version
0.930. Reproduced on many Python versions by the typeshed CI; local testing done on Python 3.10.
To reproduce
mypy stdlib/abc.pyi --custom-typeshed-dir .(the precise file you run mypy on is irrelevant).Cc. @sobolevn, @JukkaL, @Akuli
The text was updated successfully, but these errors were encountered: