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

[Guido van Rossum]

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 

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

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

[Cameron Trando]

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 and don't inherit from it. That means Path has 
incorrect bases.

Previously we assumed we only had to special case typing so we will special 
case PathLike as well.

--

___
Python tracker 

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

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

[Ivan Levkivskyi]

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 only rare cases of type aliases and base classes, so I don't see 
much benefit. Also making it generic will require importing ``typing`` from 
``os`` which may make it slower to import (``typing`` is a really heavy module, 
in particular because it imports many other modules).

--

___
Python tracker 

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

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

[Guido van Rossum]

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 VS Code (that can't be 
fixed by adapting VC Code to reality).

--
versions: +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

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

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
nosy: +gvanrossum, levkivskyi

___
Python tracker 

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

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

[Cameron Trando]

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

And since mypy interprets it as useful, cpython should try and support it as 
well.

--
messages: 350221
nosy: Cameron Trando
priority: normal
severity: normal
status: open
title: Support subscripting os.PathLike and make it valid at runtime
type: behavior
versions: Python 3.7

___
Python tracker 

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