On Mon, Jun 13, 2011 at 1:09 PM, Terry Reedy <tjreedy@udel.edu> wrote:
On 6/13/2011 12:59 PM, geremy condra wrote:
On Sun, Jun 12, 2011 at 2:20 PM, Terry Reedy<tjreedy@udel.edu> wrote:
'Given' or 'where' constructs are sometimes used in mathematical writings, especially formula exposition, but they typically, if not always, are isolated (like the examples in the PEP), and not part of a code sequence. So this is notreally a precedent to me. Example:
fv = p * (1 + i/12)**t... , where fv = present value p = principle i = nominal annual interest rate t = time in months
-(1+whatever)
I've historically been in favor of this kind of proposal specifically because I'd like to be able to write the above code,
Part of my point is that the above is not *code* (and hence not an argument for formatting code that way). It is a text definition. Someone who wrote something like the above might very well then write a *code* version the equivalent of
p = input("principle: ") i = input("nominal annual interest rate: ") t = input("time in months: ") print("Future value of ${} at {}% after {} months is ${}" .format(p, i, t, p*(1+i/12)**t
Meh, semantics. I could, hypothetically, write the following: y = sqrt(z**2 + x**2) given: z = get_adjacent_side_length() x = get_opposite_side_length() and in terms of exposition style it would be basically the same as what you put up earlier, and is (to me) more readable than: z = get_adjacent_side_length() x = get_opposite_side_length() y = sqrt(z**2 + x**2) for the same reasons. The question is whether the (admittedly arguable) gain in readability offered in situations like this is worth the extra complexity of implementation and the risk of seeing code like the examples from the PEP in practice. Also, just to make sure I'm being clear- Nick, I'm not trying to bash your code. I just think that right now this lends itself to some really hard-to-understand constructions. Geremy Condra Geremy Condra