[Python-Dev] PEP 550 v4
Nick Coghlan
ncoghlan at gmail.com
Tue Aug 29 05:01:03 EDT 2017
On 27 August 2017 at 03:23, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
> On Sat, Aug 26, 2017 at 1:23 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
>> On 08/26/2017 09:25 AM, Yury Selivanov wrote:
>>> ContextVar.lookup() method *traverses the stack* until it finds the LC
>>> that has a value. "get()" does not reflect this subtle semantics
>>> difference.
>>
>> A good point; however, ChainMap, which behaves similarly as far as lookup
>> goes, uses "get" and does not have a "lookup" method. I think we lose more
>> than we gain by changing that method name.
>
> ChainMap is constrained to be a Mapping-like object, but I get your
> point. Let's see what others say about the "lookup()". It is kind of
> an experiment to try a name and see if it fits.
I don't think "we may want to add extra parameters" is a good reason
to omit a conventional `get()` method - I think it's a reason to offer
a separate API to handle use cases where the question of *where* the
var is set matters (for example, `my_var.is_set()` would indicate
whether or not `my_var.set()` has been called in the current logical
context without requiring a parameter check for normal lookups that
don't care).
Cheers,
Nick.
P.S. And I say that as a reader who correctly guessed why you had
changed the method name in the current iteration of the proposal. I'm
sympathetic to those reasons, but I think sticking with the
conventional API will make this one easier to learn and use :)
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev
mailing list