Re: [Python-Dev] PEP 550 v4
On Sat, Aug 26, 2017 at 04:13:24PM -0700, Nathaniel Smith wrote: > On Sat, Aug 26, 2017 at 7:58 AM, Elvis Pranskevichus > wrote: > > What we are talking about here is variable scope leaking up the call > > stack. I think this is a bad pattern. For decimal context-like uses > > of the EC you should always use a context manager. For uses like Web > > request locals, you always have a top function that sets the context > > vars. > > It's perfectly reasonable to have a script where you call > decimal.setcontext or np.seterr somewhere at the top to set the > defaults for the rest of the script. +100. The only thing that makes sense for decimal is to change localcontext() to be automatically async-safe while preserving the rest of the semantics. Stefan Krah ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 550 v4: Decimal examples and performance
On Sat, Aug 26, 2017 at 12:21:44PM -0400, Yury Selivanov wrote: > On Sat, Aug 26, 2017 at 7:45 AM, Stefan Krah wrote: > >> This generic caching approach is similar to what the current C > >> implementation of ``decimal`` does to cache the the current decimal > >> context, and has similar performance characteristics. > > > > I think it'll work, but can we agree on hard numbers like max 2% slowdown > > for the non-threaded case and 4% for applications that only use threads? > > I'd be *very* surprised if wee see any noticeable slowdown at all. The > way ContextVars will implement caching is very similar to the trick > you use now. I'd also be surprised, but what do we do if the PEP is accepted and for some yet unknown reason the implementation turns out to be 12-15% slower? The slowdown related to the module-state/heap-type PEPs wasn't immediately obvious either; it would be nice to have actual figures before the PEP is accepted. Stefan Krah ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 550 v4
On Sun, Aug 27, 2017 at 6:08 AM, Stefan Krah wrote: > On Sat, Aug 26, 2017 at 04:13:24PM -0700, Nathaniel Smith wrote: >> On Sat, Aug 26, 2017 at 7:58 AM, Elvis Pranskevichus >> wrote: >> > What we are talking about here is variable scope leaking up the call >> > stack. I think this is a bad pattern. For decimal context-like uses >> > of the EC you should always use a context manager. For uses like Web >> > request locals, you always have a top function that sets the context >> > vars. >> >> It's perfectly reasonable to have a script where you call >> decimal.setcontext or np.seterr somewhere at the top to set the >> defaults for the rest of the script. > > +100. The only thing that makes sense for decimal is to change localcontext() > to be automatically async-safe while preserving the rest of the semantics. TBH Nathaniel's argument isn't entirely correct. With the semantics defined in PEP 550 v4, you still can set decimal context on top of your file, in your async functions etc. This will work: decimal.setcontext(ctx) def foo(): # use decimal with context=ctx and this: def foo(): decimal.setcontext(ctx) # use decimal with context=ctx and this: def bar(): # use decimal with context=ctx def foo(): decimal.setcontext(ctx) bar() and this: def bar(): decimal.setcontext(ctx) def foo(): bar() # use decimal with context=ctx and this: decimal.setcontext(ctx) async def foo(): # use decimal with context=ctx and this: async def bar(): # use decimal with context=ctx async def foo(): decimal.setcontext(ctx) await bar() The only thing that will not work, is this (ex1): async def bar(): decimal.setcontext(ctx) async def foo(): await bar() # use decimal with context=ctx The reason why this one example worked in PEP 550 v3 and doesn't work in v4 is that we want to avoid random code breakage if you wrap your coroutine in a task, like here (ex2): async def bar(): decimal.setcontext(ctx) async def foo(): await wait_for(bar(), 1) # use decimal with context=ctx We want (ex1) and (ex2) to work the same way always. That's the only difference in semantics between v3 and v4, and it's the only sane one, because implicit task creation is an extremely subtle detail that most users aren't aware of. We can't have a semantics that let you easily break your code by adding a timeout in one await. Speaking of (ex1), there's an example that didn't work in any PEP 550 version: def bar(): decimal.setcontext(ctx) yield async def foo(): list(bar()) # use decimal with context=ctx In the above code, bar() generator sets some decimal context, and it will not leak outside of it. This semantics is one of PEP 550 goals. The last change just unifies this semantics for coroutines, generators, and asynchronous generators, which is a good thing. Yury ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Pep 550 module
I think there is general consensus that this should go in a module other
than sys. (At least a submodule.)
The specific names are still To Be Determined, but I suspect seeing the
functions and objects as part of a named module will affect what works.
So I am requesting that the next iteration just pick a module name, and let
us see how that looks. E.g
import dynscopevars
user=dynscopevars.Var ("username")
myscope=dynscopevars.get_current_scope()
childscope=dynscopevars.Scope (parent=myscope,user="bob")
-jJ
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Pep 550 and None/masking
Does setting an ImplicitScopeVar to None set the value to None, or just remove it? If it removes it, does that effectively unmask a previously masked value? If it really sets to None, then is there a way to explicitly unmask previously masked values? Perhaps the initial constructor should require an initial value (defaulting to None) and the docs should give examples both for using a sensible default value and for using a special "unset" marker. -jJ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pep 550 and None/masking
Hi Jim, it seems like each time you reply you change the subject line and start a new thread. Very few others are doing this (e.g. Yury when releasing a new version). Would it be possible for you to preserve the threading like others? --Chris On Sun, Aug 27, 2017 at 9:08 AM Jim J. Jewett wrote: > Does setting an ImplicitScopeVar to None set the value to None, or just > remove it? > > If it removes it, does that effectively unmask a previously masked value? > > If it really sets to None, then is there a way to explicitly unmask > previously masked values? > > Perhaps the initial constructor should require an initial value > (defaulting to None) and the docs should give examples both for using a > sensible default value and for using a special "unset" marker. > > -jJ > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/chris.jerdonek%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pep 550 and None/masking
On 08/27/2017 11:02 AM, Chris Jerdonek wrote: Hi Jim, it seems like each time you reply you change the subject line and start a new thread. Very few others are doing this (e.g. Yury when releasing a new version). Would it be possible for you to preserve the threading like others? I must admit I'm torn here: on the one hand, having all the discussion in a single thread keeps the conversation in one place; on the other hand, having separate threads for very specific questions makes it easier to focus on the parts one is interested in without being overwhelmed by the volume. So while I'm okay either way, I do appreciate Jim trying to have focused threads. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pep 550 and None/masking
I believe that the current status is: - assigning None isn't treated specially – it does mask any underlying values (which I think is what we want) - there is currently no way to "unmask" - but it's generally agreed that there should be a way to do that, at least in some cases, to handle the save/restore issue I raised. It's just that Yury & Elvis wanted to deal with restructuring the PEP first before doing more work on the api details. -n On Aug 27, 2017 9:08 AM, "Jim J. Jewett" wrote: > Does setting an ImplicitScopeVar to None set the value to None, or just > remove it? > > If it removes it, does that effectively unmask a previously masked value? > > If it really sets to None, then is there a way to explicitly unmask > previously masked values? > > Perhaps the initial constructor should require an initial value > (defaulting to None) and the docs should give examples both for using a > sensible default value and for using a special "unset" marker. > > -jJ > > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > njs%40pobox.com > > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 442 undocumented C API functions
Hi, thanks to your report. > As far as I understand, if you have a custom tp_dealloc, you *have* to > call PyObject_CallFinalizerFromDealloc in order to get your tp_finalize > called. Is this correct? Sorry, I'm not expert of Object finalization process. But If my understanding is correct, you're almost right. When a type has custom *tp_finalize*, it have to call `PyObject_CallFinalizerFromDealloc`. And to allow subclass, it should be like this: https://github.com/python/cpython/blob/ed94a8b2851914bcda3a77b28b25517b8baa91e6/Modules/_asynciomodule.c#L1836-L1849 > However, since the necessary functions are undocumented, it's unclear > if they were intended to be public Python API functions. So are they > actually public functions that 3rd party extensions can call? > If not, how is tp_finalize supposed to be used? While I don't want tp_finalize is used widely (like `__del__`), I agree with you. But I'm not good English writer. Contribution is welcome. Regards, INADA Naoki ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
