[Python-ideas] PEP draft: context variables

Steve Dower steve.dower at python.org
Wed Oct 11 14:54:00 EDT 2017


On 11Oct2017 0458, Koos Zevenhoven wrote:
> ​Exactly. You did say it less politely than I did, but this is exactly 
> how I thought about it. And I'm not sure people got it the first time.

Yes, perhaps a little harsh. However, if I released a refactoring tool 
that moved function calls that far, people would file bugs against it 
for breaking their code (and in my experience of people filing bugs 
against tools that break their code, they can also be a little harsh).

> I want PEP 555 to be how things *should be*, not how things are.
Agreed. Start with the ideal target and backpedal when a sufficient case 
has been made to justify it. That's how Yury's PEP has travelled, but I 
disagree that this example is a compelling case for the amount of 
bending that is being done.

>> New users of this functionality very likely won’t assume that TLS is
>> the semantic equivalent, especially when all the examples and naming
>> make it sound like context managers are more related. (I predict
>> people will expect this to behave more like unstated/implicit
>> function arguments and be captured at the same time as other
>> arguments are, but can’t really back that up except with gut-feel.
>> It's certainly a feature that I want for myself more than I want
>> another spelling for TLS…)
> 
> I assume you like my decision to rename the concept to "context 
> arguments" :). And indeed, new use cases would be more interesting than 
> existing ones. Surely we don't want new use cases to copy the semantics 
> from the old ones which currently have issues (because they were 
> originally designed to work with traditional function and method calls, 
> and using then-available techniques).

I don't really care about names, as long as it's easy to use them to 
research the underlying concept or intended functionality. And I'm not 
particularly supportive of this concept as a whole anyway - EIBTI and all.

But since it does address a fairly significant shortcoming in existing 
code, we're going to end up with something. If it's a new runtime 
feature then I'd like it to be an easy concept to grasp with clever 
hacks for the compatibility cases (and I do believe there are clever 
hacks available for getting "inject into my deferred function call" 
semantics), rather than the whole thing being a complicated edge-case.

Cheers,
Steve


More information about the Python-ideas mailing list