[issue46133] Feature request: allow mechanism for creator of exec-generated code to provide source to pdb
Spencer Brown added the comment: There is a solution to this: you can modify the linecache module's cache to add lines under a fake filename, which is the approach attrs takes here: https://github.com/python-attrs/attrs/blob/9727008fd1e40bc55cdc6aee71e0f61553f33127/src/attr/_make.py#L347 However, there are several downsides. - That dict isn't documented or appears in __all__, so it's arguably private. - The C implementation of traceback printing opens files directly, so this doesn't work there. - You have to invent a unique filename, and manually remove lines from the cache if the function is later deleted. This does affect both namedtuple and dataclasses, though it's probably not too important given how straightforward the generated code they produce is. -- nosy: +Spencer Brown ___ 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
[issue46382] dataclass(slots=True) does not account for slots in base classes
Spencer Brown added the comment: Both will function, but class B will add its slots after A's, causing there to be an extra unused slot in the object that you can only access by directly using the A.a descriptor. So all slotted inheriting dataclasses cause the object to use more memory than necessary. -- nosy: +Spencer Brown ___ Python tracker <https://bugs.python.org/issue46382> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46467] Rounding 5, 50, 500 behaves differently depending on preceding value
Spencer Brown added the comment: This is intentional behaviour, if the value is 5 it rounds towards even as documented here: https://docs.python.org/3/library/functions.html#round The reason is so that if you have a bunch of random data, rounding won't slightly bias the result upward or downward. -- nosy: +Spencer Brown ___ Python tracker <https://bugs.python.org/issue46467> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45100] Improve help() by making typing.overload() information accessible at runtime
Spencer Brown added the comment: I'm not sure a get_overloads() function potentially called after the fact would fully work - there's the tricky case of nested functions, where the overload list would need to be somehow cleared to ensure every instantiation doesn't endlessly append to the same list. It's probably also desirable to weakref it (or make it an attribute) so they can be decrefed if the function isn't being used. -- nosy: +Spencer Brown ___ Python tracker <https://bugs.python.org/issue45100> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45100] Improve help() by making typing.overload() information accessible at runtime
Spencer Brown added the comment: Had a potential thought. Since the only situation we care about is overload being used on function definitions in lexical order, valid calls are only that on definitions with ascending co_firstlineno counts. Expanding on Jelle's solution, the overload() decorator could compare the current function's line number to the first in the list, and if it's <= clear out the list (we're re-defining). Then repeated re-definitions wouldn't duplicate overloads. The other change I'd suggest is to make get_overloads_for() first check __overloads__, then only if not present pop from the _overloads dict and assign to that attribute. That way if code calls get_overloads_for() at least once, the function will be referring to the actual overloads created at the same time. It'd also get garbage collected then when the function dies. It also means you could manually assign to add overloads to any callable. -- ___ Python tracker <https://bugs.python.org/issue45100> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45579] [list.append(i) for i in list] causes high resources usage
Spencer Brown added the comment: This is intentional behaviour, you actually created an infinite loop. When you iterate over a list, all Python does is track the current index through the list internally, incrementing it each time. But each iteration, you call list.append() to add a new item to the end of the list, so you're continually making it longer and preventing the iteration from ending. Regardless of that, this probably isn't a good use of list comprehensions anyway - append() always returns None, so the result of this comprehension would be a useless list of Nones. It'd be better to just use a regular for loop, or if you're just wanting to copy the list call list.copy() or list(your_list). -- nosy: +Spencer Brown ___ Python tracker <https://bugs.python.org/issue45579> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42369] Reading ZipFile not thread-safe
Change by Spencer Brown : -- nosy: +Spencer Brown ___ Python tracker <https://bugs.python.org/issue42369> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45972] typing.NamedTuple with default arguments without type annotations is falsy
Spencer Brown added the comment: What's happening is that typing.NamedTuple ignores non-annotated attributes entirely when computing the names it passes along to namedtuple(), so here "a" is just a class attribute. You're accessing it from there, but the tuple itself is entirely empty. Perhaps it should error out if no names at all are found? -- nosy: +Spencer Brown ___ Python tracker <https://bugs.python.org/issue45972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44166] Make IndexError messages for list more informative
Spencer Brown added the comment: One potential solution would be to add two Py_ssize_t to IndexError, storing the index and length along with the existing exception value. Then __str__() can append that to the message if set, perhaps having len be negative to signal they're not passed. An issue though is that it might be backwards incompatible with classes trying to multiply inherit from other exceptions too. To deal with that it could put the values in the args tuple, though then it'd have to allocate the tuple and ints which might hurt perf. -- nosy: +Spencer Brown ___ Python tracker <https://bugs.python.org/issue44166> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27989] incomplete signature with help function using typing
Spencer Brown added the comment: More precisely, the issue is with inspect.formatannotation(), which overrides/ignores the repr if the annotation is an instance of type. Perhaps that should be changed to also check that __repr__ is type's repr. -- nosy: +Spencer Brown ___ Python tracker <http://bugs.python.org/issue27989> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27989] incomplete signature with help function using typing
Spencer Brown added the comment: It might be better to just change the if statement to 'if isinstance(annotation, type) and type(annotation).__repr__ is type.__repr__:'. That would make it fallback for any metaclass which overrides repr, instead of special-casing typing. That also ensures 'typing.' is still in the name, since these aren't builtins. -- ___ Python tracker <http://bugs.python.org/issue27989> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27100] Attempting to use class with both __enter__ & __exit__ undefined yields __exit__ attribute error
Spencer Brown added the comment: Alternatively, SETUP_WITH could additionally check for the other method, and raise an AttributeError with a custom message mentioning both methods. -- nosy: +Spencer Brown ___ Python tracker <http://bugs.python.org/issue27100> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
