[Python-3000] pre-PEP: Default Argument Expressions

[Josiah Carlson]

"BJörn Lindqvist" <bjourne at GMAIL.COM> wrote:
> On 2/14/07, Josiah Carlson <jcarlson at uci.edu> wrote:
> > Chris Rebert <cvrebert at gmail.com> wrote:
> > > Requesting comments on the following pre-PEP. pybench runs both with and
> > > without the patch applied would also be appreciated.
> > > - Chris R
> >
> > One Glyph Lefkowitz posted today [1] in response to dynamic attribute
> > access the following, which is surely applicable here.
> 
> To be fair, the two ideas are fairly different. Dynamic attribute
> access was about adding new syntax which makes the language more
> complex. This idea is more about fine-tuning existing syntax; it does
> not add to the language, it just makes it different.

There are about a dozen different syntax proposals in the pre-PEP to
determine whether something is executed at compilation or during call. 
Re-read it.

[snip]
> > 1a) Proof as to what is to be gained over an explicit if statement or
> > conditional expression.
> 
> Two less lines of code? It is hard to grep for it, but I bet there are
> a few hundred occurrences the following in the standard library:
> 
>     def something(x = None):
>         if x is None:
>             x = [1, 2, 3]       # <- default

If some 500+ examples of dynamic attribute access in the Python standard
library wasn't sufficient, than the 'few hundred' surely isn't,
especially without actual counts.  Yes, coming up with good counts is
hard, but that's one of the requirements Glyph pointed out.  If no one
is willing to go through and see what it would fix, then it's obviously
not worth it.


> If you remember, it was constructs like this that was one of the big
> motivations behind the terniary operator. So now you write the above like this:
> 
>     def something(x = None):
>         x = [1, 2, 3] if x is None else x

That is certainly an *application* of the terniary operator, but they
can be used *anywhere* a decision is made to choose a value, not merely
in the function signature.

[snip]
> > or
> > 1b) A cost/benefit analysis of the time it would take to "fix" the
> > standard library and/or user code with any of the provided new
> > syntax/semantics.
> 
> I naively think that Python's test suite would discover most of the
> problems. If not, fix the test suite. :) This idea is for py3k, so one
> would guess that the allowed cost is higher.

The cost of syntax changes are allowed to be higher, *but only if their
benefits actually outweigh their costs*.  So far, all you or really
anyone else has shown in the default argument expressions discussion is
that:
1) a few lines
2) on occasion
3) written by new or sloppy Python developers

will be:
1a) less buggy
1b) or not buggy
2) at most 2 lines shorter

Bite the bullet.  Spend the two lines.

 - Josiah