This PEP doesn't cover about what happened when __co_annotation__()
failed (e.g. NameError).
Forward reference is a major reason, but not a only reason for using
string annotation. There are two other reasons:
* Avoid importing heavy module.
* Avoid circular imports.
In these cases, this
On 1/16/21 4:09 PM, Greg Ewing wrote:
On 17/01/21 12:31 pm, Larry Hastings wrote:
Consider the best practice for getting class annotations, example
here from Lib/dataclasses.py:
cls_annotations = cls.__dict__.get('__annotations__', {})
Isn't that going to get broken anyway? It won't
On 17/01/21 12:31 pm, Larry Hastings wrote:
Consider the best
practice for getting class annotations, example here from
Lib/dataclasses.py:
cls_annotations = cls.__dict__.get('__annotations__', {})
Isn't that going to get broken anyway? It won't trigger the
calling of
Given your comments below, I'd summarize the semantics you want as:
Looking up names for annotations should work exactly as it does
today with "stock" semantics, except annotations should also see
names that haven't been declared yet.
Thus an annotation should be able to see names set
On 1/16/21 8:41 AM, Nick Coghlan wrote:
Could you get the best of both worlds by making __annotations__ an
auto-populating descriptor on "type", the way it is on functions?
Continue to add a non-empty annotations dict to the class dict
eagerly, but only add the empty dict when
On Wed, 13 Jan 2021, 12:35 pm Larry Hastings, wrote:
>
> On 1/12/21 5:28 PM, Brett Cannon wrote:
>
> The other thing to keep in mind is we are talking about every module,
> class, and function getting 64 bytes ... which I bet isn't that much.
>
> Actually it's only every module and class.
On Tue, 12 Jan 2021, 11:55 am Ethan Furman, wrote:
> On 1/7/21 4:56 AM, Nick Coghlan wrote:
>
> > Both EnumMeta and ABCMeta should probably be relying on `__set_name__`
> > for their per-member set up work these days, rather than deferring
> > that work until after __new__ returns.
>
> And
