[issue37920] Support subscripting os.PathLike and make it valid at runtime

Guido van Rossum added the comment: Sounds like you are mixing up analyzing .pyi and .py files. Anyway, let's not do this. -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker

[issue37920] Support subscripting os.PathLike and make it valid at runtime

Cameron Trando added the comment: What happened is that we have a hard time analyzing PathLike because in the pathlib stub they use PathLike[str], so when we try to analyze Path which inherits from PathLike[str], because PathLike is not generic, then we think it's an instance of an object

[issue37920] Support subscripting os.PathLike and make it valid at runtime

Ivan Levkivskyi added the comment: There is an (old) similar proposal https://github.com/python/typing/issues/402 btw. Taking into account that this can be made only in 3.9, what is the benefit over ``from __future__ import annotations`` (that one can use already) do you see? IMO there are

[issue37920] Support subscripting os.PathLike and make it valid at runtime

Guido van Rossum added the comment: Making an existing stdlib class generic has to be considered carefully, otherwise it may break backward compatibility. As I wrote in the typeshed issue, I actually think the status quo is fine. But I'd like to hear you out about how it causes problems in

[issue37920] Support subscripting os.PathLike and make it valid at runtime

Change by Serhiy Storchaka : -- nosy: +gvanrossum, levkivskyi ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37920] Support subscripting os.PathLike and make it valid at runtime

New submission from Cameron Trando : Currently os.PathLike[str] causes a runtime error; however, typeshed sees it as valid and mypy does not throw any errors on it. mypy treats it as os.PathLike[AnyStr] I already filed a bug on typeshed, see https://github.com/python/typeshed/issues/3202