Yury Selivanov wrote:
> On Thu, Jun 6, 2019 at 5:20 PM Christoph Groth
> wrote:
> [..]
> > The other possibility I see would be wrapping ContextVar inside a
> > class (like in the example module that I attached to the first post
> > in this thread), but that's n
Yury Selivanov wrote:
> Christoph Groth wrote:
> > Did you consider anything like that? For example, ContextVar could
> > accept an optional keyword arg 'validate' that must be a function
> > that is then called for each new value, and somehow reports problems
>
Yury Selivanov wrote:
> I suggest you to open an issue on bugs.python.org to implement support
> for context manager protocol for contextvars.Token. I'm not opposed
> to the idea. Keep in mind that Python 3.8 is already in a feature
> freeze mode, so the earliest we can get this is Python 3.9.
Yonatan Zunger wrote:
> I had a similar recent need, with a bit more on top of it, and solved it
> with this slightly insane library. (Alas, I haven't figured out a good way
> to make it act as a true subtype of UnderlyingType yet)
>
> (...)
To me, your trick seems to address a different problem.
Abhilash Raj wrote:
> There is rich text support on the way, but there are some quirks
> remaining to be fixed.
Is it documented anywhere? I couldn't find anything, only your issue
https://gitlab.com/mailman/hyperkitty/issues/225.
> You could open a bug report
I'll consider doing that once I
Hi Yury,
thanks for the quick reply.
Yury Selivanov wrote:
> Adding context manager protocol support to contextvars.Token was
> considered when PEP 567 was discussed. There wasn't a strong argument
> against that; however we decided not to immediately add it because
> context variables is a rel
Thanks for moving python-ideas to Mailman 3. To me this is the best of
two worlds.
I noticed a small problem: it seems that identation of code snippets
gets lost in the web view. For example:
def inc(a):
return a + 1
Could something be done about this?
Python-Ideas mailing list -- python-d
It seems that the following idea has not been raised here before. If it
has been, I'd be grateful for a pointer to the relevant discussion.
The idea is: how about adding context manager interface (__enter__ and
__exit__ methods) to the contextvars.Token type?
This would allow code like this:
Nick Coghlan wrote:
> On 25 March 2018 at 22:44, Christoph Groth wrote:
> > I think that it's a helpful guideline to imagine what the ideal
> > behavior should be if we were not constrained by backwards
> > compatibility, and then try to follow it. In the case at hand
Chris Angelico wrote:
> On Sun, Mar 25, 2018 at 8:31 PM, Christoph Groth
> wrote:
> > That's indeed a bit strange, and I would consider it somewhat of a wart
> > of the language. But as far as I can tell remaining compatible with the
> > above behavior does not forc
Nick Coghlan wrote:
> It would also result in two different ways to handle traditional
> assignments:
>
> x = expr
> x := expr
>
> Perhaps ":=" could be explicitly restricted to only single names on
> the LHS, without any of the clever unpacking features of full
> assignment statements?
Nick Coghlan wrote:
> On 24 March 2018 at 23:29, Christoph Groth wrote:
> > x = [n * m for n in range(4) for m in range(5)]
> >
> > be equally well equivalent to
> >
> > def ():
> > ret = []
> > for n in range(4):
> >
Chris Angelico wrote:
> On Sat, Mar 24, 2018 at 8:07 PM, Christoph Groth
> wrote:
> > Chris Angelico wrote:
> >
> >> Thank you; both of these have now been incorporated into the document.
> >
> > Thanks! Just a small comment. You wrote in the PEP draf
Chris Angelico wrote:
> Thank you; both of these have now been incorporated into the document.
Thanks! Just a small comment. You wrote in the PEP draft:
> # Name bindings inside list comprehensions usually won't leak
> ...
> # But occasionally they will!
I don't understand what you mean here.
Disclaimer: I skimmed/searched through the PEP 572 threads (or should I
say "literature"?) and did not find a discussion of the following point.
If it has been discussed already, I'd be glad to be pointed to it.
I am aware that Python, in contrast to C-like languages, has chosen not
to treat assig
15 matches
Mail list logo
