RetroSearch Browse

Thu Jan 11 01:39:05 EST 2018 · https://mail.python.org/pipermail/python-dev/2018-January/151711.html

On 01/10/2018 10:23 PM, Yury Selivanov wrote:
> On Thu, Jan 11, 2018 at 4:44 AM, Nathaniel Smith wrote:

>> It may have gotten lost in that email, but my actual favorite approach
>> is that we make the signatures:
>>
>> ContextVar(name, *, initial_value)  # or even (*, name, initial_value)
>> ContextVar.get()
>> ContextVar.set(value)
>>
>> so that when you create a ContextVar you always state the initial
>> value, whatever makes sense in a particular case. (Obviously None will
>> be a very popular choice, but this way it won't be implicit, and
>> no-one will be surprised to see it returned from get().)
>
> Alright, you've shown that most of the time when we use
> threading.local in the standard library we subclass it in order to
> provide a default value (and avoid AttributeError being thrown).  This
> is a solid argument in favour of keeping the 'default' parameter for
> the ContextVar constructor.  Let's keep it.

[...]

> I think that when you have an int stored in a context variable it
> would usually make sense to give it a 0 default (or some other
> number). However, for a complex object (like current request object)
> there is *no* sensible default value sometimes.  Forcing the user to
> set it to None feels like a badly designed API that forces the user to
> work around it.
>
> Therefore I'm still in favour of keeping the current PEP 567
> behaviour.

To be clear:  We'll now be able to specify a default when we create the variable, but we can also leave it out so a 
LookupError can be raised later?

--
~Ethan~

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2018-January/151711.html below:

[Python-Dev] PEP 567 pre v3