[Python-ideas] PEP draft: context variables
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.
More information about the Python-ideas