[issue22240] argparse support for "python -m module" in help
Nils Kattenbeck added the comment: I implemented the logic and adjusted the existing tests to have a fixed program name. I also fixed the build error by changing how zip files are detected. Based on you comment Nick you however even had a different idea. Currently I check if __spec__.__loader__ is a zip loader but if I understood correct you suggest the check if __spec__.__location__ is a proper subdir of sys.argv[0]? https://github.com/septatrix/cpython/compare/main...septatrix:enhance/argparse-prog-name. When I have some more time I will check whether mocking works and otherwise checkout test.support.script_helper or making the function accept spec/argv0 -- ___ Python tracker <https://bugs.python.org/issue22240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13824] argparse.FileType opens a file and never closes it
Nils Kattenbeck added the comment: A good alternative would be to use pathlib.Path. The only downside would be that one has to manually handle `-` but besides that it solves most problems. Still the fact that file descriptors are kept open should be added as a warning to the docs -- nosy: +Nils Kattenbeck ___ Python tracker <https://bugs.python.org/issue13824> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22240] argparse support for "python -m module" in help
Nils Kattenbeck added the comment: I expanded the patch from tebeka to also work with invocations like `python3 -m serial.tools.miniterm` where `miniterm.py` is a file and not a directory with a `__main__.py`. This was able to handle everything I threw at it. However due to the import of zipfile which itself imports binascii the build of CPython itself fails at the `sharedmods` stage... ```text CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -fwrapv -O3 -Wall' _TCLTK_INCLUDES='' _TCLTK_LIBS='' ./python -E ./setup.py build Traceback (most recent call last): File "/home/septatrix/Documents/programming/cpython/./setup.py", line 3, in import argparse ^^^ File "/home/septatrix/Documents/programming/cpython/Lib/argparse.py", line 93, in from zipfile import is_zipfile as _is_zipfile ^ File "/home/septatrix/Documents/programming/cpython/Lib/zipfile.py", line 6, in import binascii ^^^ ModuleNotFoundError: No module named 'binascii' make: *** [Makefile:639: sharedmods] Error 1 ``` I guess this is because binascii is a c module and not yet build at that point in time. Does anyone who knows more about the build system have an idea how to resolve this? --- Resolving this bug would also allow the removal of several workarounds for this in the stdlib: * https://github.com/python/cpython/blob/83d1430ee5b8008631e7f2a75447e740eed065c1/Lib/unittest/__main__.py#L4 * https://github.com/python/cpython/blob/83d1430ee5b8008631e7f2a75447e740eed065c1/Lib/json/tool.py#L19 * https://github.com/python/cpython/blob/83d1430ee5b8008631e7f2a75447e740eed065c1/Lib/venv/__init__.py#L426 -- Added file: https://bugs.python.org/file50174/patch.diff ___ Python tracker <https://bugs.python.org/issue22240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22240] argparse support for "python -m module" in help
Nils Kattenbeck added the comment: I am not sure if the patch correctly handles calling a nested module (e.g. `python3 -m serial.tools.miniterm`). Would it also be possible to detect if python or python3 was used for the invocation? -- nosy: +Nils Kattenbeck ___ Python tracker <https://bugs.python.org/issue22240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41249] TypedDict inheritance doesn't work with get_type_hints and postponed evaluation of annotations across modules
Nils Kattenbeck added the comment: > The way I fixed this is I added `__forward_module__` to `typing.ForwardRef`, > so that it can resolve the forward reference with the same globals as the > ones specified by the module in `__forward_module__`. `TypedDict`'s metaclass > should then pass the dictionary’s module name to the annotations’ forward > references via the added `module`’s keyword argument in > `typing._type_check()`. I can work in a pull request with this solution and > discuss any potential problems. While this seems like a good solution I would still like to figure out why TypedDict do not preserve MRO. Because for now I have not found a reason nor did someone on the typing-sig mailinglist have a clue. Should there (no longer) be a reason for this then this problem has a trivial solution (just re-add the MRO and use that). -- ___ Python tracker <https://bugs.python.org/issue41249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41249] TypedDict inheritance doesn't work with get_type_hints and postponed evaluation of annotations across modules
Nils Kattenbeck added the comment: > I believe it had something to do with TypedDict instances being instances of > dict at runtime, but I can't actually reconstruct the reason. Hm that may be true. My limited low-level Python knowledge leads me to believe that this could also be done using __new__ but I also read that most magic methods get called as type(Foo).__magic__(bar, ...) so that might not be possible. (However also no methods can be declared on a TypedDict class so that might not be a problem?) > Maybe it's written up in PEP 589, but I suspect not (I skimmed and couldn't > find it). I read it completely and could not find anything > If you ask on typing-sig maybe David Foster (who contributed the initial idea > and implementation) remembers. I asked [here on typing-sig](https://mail.python.org/archives/list/typing-...@python.org/thread/RNFWPRLHTUTZES2FDSSMY472JFGMD4EW/) but did not yet get any responses. -- ___ Python tracker <https://bugs.python.org/issue41249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41249] TypedDict inheritance doesn't work with get_type_hints and postponed evaluation of annotations across modules
Nils Kattenbeck added the comment: What is/was the initial reason to not preserve the MRO for a TypedDict? The only thing which came to my mind would be instantiation performance but as annotations are not evaluated by default and on the right-hide side of assignment most people will use dict literals I am not sure if this is still relevant. Otherwise it might even be simpler to just preserve the original bases in TypedDict but please correct me if I overlooked something -- nosy: +Nils Kattenbeck ___ Python tracker <https://bugs.python.org/issue41249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25024] Allow passing "delete=False" to TemporaryDirectory
Nils Kattenbeck added the comment: While the proposal linked by C.A.M. solves one of the use cases but it does not address the others. One use cases which is rather common for me it is e.g. to have scripts/programs which allow configuring whether temporary directories should get deleted or stay persistent after program exit. Currently this always requires hand rolled wrappers like the following: def mkdtemp_persistent(*args, persistent=True, **kwargs): if persistent: @contextmanager def normal_mkdtemp(): yield tempfile.mkdtemp() return normal_mkdtemp(*args, **kwargs) else: return tempfile.TemporaryDirectory(*args, **kwargs) with mkdtemp_persistent(persistent=False) as dir: ... Which gets the job done but is not as user friendly as other parts of the stdlib. -- nosy: +Nils Kattenbeck ___ Python tracker <https://bugs.python.org/issue25024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1717] Get rid of more references to __cmp__
Nils Kattenbeck added the comment: Has there been any resolution regarding `sortTestMethodsUsing`? See https://bugs.python.org/msg77261 I spend a decent time and read the documentation thrice before realizing it received an old-style compare function. Brett's proposal for a new attribute seems like a sane way to do this without breaking backwards compatibility. Or will this continue using an old-style compare function for the foreseeable future? -- nosy: +Nils Kattenbeck ___ Python tracker <https://bugs.python.org/issue1717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44137] importlib.resources.path raises RuntimeError when FileNotFoundError is raise in context manager
Nils Kattenbeck added the comment: Thanks for looking into it. Yes I can confirm that `importlib_resources` has the expected behaviour - I did not download Python 3.10 as the code seems to be the same. -- ___ Python tracker <https://bugs.python.org/issue44137> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44137] importlib.resources.path raises RuntimeError when FileNotFoundError is raise in context manager
Nils Kattenbeck added the comment: Yes I understand that the function handles this specially to not raise an exception if the file is not found in the package (even though the intention behind this is not clear to me). However if a user causes a FileNotFoundException itself inside of the context manager everything breaks (e.g. does something erroneous with the path, calls subprocess.run with a non existing binary etc). -- ___ Python tracker <https://bugs.python.org/issue44137> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44137] importlib.resources.path raises RuntimeError when FileNotFoundError is raise in context manager
Change by Nils Kattenbeck : -- title: importlib.resources.path raises RuntimeError import FileNotFoundError is raise in context manager -> importlib.resources.path raises RuntimeError when FileNotFoundError is raise in context manager ___ Python tracker <https://bugs.python.org/issue44137> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44137] importlib.resources.path raises RuntimeError import FileNotFoundError is raise in context manager
New submission from Nils Kattenbeck :
When a FileNotFoundError is raised inside while the importlib.resources.path
context manager is active a RuntimeError is raised.
Looking at the (3.8) code it seems that FileNotFound exceptions are handled
specially from all other exceptions which may lead to this behaviour. While the
code in 3.9 changed significantly the same behaviour can be observed.
Files:
.
└── my_package
├── data.txt (empty)
├── __init__.py (empty)
└── test.py
Content of test.py:
import importlib.resources
def main():
with importlib.resources.path('my_package', 'data.txt') as p:
raise FileNotFoundError()
if __name__ == '__main__':
main()
Exact error message:
RuntimeError: generator didn't stop after throw()
--
components: Library (Lib)
messages: 393686
nosy: Nils Kattenbeck, brett.cannon, jaraco
priority: normal
severity: normal
status: open
title: importlib.resources.path raises RuntimeError import FileNotFoundError is
raise in context manager
type: behavior
versions: Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue44137>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38756] Add generic versions of weakref types to typing module
Nils Kattenbeck added the comment: Okay, if I want to start a discussion about adding weakref types to PEP 585 where should do it? The mailing list or as an issue in the PEP repo? -- ___ Python tracker <https://bugs.python.org/issue38756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38761] weakref.WeakSet not instanceof collections.abc.Set
New submission from Nils Kattenbeck : Instances of weakref.WeakSet are not instances of Set and therefore not of MutableSet but they are instances of Collection. They however implement all required methods for a MutableSet and Weak(Key|Value)Dictionary are correctly identified. Is this just an oversight or am I missing something? from weakref import WeakKeyDictionary, WeakValueDictionary, WeakSet from collections.abc import MutableMapping, Collection, Set, MutableSet wkdict = WeakKeyDictionary() wvdict = WeakValueDictionary() ws = WeakSet() assert isinstance(wkdict, MutableMapping) assert isinstance(wvdict, MutableMapping) assert isinstance(ws, Collection) assert not isinstance(ws, Set) assert not isinstance(ws, MutableSet) -- components: Library (Lib) messages: 356326 nosy: Nils Kattenbeck priority: normal severity: normal status: open title: weakref.WeakSet not instanceof collections.abc.Set versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue38761> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38756] Add generic versions of weakref types to typing module
Nils Kattenbeck added the comment: Okay nevermind, after looking in the PEP again and inspecting the __annotations__ property I learned that annotations are never evaluated and just saved as a string when using said future statement. However this may still be relevant as typing.get_type_hints will still fail. For my use case however this is sufficient. -- ___ Python tracker <https://bugs.python.org/issue38756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38756] Add generic versions of weakref types to typing module
Nils Kattenbeck added the comment: Yes thank you, using 'from __future__ import annotations' works fantastic. I did not knew about this functionality of the annotations future import statement, I thought it was only for postponed evaluation but I probably missed something in the PEP... -- ___ Python tracker <https://bugs.python.org/issue38756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38756] Add generic versions of weakref types to typing module
Nils Kattenbeck added the comment: A possible use case would be having multiple users and some groups said users can belong to. When using a WeakSet a user won't be part of a groups after he deleted his account without having to iterate over all groups. class User: pass class Group: users: WeakSet[User] def __init__(self, users: Iterable[User]): self.users = WeakSet(users) # somewhere else a collection of all active users Types I would like to see added as a generic would be primarily: - WeakKeyDictionary - WeakValueDictionary - WeakSet Additionally it would be nice to have generic versions of: - ref (would probably return Optional[T] on call?) - WeakMethod - ProxyType - CallableProxyType Although the last two could probably be just annotated using T because they mostly should behave the same... -- ___ Python tracker <https://bugs.python.org/issue38756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38756] Add generic versions of weakref types to typing module
New submission from Nils Kattenbeck : I would like to request the addition of generic variants of some of the types in weakref to the typing module. This would for example include weakref.WeakKeyDictionary among others. Doing so would allow one to add type annotations to code using such data structures. -- components: Library (Lib) messages: 356304 nosy: Nils Kattenbeck priority: normal severity: normal status: open title: Add generic versions of weakref types to typing module type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue38756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
