Nick Coghlan wrote:
as equivalent to:
def __use_stmt():
use-suite
def _in_clause():
in-suite
return names
return _in_clause()
__use_stmt_args = {}
names = __use_stmt()
del __use_stmt
The more I think about this return-based approach, the less I like it. It could
probably be made to
Nick Coghlan wrote:
Semantics
-
The code::
statement with:
suite
translates to::
def unique_name():
suite
statement
unique_name()
I've come to the conclusion that these semantics aren't what I would expect from
the construct. Exactly what I would expect can't really be
Nick Coghlan wrote:
def f():
a = 1
b = 2
print 1, locals()
print 3, locals() using:
a = 2
c = 3
print 2, locals()
print 4, locals()
I think the least suprising result would be:
1 {'a': 1, 'b': 2} # Outer scope
2 {'a': 2, 'c': 3} # Inner
On Fri, 14 Jan 2005 01:48:48 +1000, Nick Coghlan [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
Semantics
-
The code::
statement with:
suite
translates to::
def unique_name():
suite
statement
unique_name()
I've come to the conclusion that these semantics aren't
Bengt Richter wrote:
Problems? (Besides NIH, which I struggle with regularly, and had to overcome to
accept Tim's
starting point in this ;-)
The ideas regarding creating blocks whose name bindings affect a different scope
are certainly interesting (and relevant to the 'using' out-of-order
Nick Coghlan wrote:
Semantics
-
The code::
statement with:
suite
translates to::
def unique_name():
suite
statement
unique_name()
Bleh. Not only was my proposed grammar change wrong, my suggested semantics are
wrong, too.
Raise your hand if you can see the problem with
Nick Coghlan wrote:
Semantics
-
The code::
statement with:
suite
translates to::
def unique_name():
suite
statement
unique_name()
Bleh. Not only was my proposed grammar change wrong, my suggested
semantics are wrong, too.
Raise your hand if you can see the problem with
Nick Coghlan wrote:
Nick Coghlan wrote:
Semantics
-
The code::
statement with:
suite
translates to::
def unique_name():
suite
statement
unique_name()
Bleh. Not only was my proposed grammar change wrong, my suggested
semantics are wrong, too.
Raise your hand if you can see the
Andrey Tatarinov wrote:
afair you told yourself that
var = statement where:
suite
translates to:
def unique_name():
suite
return statement
var = unique_name()
in this case class gets unique_name() function? is it that bad?
No, I wasn't thinking clearly and saw problems that weren't
Andrey Tatarinov wrote:
I think using 'with' keyword can cause some ambiguity. for example I
would surely try to write
x = a+b with self:
b = member
and using with at the end of block brings more ambiguity:
stmt1()
stmt2()
with self:
member = stmt3()
compare to:
stmt1()
So of the four keywords suggested so far ('where', 'with', 'in',
'using'), I'd currently vote for 'using' with 'where' a fairly close
second. My vote goes to 'using' because it has a fairly clear meaning
('execute the statement using this extra information'), and doesn't have
the conflicting
Duncan Booth wrote:
Nick Coghlan wrote:
Grammar Change
--
Current::
statement ::=stmt_list NEWLINE | compound_stmt
New::
statement ::=(stmt_list NEWLINE | compound_stmt) [local_namespace]
local_namespace ::= with : suite
Semantics
-
The code::
statement with:
Nick Coghlan wrote:
Disallowing local namespaces for statement lists would suggest something
like this:
statement ::= (simple_stmt
(NEWLINE | ; stmt_list NEWLINE | local_namespace)
) |
(compound_stmt [local_namespace])
local_namespace ::=
+1
I really like the idea of this. It removes all my objections to
lambdas, and replaces it with something clear and readable.
I look forward to seeing what comes of it.
Anna
--
http://mail.python.org/mailman/listinfo/python-list
Andrey Tatarinov wrote:
So it seems that people loved the idea of 'where' keyword, may be it's
time to think about PEP draft? I appreciate any help (cause my english
is not that good =)).
There's certainly a PEP in the idea. Here's a summary of what we have so far in
this thread in a PEPish
15 matches
Mail list logo
