Carl M. johnson wrote:>2.) What happens in this case:
>
>x = y given:
> return "???"
>
>Do we just disallow return inside a given? If so, how would the parser
>know to allow you to do a def inside a given?
i think so because unless i am misunderstanding something the only allowed expressions
in a 'given' block would be of the type:
a_variable = an_expression
however one way to think of it is that
ans = do_something(a, b, c) given:
a = get_a()
b = get_b()
c = get_c()
is the same as saying
a = get_a()
b = get_b()
c = get_c()
ans = do_something(a, b, c)
del a, b, c
which would seem to indicate that
a = do_something() given:
return "???"
goes to:
return "???"
a = do_something()
would be valid (if extremely bad style)
in the end i think its use in that way would be like the use of a GOTO statement in many languages, technically there is no reason it should not be allowed
but still prohibited for stylistic reasons.
anyway why would you ever want to do this? it would be like writing
def f():
return return
it is non-nonsensical and obviously an error
On Tue, Jul 20, 2010 at 8:09 PM, Carl M. Johnson
<cmjohnson.mailinglist@gmail.com> wrote:
Questions:
1.) It looks like a lot of the complexity of PEP 3150 is based on
wanting thing like this to work:
x[index] = 42 given:
index = complicated_formula
To make that work, you need to figure out if index is a nonlocal or a
global or what in order to emit the right bytecode. What happens if we
just give up that use case and say that anything on the assignment
side of the initial = gets looked up in the original namespace? In
other words, make 3150 more similar to the sugar:
def _():
index = complicated_formula
x[index] = _() #Probably a NameError
Would the complexity of PEP 3150 be significantly lessened by that? Or
are there other major sources of complexity in the
local/nonlocal/global issue?
2.) What happens in this case:
x = y given:
return "???"
Do we just disallow return inside a given? If so, how would the parser
know to allow you to do a def inside a given?
-- Carl Johnson