[issue46581] _typevar_types and _paramspec_tvars are missing from _GenericAlias.copy_with
Matt B added the comment: Thanks, @kj! Fantastic education and insight! I'm sad that I needed you as an interpreter but very grateful you were around to provide the interpretation. Working on a patch now…. -- ___ Python tracker <https://bugs.python.org/issue46581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46581] _typevar_types and _paramspec_tvars are missing from _GenericAlias.copy_with
Matt B added the comment: I am happy to attempt a patch, but I don't understand what's going on with _ConcatenateGenericAlias. Or rather, I don't fully understand the various copy_with semantics. This code is *very* hard to follow. Patching _GenericAlias.copy_with seems relatively straightforward: def copy_with(self, params): -return self.__class__(self.__origin__, params, name=self._name, inst=self._inst) +return self.__class__(self.__origin__, params, name=self._name, inst=self._inst, + _typevar_types=self._typevar_types, + _paramspec_tvars=self._paramspec_tvars) _ConcatenateGenericAlias.copy_with, on the other hand, appears to return a tuple rather than a type until it falls back to the parent implementation. What does one do with that? Also, what about _AnnotatedAlias, _SpecialGenericAlias, _UnionGenericAlias, or _strip_annotations? Do any of those need to be modified? I can't find any tests that deal with copy_with directly, so I'm assuming its use is stressed via higher level code paths, but it's not clear what use cases that method is supposed to serve. The good news is that its use is confined to typing.py. The bad news is that file gives little insight to those who aren't already experts in that territory. In short, I will do my best, but I suspect I will need patience and guidance in arriving something acceptable. -- ___ Python tracker <https://bugs.python.org/issue46581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46581] _typevar_types and _paramspec_tvars are missing from _GenericAlias.copy_with
Matt B added the comment: Filed by request: https://github.com/python/cpython/pull/26091#issuecomment-1024900261 -- ___ Python tracker <https://bugs.python.org/issue46581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46581] _typevar_types and _paramspec_tvars are missing from _GenericAlias.copy_with
New submission from Matt B : c55ff1b352f8b82184f80d9dea220e832691acfc was submitted to fix #44098 and added the _typevar_types and _paramspec_tvars properties to _GenericAlias. However, those properties continue to be omitted from _GenericAlias.copy_with[1]. Further, typing.py is fairly intricate, which makes it hard to understand if that is the only place those properties are absent. A more careful review/audit may be in order. [1]: https://github.com/python/cpython/blob/8b1b27f1939cc4060531d198fdb09242f247ca7c/Lib/typing.py#L1069-L1070 -- components: Library (Lib) messages: 412144 nosy: posita priority: normal severity: normal status: open title: _typevar_types and _paramspec_tvars are missing from _GenericAlias.copy_with versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue46581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42343] threading.local documentation should be on the net...
Matt B added the comment: @ztane, if you are interested in trying your hand at a PR, these will be generally useful: * https://devguide.python.org/ * https://devguide.python.org/documenting/ -- ___ Python tracker <https://bugs.python.org/issue42343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42343] threading.local documentation should be on the net...
Matt B added the comment: @rhettinger, the docstring[1] alluded to in the docs is quite lengthy. Are you suggesting copying it straight across to the standard library documentation? If not, can you give (or link to) some documentation standards or other guidance on constructing a viable PR? Also, for newcomer friendly issues, it is helpful to link to instructions on how to construct and submit a PR for review. That will increase the likelihood of a community-provided fix. [1]: https://github.com/python/cpython/blob/main/Lib/_threading_local.py -- nosy: +posita ___ Python tracker <https://bugs.python.org/issue42343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46133] Feature request: allow mechanism for creator of exec-generated code to provide source to pdb
Matt B added the comment: Please treat this as a feature request to add the ability for pdb (and internals) to ingest sources for exec-generated code. -- ___ Python tracker <https://bugs.python.org/issue46133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46133] Feature request: allow mechanism for creator of exec-generated code to provide source to pdb
Change by Matt B : -- resolution: not a bug -> ___ Python tracker <https://bugs.python.org/issue46133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46133] Feature request: allow mechanism for creator of exec-generated code to provide source to pdb
Change by Matt B : -- status: closed -> open title: Unclear whether one can (or how to) provide source to exec-generated code -> Feature request: allow mechanism for creator of exec-generated code to provide source to pdb type: behavior -> enhancement ___ Python tracker <https://bugs.python.org/issue46133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46133] Unclear whether one can (or how to) provide source to exec-generated code
Change by Matt B : -- components: +Library (Lib) type: -> behavior versions: +Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46133] Unclear whether one can (or how to) provide source to exec-generated code
New submission from Matt B :
Unless I missed it, looking at
https://github.com/python/cpython/blob/main/Lib/pdb.py,
https://github.com/python/cpython/blob/main/Lib/inspect.py, and
https://docs.python.org/3/library/pdb.html doesn't give much of a clue how to
provide sources to exec-generated code.
I may have misread, but pdb *seems* to lean on inspect.findsource which
eventually excludes sources that match `^<.*>$` (like ``).
Running attached test_case.py:
% python test_case.py
> (4)foo()
(Pdb) l
[EOF]
(Pdb) c
inspect.getfile():
calling inspect.findsource() ...
Traceback (most recent call last):
File "/Users/matt/Documents/dev/numerary/test_case.py", line 12, in
foo()
File
"/Library/Frameworks/MacPorts-20200907/Python.framework/Versions/3.9/lib/python3.9/inspect.py",
line 835, in findsource
raise OSError('could not get source code')
OSError: could not get source code
--
files: test_case.py
messages: 408910
nosy: posita
priority: normal
severity: normal
status: open
title: Unclear whether one can (or how to) provide source to exec-generated code
Added file: https://bugs.python.org/file50502/test_case.py
___
Python tracker
<https://bugs.python.org/issue46133>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4033] python search path - .pth recursion
Changes by Matt B mbau...@gmail.com: -- nosy: +Matt.B ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4033 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8247] Can't Import Tkinter
New submission from Matt B mattc...@earthlink.net: import _tkinter Traceback (most recent call last): File stdin, line 1, in module ImportError: DLL load failed: %1 is not a valid Win32 application. I 'upgraded' to python 2.6.5 by downloading the windows 64 bit installer. I'm running windows 7 64 bit. Everything worked great in 2.6.4 by the way. I had a similar problem with numpy, but reinstalling it from this site seemed to fix it: http://www.lfd.uci.edu/~gohlke/pythonlibs/ I can only speculate what happened. If I knew what DLL failed to load I could easily check to see if there were dependency issues or 64/32 bit issues. Perhaps the old dll is still around? If so then there is an issue with the installer I think. No doubt the issues extends beyond just Tkinter. -- components: Tkinter messages: 101852 nosy: SevenThunders severity: normal status: open title: Can't Import Tkinter versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
