Antoine Pitrou wrote:
> This is especially true if the "X" in "X if C else Y" happens to be a
> non-trivial expression - witness your example from unittest.py:
> return doc.split("\n")[0].strip() if doc else None
>
> ... because then the condition (which is the most important part of the
> statement) is shadowed by the complexity of the first alternative; and
> the two alternatives, which should logically be siblings, are separated
> by something which has a different role in the construct.
I think the perception of what's important is relevant here - to me, the
behaviour in the normal case (i.e., non-empty doc) is the most important
element. The conditional, and the default value returned when 'doc' is empty
are interesting, but are a corner case, rather than a fundamental element of
the function's behaviour.
> This is exactly like a switch/case statement where the "switch" would
> have to be inserted in the middle of two "case"'s.
Well, no - because it is possible to consider an if-else as a parameterised
binary operation that chooses between the left and right operands (i.e., it's
like an "or", only we're asking that the decision be made based on something
other than the truth value of the left hand operand).
That is, in the case where the left hand expression has no side effects, the
following pairs of expression are essentially equivalent:
a or b <-> a if a else b
a and b <-> a if not a else b
In the switch statement example, the switch statement is inherently an n-ary
operation, so there is no comparable way of finding a spot to put the switch
variable "in the middle".
> Also, generally, one of the most annoying things in computer languages
> is when they try to invent their own unnatural conditional forms: such
> as Perl's inverted forms or "unless" statement.
Even more annoying are constructs that don't gel with the rest of the
language, though.
Regards,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.blogspot.com
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
