[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: Thanks for your feedback, everybody! It's now checked in. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: New changeset 74613a46fc79cacc88d3eae4105b12691cd4ba20 by larryhastings in branch 'master': bpo-43817: Add inspect.get_annotations(). (#25522) https://github.com/python/cpython/commit/74613a46fc79cacc88d3eae4105b12691cd4ba20 --

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: Ie debated about this with myself (and with a friend!) over the last few days, and I've concluded that evaluating strings by default is too opinionated for the standard library. I've changed both inspect.signature() and inspect.get_annotations() so

[issue43817] Add inspect.get_annotations()

Inada Naoki added the comment: > Just to be clear: I would *not* want this new mode to be the *default* > behavior. So far I think ONLY_IF_STRINGIZED is the best compromise for > default behavior. I don't think ONLY_IF_STRINGIZED is the best compromise. I don't think it solve any issue.

[issue43817] Add inspect.get_annotations()

Guido van Rossum added the comment: No, I want the *default* not to raise when eval() fails. -- ___ Python tracker ___ ___

[issue43817] Add inspect.get_annotations()

Guido van Rossum added the comment: I want to be as short as possible. The user may have annotations because they are using mypy. They may be using a library that calls inspect.signature() on some of their functions to retrieve the parameter names conveniently. All this has worked for years,

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: One final thought on that idea. Part of the reason why I didn't go back to the drawing board and re-think the API was because I thought folks were pushing back on the idea of *default* behavior possibly raising exceptions. If I misread it, and the pushback

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: Just to be clear: I would *not* want this new mode to be the *default* behavior. So far I think ONLY_IF_STRINGIZED is the best compromise for default behavior. -- ___ Python tracker

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: I like Eric's suggestion best of all. I'd be willing to add a "silence errors on a case-by-case basis" flag to inspect.signature(). I imagine that would add a new field to the Parameter object (as Guido suggested) indicating which objects failed. Would

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: > There may be a (deliberate? :-) misunderstanding. When I wrote about > "you" inspecting code by a "3rd party" I meant that as a symmetric > relationship -- the "you" could be a library and from the library's > POV the "3rd party" could be you (or me). I

[issue43817] Add inspect.get_annotations()

Eric V. Smith added the comment: I'd like to see the default behavior be to raise an exception if eval fails on any annotation. I think it's reasonable to provide a way to find out which specific keys have problems, but I don't think that should be the default. Wouldn't it be good enough

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: > I use inspect.signature for getting information about callables > (third-party and first-party) in my type checker: > https://github.com/quora/pyanalyze/blob/master/pyanalyze/arg_spec.py#L436. > In that context, I'd much rather get string annotations that

[issue43817] Add inspect.get_annotations()

Guido van Rossum added the comment: There may be a (deliberate? :-) misunderstanding. When I wrote about "you" inspecting code by a "3rd party" I meant that as a symmetric relationship -- the "you" could be a library and from the library's POV the "3rd party" could be you (or me). Either

[issue43817] Add inspect.get_annotations()

Jelle Zijlstra added the comment: I agree with Guido that it's better to design inspect.signature to not throw an error for annotations that don't eval() cleanly. I use inspect.signature for getting information about callables (third-party and first-party) in my type checker:

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: > I'm not a big user of the inspect module, but I always thought that > its use was so that you could look at a function (or other object) > *produced by a 3rd party* and learn something about it. That's interesting! I always thought its main use was the

[issue43817] Add inspect.get_annotations()

Guido van Rossum added the comment: I'm not a big user of the inspect module, but I always thought that its use was so that you could look at a function (or other object) *produced by a 3rd party* and learn something about it. Asking for the signature is one such operation, and I'd be

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: I keep thinking about it, and I think letting inspect.get_annotations() and inspect.signature() raise exceptions is the right API choice. I note that that's what typing.get_type_hints() did in Python 3.9. During the development of Python 3.10, this was

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: Perhaps eval_str=ONLY_IF_STRINGIZED should also add the semantics "if evaluating any string fails, behave as if eval_str=false". I would *not* propose adding that for eval_str=true. But people keep asking for this. Hmm. The heuristic is a tricky thing.

[issue43817] Add inspect.get_annotations()

Inada Naoki added the comment: > > The difference between eval_str=True and eval_str=ONLY_IF_STRINGIZED: > > def foo(a:int, b:"howdy howdy"): ... > > inspect.get_annotations(foo, eval_str=True) throws an exception. > inspect.get_annotations(foo, eval_str=ONLY_IF_STRINGIZED) returns {'a': int,

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: The difference between eval_str=True and eval_str=ONLY_IF_STRINGIZED: def foo(a:int, b:"howdy howdy"): ... inspect.get_annotations(foo, eval_str=True) throws an exception. inspect.get_annotations(foo, eval_str=ONLY_IF_STRINGIZED) returns {'a': int, b:

[issue43817] Add inspect.get_annotations()

Inada Naoki added the comment: > I think Pydantic would prefer it, because Pydantic wants to see the real > objects at runtime, rather than the stringized annotations. If so, why don't they use `eval_str=True`? I can not find any use cases where `eval_str= ONLY_IF_ALL_STR` is better than

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: For what it's worth: I changed the name to ONLY_IF_STRINGIZED in the PR. Since I propose that it be the default, everyone who called inspect.get_annotations(), and inspect.signature(), would use it. I think Pydantic would prefer it, because Pydantic wants

[issue43817] Add inspect.get_annotations()

Inada Naoki added the comment: I'm not sure `ONLY_IF_ALL_STR` is worth enough. Will anyone use it after Python 3.10? inspect.signature()? Pydantic? -- ___ Python tracker ___

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: Time runs short for Python 3.10b1. Can I get a review from anybody here, say over the weekend? -- ___ Python tracker ___

[issue43817] Add inspect.get_annotations()

Eric V. Smith added the comment: > p.s. assuming you meant PEP 563, not PEP 573. Yes. Someday I'll figure out this keyboard. -- ___ Python tracker ___

[issue43817] Add inspect.get_annotations()

Change by Larry Hastings : -- assignee: -> larry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: PR is up, passes all checks. I think it's ready for the first round of reviews! -- ___ Python tracker ___

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: I think it gets a little murkier when we talk about *annotations* vs *type hints*. Type hints have a defined meaning for a string: a string is a sort of forward declaration, and you eval() the string to get the real value. (Or, not, if you're comfortable

[issue43817] Add inspect.get_annotations()

Eric V. Smith added the comment: > To be honest, I've never been really sure if the idea of PEP 563 stringized > annotations are supposed to be a hidden implementation detail, or a > first-class concept that the user (and the standard library) is expected to > deal with. This is an

[issue43817] Add inspect.get_annotations()

Change by Larry Hastings : -- keywords: +patch pull_requests: +24242 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/25522 ___ Python tracker

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: When I proposed this new function, stringized annotations were the default behavior in Python 3.10, and there were two calls to typing.get_type_hints() in the standard library: * inspect.signature() * functools.singledispatch() Now that stringized

[issue43817] Add inspect.get_annotations()

Eric V. Smith added the comment: > And since there are definitely circumstances in which it can't return > __annotations__ directly, that indicates that it should never return > __annotations__ directly. And the follow on here is that get_annotations() shouldn't set __annotations__ if it's

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: Just to round the bases: get_annotations() won't return an unmodified __annotations__ dict, but it *could* return a *consistent* dict. It could keep a cache (lru or otherwise) of all responses so far. I don't think that's what we want, I just thought I

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: > Are you saying the user would expect to be able to change __annotations__ my > modifying the dict they get back? As the docs are currently written, it's ambiguous. > Is it ever the case that the user can modify __annotations__ through the dict > that's

[issue43817] Add inspect.get_annotations()

Eric V. Smith added the comment: > If o.__annotations__ is None, should this function set the empty dict on the > object? That seems slightly too opinionated to me. On the other hand, the > user would probably expect that they could change the dict they got back. Are you saying the user

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: Hmm. If o.__annotations__ is None, should this function set the empty dict on the object? That seems slightly too opinionated to me. On the other hand, the user would probably expect that they could change the dict they got back. (If Python shipped with

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: Just over twelve hours ago, the Python Steering Committee announced that stringized annotations would no longer be default behavior in Python 3.10. They will go back to being gated with "from __future__ import annotations". I think we still need this

[issue43817] Add inspect.get_annotations()

Change by Larry Hastings : -- title: Add typing.get_annotations() -> Add inspect.get_annotations() ___ Python tracker ___ ___