PEP308: Yet another syntax proposal

[Andrew Dalke]

James J. Besemer:
> Aahz:
> > That's still not addressing my point: how often is short-circuit
> > evaluation needed?
>
> This is pure rhetoric.  It's impossible to answer.
>
> Otherwise, tell us what is is the "correct" answer?  10% of the time?  1%?
> 0.1%?  There is no correct answer.

Estimated at over once every 5,000 lines, but likely even lower
rates.  See other posts of mine for why.

> How often are list comprehensions needed?  Booleans needed?

I have not done the analysis.  When the list comprehensions
addition was discussed, there were some ad hoc usability
tests done to evalute the different syntaxes.  There were also
dicussions about how it is used in other languages.  Now that
they exist, I used them, but with strict guidelines (no embedded
list comps, no "for x in .. for y in ..." constructs, no term may
exceed more than one line, so a 3 line max).  They ended
up replacing functions which were hard to name and hard
to understand, like

def get_list_attr(dataset, attr):
    results = []
    for x in dataset:
        results.append(getattr(x, attr))
   return results


For me, booleans were not new syntax they were simply
new built-in objects which worked in the same framework as
the existing code.  There were some changes to how
comparisons are done, but all were done in a backwards
compatiable way.  In addition, I needed booleans for some
projects (eg, to express configuration options) so having a
commong spelling of True/False helped simplify bad code.
The objections to adding bool were deemed minor enough
by our Fearless BDFL.


> Python already wisely recognizes the need for short-circuit within
> expressions.  But and/or is not powerful enough.
>
>  > That's the *only* reason to consider conditional
> > expressions rather than a new builtin conditional function.
>
> Not true, as I and others have explained at length elsewhere.  Readability
> and maintainability are SERVED by factoring out common sub-expressions
from
> the more verbose forms:
>
>      if condition1:
>          if condition2
>                  targetVar1 = result1
>              else:
>                  targetVarl = result2 # hidden BUG!!
>      else:
>          targetVar1 = result3

Such variable naming schemes, of course, are also
deemed unwise.  In addition, it turns out that most code
looks like this

      need_delete = 0
      if condition1:
          if condition2
                  targetVar1 = result1
              else:
                  targetVar1 = result2
                  need_delete = 1
      else:
          targetVar1 = result3

so that if the original code was written with a set of
embedded if/else expressions, then it would need to be
rewritten (and retested) to add this 'need_delete' flag.

                    Andrew
                    dalke at dalkescientific.com