PEP 308: Pep Update

[Steven Taschuk]

Quoth Andrew Dalke:
> Raymond Hettinger:
> > The leading options on the table are:
> >
> > *     (if <cond>: <expr1> else: >expr2>)
> 
> BTW, I never did see a response to this comment of mine.  With the
> above syntax, this means the following is legal

  [... snip good example ...]

> That is, code which in the small looks like normal Python if/else
> statement is really an if/else expression once you look in the
> larger scope, which may be indefinitely away.  Also note that
> the indentation level does not matter inside of the "a=(...)"
> expression.
> 
> I don't like that.  I would rather use two temporary names.

Stipulated that the confusions you point out are Bad Things.

How would you feel about this?

	# get the 2-ple of name's value and owner
	value = (if is_cached: self._get_cache[name]
		else: self.connection.fetch(name))
	owner = (if x.startswith("DB"): self.connection.get_owner(name)
		else: self.webservice.get_owner_by_name(name))
	a = (value, owner)

(Btw, should that be name.startswith("DB")?)

To me, this rewrite is motivated by general considerations of good
style, and the result is satisfactory.  I make the same kinds of
rewrites with normal expressions, e.g., replacing
	spam = (x, (x - p1[0])*(p1[0] - p2[0])/(p1[1] - p2[1]) + p1[1])
with something like
	dx = p1[0] - p2[0]
	dy = p1[1] - p2[1]
	slope = dx/dy
	intercept = p1[1] - slope*p1[0]
	spam = (x, slope*x + intercept)
Big expressions are hard to follow; naming intermediate values
helps.  (I've also changed the algorithm slightly.)

Your example seems to me to be of the same type.  It is, of
course, made worse by the fact that indentation is surprisingly
irrelevant, as you point out; but to me it's a style issue, not a
shortcoming of the proposed notation.

-- 
Steven Taschuk           | "We can't stop people from complaining, but
staschuk at telusplanet.net |  we can influence what they complain about."
                         |                                -- Tim Peters