[Python-Dev] The baby and the bathwater (Re: Scoping, augmented assignment, 'fast locals' - conclusion)

[Josiah Carlson]

Boris Borcic <bborcic at gmail.com> wrote:
> [this is bytes of an oversized put-all-into-it intervention. A possibly expanded 
> version will be submitted on clp with local followup before a couple days]
> 
> Josiah Carlson wrote:
> 
> [BB]
>  >> I'd say a first step in convincing me I am wrong would be to show me 
> examples of
>  >> object methods of the standard library that are recursive, and cut out for
>  >> recursion.
> 
> [JC]
>  > Actually, I don't believe that is necessary. I've shown that you would
>  > get better performance with a non-recursive function and passing two
>  > arguments, than you would passing one argument with scoping tricks to
>  > get the second.
> 
> Assuming my aim was purely performance clearly stretches the hints I gave that I 
> wasn't unconcerned by it. Taking ground on this to unwarrantedly suppose that my 
> methodology was deficient, rectify it, and then dictate the "necessary" 
> conclusions I find... er, preposterous seems balanced, "thought police" not 
> totally unwarranted.

In my initial and later readings of your messages, I read 2 reasons why
you were using a closure rather than some other method to perform this
particular operation:
1. Minimal code change.
2. It was faster than using an object with a particular interface.

If there were other reasons, then I obviously missed them.

However, since no one else has responded substantively to your postings,
other than Terry and Guido's 'not gonna change', I can only presume that
others have found that your desired result (augmented assignments for
names not previously existing in the current scope, but existing in a
parent lexical scope, be performed on the object bound to a parent scope
name), is undesireable for Python 2.5 .  The fact that no one has
suggested that you write a PEP, or start the discussion _after_ 2.5
comes out, is a sign to me that the feature is generally undesireable.
Without proof to the contrary (a group of core Python developers coming
out in support of the feature), I can only go by my own opinion: I don't
believe the utility of this particular feature is worthwhile enough to
change how Python works, considering the possibility for execution
errors.

[snip]

> This said, first : I deny you have or ever had real ground to refuse legitimacy, 
> motivation, efficiency or methodological soundness to my approach.

In a portion of your message that I've cut out, you described how the
goal of your current programming project was to write a sudoku solver in
fewer than 60 lines and that ran in fewer than 10ms for arbitrary
problems. Great, wonderful, I wish you luck; I will not question or
"refuse legitimacy, motivation, efficiency or methodological soundness"
of your approach when using the Python programming language.

However, you are offering a series of reasons as to why the Python
programming language should be changed.  I'm questioning your reasoning.
You may find it insufficient, misinformed, prejudiced, nonsense,
mean-spirited, or even that I'm a loony who should be in your killfile.
My purpose here isn't to convince _you_ that you are wrong about this
feature, as arguing via email has never been my strong suit, but instead
to offer at least one valid reason why your change could or would hurt
some Python users, and/or the effectiveness of their code.

I will mention that the lack of _any_ public support in python-dev
likely says far more about the unliklihood of acceptance than anything
you or I have probably typed in the last few days.


[snip]
> [JC]
>  > when it was an
>  > actual error (a not uncommon case),
> 
> I guess your insistence on the rightful methodology entitles me to enquire in 
> turn on your choice of tool to establish the relative frequency of said case ?

My measurement is quite subjective.  Have I ever made that mistake, or
do I know of anyone who has made that mistake? In this case, I have made
the mistake I mention, both in personal code, as well as code I was
writing as I was tutoring.  I'm not aware of significant problems in
user code, usually because the moment the code is run, the programmer
fixes it.

Here are two questions for you:

1. Do you have any proof showing that the error I claim exists (not
uncommonly was my description), is in fact so rare, that I am
essentially the only one who has made the mistake?

2. Do lexically nested augmented assignments happen so often as to make
this problem a "must solve" for any Python revision?


> [JC]
>  > which is a bit of a no-no,
> 
> What I would have believed a /bit/ of a no-no for Python, is to turn away from 
> the "consenting adults" spirit to go the way of so many other programming languages.
> 
> Picture of the latter way : - As a matter of course, to place the virtue of 
> catching errors early, before the virtue of following programmers' legitimate 
> intentions. - Designing for assumed chronic lusers in need of being protected by 
> the compiler from shooting themselves in the foot.

Do skilled programmers make errors?  Yes.  Do skilled programmers make
errors when they are first using a programming language?  Yes.  It has
always been my experience with Python that it seeks to be reasonable to
use for both newcomers to programming and long-time "skilled"
programmers.

In my statements regarding possible errors related to augmented
assignments, I merely believe that people can and will make mistakes. I
further believe that if I manage to make a particular mistake, that
someone else has, because while I'm not the most brilliant programmer
out there, I'm also certainly not the worst, and I would guess that I
lack the creativity to generate a completely new class of mistakes.

You talk about "Designing for assumed chronic lusers", I'm talking about
designing for human beings, some of whom are new to the language.


 - Josiah