# PEP 749: Implementing PEP 649 **URL:** \ **Category:** PEPs\ **Created:** [June 5, 2024, 1:07am UTC](https://discuss.python.org/t/pep-749-implementing-pep-649/54974 "2024-06-05T01:07:14Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![ncoghlan](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ncoghlan/32/14266_2.png) [@ncoghlan](https://discuss.python.org/u/ncoghlan)\ **Post date:** [June 5, 2024, 5:49am UTC](https://discuss.python.org/t/pep-749-implementing-pep-649/54974/4 "2024-06-05T05:49:33Z")
Even if the SC haven’t been formally asked for approval yet, I assume they’ll still keep an eye on how things are going, and chime in if they have specific concerns. It’s also an area where “seems like a good idea in principle” may fail in practice once stdlib modules like `dataclasses` actually attempt to adapt to the changes, so I think it makes sense to ask the SC for ratification of details that have already been demonstrated to work rather than asking for approval for everything that is being tried along the way. On PEP 749 itself, I don’t think the current notes for wrapper functions are quite right, as they won’t do the right thing when ` __annotations__ ` has already been populated on the wrapped function. I previously posted some thoughts on how to handle that to [`functools.update_wrapper` will require changes for PEP 649 compatibility · Issue #21 · larryhastings/co\_annotations · GitHub](https://github.com/larryhastings/co_annotations/issues/21) and I still believe that adding a suitable ` __annotate__ ` implementation to the wrapper object is the better approach. The introduction of the `annotations` module also avoids the circular dependency I mentioned in that issue (`inspect` depends on `functools`, so `functools` depending on an `inspect.get_annotations` API would pose a problem beyond the mere fact of `inspect` being an expensive dependency) The other thing I noticed was that the “stringizer” used to make the `SOURCE` format reconstruction possible was being kept private. While splitting that functionality out from `ForwardRef` itself definitely makes sense, it seems like it might be a useful API to expose in its own right (potentially using a name like `EvalToSourceRef` or similar). I guess keeping it private initially doesn’t rule out making it public later, though. --- _[View the full topic](https://discuss.python.org/t/pep-749-implementing-pep-649/54974)._