Andreas H. added the comment:
Inside the discussion an ExitPool class is sketched
(https://mail.python.org/archives/list/python-id...@python.org/message/66W55FRCYMYF73TVMDMWDLVIZK4ZDHPD/),
which provides this removal of context managers.
What I learned is that this would have different
Change by Andreas H. :
--
pull_requests: +29443
pull_request: https://github.com/python/cpython/pull/31283
___
Python tracker
<https://bugs.python.org/issue46
Andreas H. added the comment:
Allright. B) sounds good to me. I dont think I have time today, so please feel
to tackle the issue. If not I can look at it the next week.
--
___
Python tracker
<https://bugs.python.org/issue46
New submission from Andreas H. :
TypedDict does not resolve cross-module ForwardRefs when the ForwardRef is not
a direct one.
In other words the fix GH-27017 (issue 41249) for TypedDict seems incomplete.
The same issue seem to exist for NamedTuple.
Example:
#module.py
TD
New submission from Andreas H. :
(De)Serialization of in-memory data structures is an important application.
However there is a rather unpleasant issue with ForwardRefs.
One cannot export type aliases when they contain ForwardRefs (and expect
things to work).
Consider the example
New submission from Andreas H. :
Consider the following:
NewT = typing.NewType("NewT", typing.List[typing.Optional['Z']] )
class Z:
pass
Now get_type_hints() does not resolve the ForwardRef within NewType (but it
does so for TypedDict, dataclasses, NamedTuple).
Andreas H. added the comment:
Ah, let me add one point: PEP563 (-> `from __future__ import annotations`) is
also not helping.
Even with PEP563 enabled, the JSON example
Json = Union[ List['Json'], Dict[str, 'Json'], int, float, bool, None ]
needs to be written in exact the same
Andreas H. added the comment:
Yeah, sure. The use-case is (de)serialization. Right now I use the library
cattr, but there are many others.
If you are interested there is related discussion in the cattr board [1].
The original problem is how to define the types for serialization.
1
Andreas H. added the comment:
I will give it a try.
--
___
Python tracker
<https://bugs.python.org/issue46333>
___
___
Python-bugs-list mailing list
Unsub
New submission from Andreas H. :
The __eq__ method of ForwardRef does not take into account the module
parameter.
However, ForwardRefs with dissimilar module parameters are referring to
different types even if they have different name. Thus also the ForwardRef's
with same name
Andreas H. added the comment:
I see your point. But even with `pop` or `remove` it is still a stack or
stack-like. In the normal case the context managers are still released in
reverse order as they were added. Order cannot be changed arbitrarily.
There is just the additional function
New submission from Andreas H. :
Currently it is not possible to remove context managers from an ExitStack (or
AsyncExitStack).
Workarounds are difficult and generally do accesses implementation details of
(Async)ExitStack.
See e.g. https://stackoverflow.com/a/37607405. It could be done
New submission from Andreas H. :
The issue is that the main task (which was supplied to asyncio.run) has no
chance to clean up its "own" sub-tasks and handle
possible exceptions that occur during the sub-task clean up. It prevents a
graceful shutdown.
There is no way to prevent t
13 matches
Mail list logo
