[Python-ideas] 'where' statement in Python?

[Nathan Schneider]

> if some_bool_func(a):
>     ans = some_func1(a, b, c)
> else:
>     ans = some_func2(a, b, c)
> given: # note: given applied to the block starting with the "if" statement
>     a = get_a()
>     b = get_b()
>     c = get_c()

It seems to me that the postfix construct would confuse the reader in
a scenario such as the above, rather than reducing complexity. (Worse,
suppose 'a', 'b', and 'c' had been assigned prior to the 'if'
statement!) Moreover, our intuitions seem to be fuzzy when it comes to
the desirability/behavior of control flow statements in the 'given'
block. So I'm -1 on this: I think there is a marked increase in the
opportunity for confusion among authors and readers, without a clear
set of common patterns that would be improved (even if readability is
slightly better on occasion).

I think a better alternative to allow for safe localization of
variables to a block would be to adapt the 'with' statement to behave
as a 'let' (similar to suggestions earlier in the thread). For
instance:

with fname = sys.argv[1], open(fname) as f, contents = f.read():
    do_stuff1(fname, contents)
    do_stuff2(contents)
do_stuff3(fname)  # error: out of scope

This makes it clear to the reader that the assignments to 'fname' and
'contents', like 'f', only pertain to the contents of the 'with'
block. It allows the reader to focus their eye on the 'important'
part—the part inside the block—even though it doesn't come first. It
helps avoid bugs that might arise if 'fname' were used later on. And
it leaves no question as to where control flow statements are
permitted/desirable.

I'm +0.5 on this alternative: my hesitation is because we'd need to
explain to newcomers why 'f = open(fname)' would be legal but bad,
owing to the subtleties of context managers. (I worry Alex's proposal
for the interpreter to create context managers on the fly would only
add confusion.)

Nathan

On Wed, Jul 21, 2010 at 1:19 PM, Alex Light <scialexlight at gmail.com> wrote:
>
>
> On Wed, Jul 21, 2010 at 12:02 PM, Jack Diederich <jackdied at gmail.com> wrote:
>>
>> <snip>
>>
>> 2a) No control flow statements in the block means if you need to
>> augment the code to do a return/break/continue/yield you then have to
>> refactor so everything in the "given:" block gets moved to the top and
>> a 1-line change becomes a 10 line diff.
>> 2b) Allowing control flow statements in the block would be even more
>> confusing.
>> 2c) Is this legal?
>>     x = b given:
>>       b = 0
>>       for item in range(100):
>>         b += item
>>         if b > 10:
>>           break
>
> 2a) you are missing the point of the given clause. you use it to assign
> values to variables if, and only if, the only possible results of the
> computation are
> 1) an exception is raised or
> 2) a value is returned which is set to the variable and used in the
> expression no matter its value.
> if there is the slightest chance that what you describe might
> be necessary you would not put it in a "given" but do something like this:
> (assumes that a given is applied to the previous statement in its current
> block)
> if some_bool_func(a):
>     ans = some_func1(a, b, c)
> else:
>     ans = some_func2(a, b, c)
> given: # note: given applied to the block starting with the "if" statement
>     a = get_a()
>     b = get_b()
>     c = get_c()
> 2b) agreed but there is no reason for them to be disallowed except
> readibility but they should be discouraged
> 2c) see it might be okay, depending on what people think of your second
> question. in my opinion it should be illegal stylistically and
> be required to be changed to
> def summation(start, end)
>     i = start
>     while i < end:
>         start += i
>         i  += 1
>     return start
> def a_func():
>     # do stuff
>     x = b given:
>         b = summation(0, 100)
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>