Nick Coghlan wrote:
# Anonymous functions
use res:
def f(x):
d = {}
exec x in d
return d
in:
res = [f(i) for i in executable]
as for me, I found construction "use :" unobvious and confusing.
Also there is great possibility to forget some of variables names.
I think that syntax
wher
Nick Coghlan wrote:
as equivalent to:
def __use_stmt():
def _in_clause():
return
return _in_clause()
__use_stmt_args = {}
= __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 work, but it just feels like
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 executi
On Fri, 14 Jan 2005 01:48:48 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>Nick Coghlan wrote:
>> Semantics
>> -
>> The code::
>>
>> with:
>>
>>
>> translates to::
>>
>> def unique_name():
>>
>>
>> unique_name()
>
>I've come to the conclusion that these semantics aren't
On Thu, 13 Jan 2005 22:41:54 +0300, Andrey Tatarinov <[EMAIL PROTECTED]> wrote:
>Nick Coghlan wrote:
>> Nick Coghlan wrote:
>>
>>> Semantics
>>> -
>>> The code::
>>>
>>> with:
>>>
>>>
>>> translates to::
>>>
>>> def unique_name():
>>>
>>>
>>> unique_name()
>> I've come to t
Nick Coghlan wrote:
Nick Coghlan wrote:
Semantics
-
The code::
with:
translates to::
def unique_name():
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
expressed in cur
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 sc
Nick Coghlan wrote:
Semantics
-
The code::
with:
translates to::
def unique_name():
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 expressed in current
Python due to t
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 ex
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
Andrey Tatarinov wrote:
afair you told yourself that
var = where:
translates to:
def unique_name():
return
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 there.
However, you're right tha
Nick Coghlan wrote:
Nick Coghlan wrote:
Semantics
-
The code::
with:
translates to::
def unique_name():
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 applying the abo
Nick Coghlan wrote:
Semantics
-
The code::
with:
translates to::
def unique_name():
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 applying the above
semantics to the
Nick Coghlan wrote:
Semantics
-
The code::
with:
translates to::
def unique_name():
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 applying the above semantics to
the
Nick Coghlan wrote:
Abstract
The proposal is to add the capacity for statement local namespaces to
Python. This allows a statement to be placed at the current scope, while
the statement's 'setup code' is indented after the statement::
with:
I think using 'with' keyword can c
+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
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 ::= "
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::
with:
trans
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::
>
>
19 matches
Mail list logo
