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~
_______________________________________________
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
