"BJörn Lindqvist" <[EMAIL PROTECTED]> wrote: > On 2/14/07, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > Chris Rebert <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
