[issue41370] PEP 585 and ForwardRef

Niklas Rosenstein added the comment: I've started a pull request here: https://github.com/python/cpython/pull/30900 -- ___ Python tracker <https://bugs.python.org/issue41

[issue41370] PEP 585 and ForwardRef

Change by Niklas Rosenstein : -- pull_requests: +29079 pull_request: https://github.com/python/cpython/pull/30900 ___ Python tracker <https://bugs.python.org/issue41

[issue41370] PEP 585 and ForwardRef

Niklas Rosenstein added the comment: Interesting! Representing the entire type hint as a string is something I haven't thought about, but it makes sense that it works. It is my understanding that `get_type_hint()` already walks through the entire type hint recursively. If it weren't

[issue41370] PEP 585 and ForwardRef

Niklas Rosenstein added the comment: It was not my intention to sound passive agressive. Thanks for providing the context around the time PEP 585 was discussed. Frankly, I believe I have explained the problem quite well. But I would like to propose a solution. I can't judge in what

[issue41370] PEP 585 and ForwardRef

Niklas Rosenstein added the comment: You're right, let me trim it down: In production we use `get_type_hints()` a lot, expecting it to resolve strings as forward references as per it's original API contract. However, PEP 585 generics parametrized with strings in Python 3.10 doesn't work

[issue41370] PEP 585 and ForwardRef

Niklas Rosenstein added the comment: Guido, sorry for the late response on this. I have a work around, but it involves passing along my own "context" from which to resolve strings on the go as they are encountered while decomposing the type hint. https://github.com/NiklasRosenstei

[issue41370] PEP 585 and ForwardRef

Niklas Rosenstein added the comment: I'm running into this issue right now. Can anyone provide a rationale as to why you think this is acceptable/expected behaviour? Do we expect developers to semi-rely on get_type_hints(), but than still having to manually resolve forward references

[issue43749] venv module does not copy the correct python exe

Niklas Rosenstein added the comment: To complete my previous comment, patching the function to see the command that is invoked, you can see it tries to invoke 'python3.exe' (seemingly derived from sys.executable) in the venv but the venv only contains 'python.exe'. ['C:\\Users\\niklas

[issue43749] venv module does not copy the correct python exe

Niklas Rosenstein added the comment: I just encountered the same behavior. Steps to reproduce: * Install Python 3 (I used 3.9.5) on Windows * Use the Admin console to create a python3.exe link, e.g. cd "c:/Users/niklas/AppData/Local/Programs/Python/Python39" mklink p

[issue35383] lib2to3 raises ParseError on argument called "print"

New submission from Niklas Rosenstein : On Python 3.7.0 lib2to3 will not parse code like this: def foo(print=None): pass and yield the following error instead lib2to3.pgen2.parse.ParseError: bad input: type=1, value='print', context=('', (1, 8)) -- components: 2to3 (2

[issue33337] Provide a supported Concrete Syntax Tree implementation in the standard library

Niklas Rosenstein added the comment: Lukasz, have you created a 3rd party package branching off lib2to3? I'm working on a project that is based on it (in a similar usecase as YAPF and Black) and was hoping that there may be some version maintained distinctly from the Python release schedule

[issue33262] Deprecate shlex.split(None) to read from stdin.

Niklas Rosenstein added the comment: I've just run into this as well -- I thought it was a bug until I found this issue. I also think that this is anything from sane. -- nosy: +n_rosenstein ___ Python tracker <https://bugs.python.org/issue33