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
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
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
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
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
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
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 enti
Change by Spencer Brown :
--
nosy: +Spencer Brown
___
Python tracker
<https://bugs.python.org/issue42369>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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 <rep...@bugs.python.
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
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
12 matches
Mail list logo
