[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).


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