unintuitive for-loop behavior

Steve D'Aprano steve+python at pearwood.info
Fri Sep 30 14:29:34 EDT 2016


On Fri, 30 Sep 2016 03:06 pm, Rustom Mody wrote:

> On Friday, September 30, 2016 at 10:23:31 AM UTC+5:30, Gregory Ewing
> wrote:
>> namenobodywants wrote:
>>  > can anyone help to reconcile me to this semantics?
>> 
>> Not really. Most people agree that it's not desirable
>> behaviour, but we've ended up here due to a convoluted
>> history, and there doesn't seem to be a good way to
>> fix it without breaking a lot of existing code.
> 
> Thanks for an unusually helpful answer.
> 
> In my experience telling a beginner:
> «This» is a misfeature/gotcha
> And «this» is its workaround
> 
> greatly shortens the learning curve as compared to long-winded
> justificatory explanations

What happens if it is *not* a misfeature? Gotchas are not always
misfeatures -- sometimes gotchas are gotchas because people's expectations
are simply wrong, and pandering to their confused expectations does not
actually help them.

I haven't made up my mind about *this* specific (mis)feature itself. I know
I don't want for-loops to introduce their own scope, but that doesn't mean
that the binding behaviour inside for-loops is necessarily the best way of
doing it. I'm still thinking about it.

But *in general*, people often don't think the logical consequences through
before deciding what behaviour is "obviously" right. They insist that
whatever behaviour would be convenient for them *now* is the one and only
correct way of doing things -- even if, an hour later, the *opposite*
behaviour is convenient and therefore the correct way of doing things.

Obviously late binding is the one and only correct way of setting function
parameter defaults -- until we need early binding, then it is the one and
only correct way of doing it.

Gotchas usually exist for a reason. Very few programming languages design
gotchas into them to deliberately trip people up[1], or even through
carelessness. More often, they're the unexpected consequences of a series
of sensible, or even unavoidable, decisions.






[1] "When I design my killer language, the identifiers `foo` and `bar` will
be reserved words, never used, and not even mentioned in the reference
manual. Any program using one will simply dump core without comment.
Multitudes will rejoice."  -  Tim Peters


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.




More information about the Python-list mailing list