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
Op 2005-01-11, Jeff Shannon schreef [EMAIL PROTECTED]:
Paul Rubin wrote:
Steve Holden [EMAIL PROTECTED] writes:
[...] and if you think that
newbies will have their lives made easier by the addition of ad hoc
syntax extensions then you and I come from a different world (and I
suspect the walls
Steve Holden [EMAIL PROTECTED] writes:
Well I for one disagreed with many of your estimates of the zen's
applicability to macros, but I just couldn't be arsed saying so.
Well, I was being somewhat flip with them, as I felt Carl was being
snotty in referring me to the Zen list. The point there
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
Paul Rubin wrote:
Steve Holden [EMAIL PROTECTED] writes:
[...] and if you think that
newbies will have their lives made easier by the addition of ad hoc
syntax extensions then you and I come from a different world (and I
suspect the walls might be considerably harder in mine than in yours).
I'm
Andrey Tatarinov wrote:
And about examples for usage where keyword
reading http://manatee.mojam.com/~skip/python/fastpython.html I
understand that almost every example should use that keyword =)
I suspect polluting the outer namespace would still be faster, since Python
wouldn't have to create
Paul Rubin wrote:
Carl Banks [EMAIL PROTECTED] writes:
And a suite, be it a def statement, a where block, or whatever,
belongs
in a statement, not an expression.
So do you approve of the movement to get rid of the print statement?
Any little incremental change in Python you could make by
Carl Banks [EMAIL PROTECTED] writes:
So do you approve of the movement to get rid of the print statement?
Any little incremental change in Python you could make by having or not
having a print statement would be minor compared to the H-Bomb of
ugliness we'd get if suites of statements were
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:
Paul Rubin wrote:
Carl Banks [EMAIL PROTECTED] writes:
So do you approve of the movement to get rid of the print
statement?
Any little incremental change in Python you could make by having or
not
having a print statement would be minor compared to the H-Bomb of
ugliness we'd get if
Carl Banks [EMAIL PROTECTED] writes:
Paul Rubin wrote:
Carl Banks [EMAIL PROTECTED] writes:
So do you approve of the movement to get rid of the print
statement?
Any little incremental change in Python you could make by having or
not
having a print statement would be minor
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 ::=
Andrey Tatarinov wrote:
It would be great to be able to reverse usage/definition parts
in haskell-way with where keyword.
Hi folks, I really like this idea. But I couldn't help but think
of a few alternative ways. I'm no language design expert by any
means, but I'm a little concerned with
Paul Rubin wrote:
The Zen of Python, by Tim Peters
Beautiful is better than ugly. = +1 macros
Explicit is better than implicit. = +1 macros
Simple is better than complex. = +1 macros
Complex is better than complicated. = I don't understand this,
+0
Flat is
Carl Banks [EMAIL PROTECTED] writes:
When I asked you to do this, it was just a rhetorical way to tell you
that I didn't intend to play this game. It's plain as day you're
trying to get me to admit something. I'm not falling for it.
If you have a point to make, why don't you just make it?
Paul Rubin wrote:
Carl Banks [EMAIL PROTECTED] writes:
When I asked you to do this, it was just a rhetorical way to tell
you
that I didn't intend to play this game. It's plain as day you're
trying to get me to admit something. I'm not falling for it.
If you have a point to make, why
+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:
And about examples for usage where keyword
reading http://manatee.mojam.com/~skip/python/fastpython.html I
understand that almost every example should use that keyword =)
I suspect polluting the outer namespace would still be faster, since
Python wouldn't have to create the
On Sun, 09 Jan 2005 15:54:08 +1000, Nick Coghlan [EMAIL PROTECTED] wrote:
Here's another nice one if 'where' is added to compound statements as well:
@dbc(pre, post)
def foo():
pass
where:
def pre():
pass
def post():
pass
Interesting. It solves some of the issues
Peter Hansen wrote:
print words[3], words[5] where:
words = input.split()
- defining variables in where block would restrict their visibility
to one expression
Then your example above doesn't work... print takes a
sequence of expressions, not a tuple as you seem to think.
sorry, I used
AdSR [EMAIL PROTECTED] wrote:
I don't know haskell, but it looks SQL-ish to me (only by loose
Indeed, the fact that many MANY more people are familiar with SQL than
with Haskell may be the strongest practical objection to this choice of
syntax sugar; the WHERE clause in an SQL SELECT has such
Paul Rubin wrote:
You mean I can't say
# compute sqrt(2) + sqrt(3)
x = (sqrt(a) where:
a = 2.) \
+ sqrt (a) where:
a = 3.
No, I'd prefer to not embed 'where' into expression.
--
http://mail.python.org/mailman/listinfo/python-list
Nick Coghlan [EMAIL PROTECTED] writes:
Trying to push it a level further (down to expressions) would, IMO, be
a lot of effort for something which would hurt readability a lot.
I think we should just try to do things in a simple and general way
and not try to enforce readability. For example,
Alex Martelli wrote:
I wonder if 'with', which GvR is already on record as wanting to
introduce in 3.0, might not be overloaded instead.
Perhaps we could steal 'using' from the rejected decorator syntax.
x = [f(x) for x in seq] using:
def f(x):
return x * x
Cheers,
Nick.
--
Nick Coghlan |
Nick Coghlan wrote:
sorry, I used expression carelessly.
I mean that
print words[3], words[5]
is a single expression
(and that would be in Python 3, when print would be subtituted with
write()/writeln()).
'statement' is the appropriate word in Python's grammar.
thanks )
And I don't think we'd
Nick Coghlan [EMAIL PROTECTED] wrote:
Alex Martelli wrote:
I wonder if 'with', which GvR is already on record as wanting to
introduce in 3.0, might not be overloaded instead.
Perhaps we could steal 'using' from the rejected decorator syntax.
x = [f(x) for x in seq] using:
def f(x):
Andrey Tatarinov wrote:
sorry, I used expression carelessly.
I mean that
print words[3], words[5]
is a single expression
(and that would be in Python 3, when print would be subtituted with
write()/writeln()).
'statement' is the appropriate word in Python's grammar.
And I don't think we'd
Paul Rubin wrote:
Nick Coghlan [EMAIL PROTECTED] writes:
Trying to push it a level further (down to expressions) would, IMO, be
a lot of effort for something which would hurt readability a lot.
I think we should just try to do things in a simple and general way
and not try to enforce readability.
Paul Rubin wrote:
What would be the advantage of that over this?
. x = sqrt(a) + sqrt(b) where:
. a = 2.0
. b = 3.0
The idea of where is to allow re-using variable names instead of
having to keep track of which ones are in use. I just tried to give a
very simple example of how you might
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
Alex Martelli wrote:
Indeed, the fact that many MANY more people are familiar with SQL than
with Haskell may be the strongest practical objection to this choice of
syntax sugar; the WHERE clause in an SQL SELECT has such wildly
different semantics from Haskell's where that it might engender huge
And about examples for usage where keyword
reading http://manatee.mojam.com/~skip/python/fastpython.html I
understand that almost every example should use that keyword =)
--
http://mail.python.org/mailman/listinfo/python-list
Alex Martelli wrote:
AdSR [EMAIL PROTECTED] wrote:
I don't know haskell, but it looks SQL-ish to me (only by loose
Indeed, the fact that many MANY more people are familiar with SQL than
with Haskell may be the strongest practical objection to this choice of
syntax sugar; the WHERE clause in an
Paul Rubin wrote:
Nick Coghlan [EMAIL PROTECTED] writes:
Trying to push it a level further (down to expressions) would, IMO,
be
a lot of effort for something which would hurt readability a lot.
I think we should just try to do things in a simple and general way
and not try to enforce
Nick Coghlan wrote:
Andrey Tatarinov wrote:
Hi.
It would be great to be able to reverse usage/definition parts in
haskell-way with where keyword. Since Python 3 would miss lambda,
that
would be extremly useful for creating readable sources.
Usage could be something like:
res =
Nick Coghlan wrote:
Killer app for this keyword:
class C(object):
x = property(get, set) where:
def get(self):
return Silly property
def set(self, val):
self.x = Told you it was silly
Hey, this is super-elegant!
AdSR
--
http://mail.python.org/mailman/listinfo/python-list
AdSR [EMAIL PROTECTED] writes:
Killer app for this keyword:
class C(object):
x = property(get, set) where:
def get(self):
return Silly property
def set(self, val):
self.x = Told you it was silly
Hey, this is super-elegant!
Heh, even further:
z = C()
Bengt Richter wrote:
It also allows the necessary but uninteresting setup for an expression
to be moved out of the way, bringing the expression that does the real
work to prominence.
Killer app for this keyword:
class C(object):
x = property(get, set) where:
def get(self):
return Silly
Nick Coghlan wrote:
It also allows the necessary but uninteresting setup for an expression
to be moved out of the way, bringing the expression that does the
real work to prominence.
Killer app for this keyword:
class C(object):
x = property(get, set) where:
def get(self):
return
At the risk of generating controversy, here's another type of example:
def gcd(a, b):
where:
a: int, b: int
return c where:
c: int
while a:
a, b = b%a, a
return b
More can be found at http://aroberge.blogspot.com
Andre
--
http://mail.python.org/mailman/listinfo/python-list
Darn space-eater google groups :-( Here is it again, at teh risk of
generating controversy
.def gcd(a, b):
.where:
.a: int, b: int
.return c where:
.c: int
.while a:
.a, b = b%a, a
.return b
more examples can be found at aroberge.blogspot.com
André
--
When I first saw this I thought: hmmm... this seems as redundant as
adding a repeat/until loop to Python; there's no chance in hell it will
ever be accepted by the community or Guido, but I actually kinda like
it. It's nice to see mostly positive reactions to this idea so far.
I think it's a
Andrey Tatarinov wrote:
print words[3], words[5] where:
words = input.split()
- defining variables in where block would restrict their visibility to
one expression
Then your example above doesn't work... print takes a
sequence of expressions, not a tuple as you seem to think.
-Peter
--
On Sat, 08 Jan 2005 12:53:05 -0500, Peter Hansen [EMAIL PROTECTED] wrote:
Andrey Tatarinov wrote:
print words[3], words[5] where:
words = input.split()
- defining variables in where block would restrict their visibility to
one expression
Then your example above doesn't
Peter Hansen wrote:
Andrey Tatarinov wrote:
print words[3], words[5] where:
words = input.split()
- defining variables in where block would restrict their
visibility to
one expression
Then your example above doesn't work... print takes a
sequence of expressions, not a tuple
Carl Banks [EMAIL PROTECTED] writes:
You misunderstand. There where is not part of the expression but the
statement. The above example would be a modified print statement, a
print...where statement, if you will. Under this suggestion, there
would be modified versions of various simple
Paul Rubin wrote:
Carl Banks [EMAIL PROTECTED] writes:
You misunderstand.
BTW, Peter, I guess I should have said I misunderstand, but it can be
legal if you consider it part of the statements, since it appears the
author did intend it to be part of an expression.
There where is not part
Carl Banks [EMAIL PROTECTED] writes:
# compute sqrt(2) + sqrt(3)
x = (sqrt(a) where:
a = 2.) \
+ sqrt (a) where:
a = 3.
Hmmm.
What would be the advantage of that over this?
. x = sqrt(a) + sqrt(b) where:
. a = 2.0
. b = 3.0
The idea
On 8 Jan 2005 16:13:39 -0800, Carl Banks [EMAIL PROTECTED] wrote:
Bengt Richter wrote:
And, is the whole thing after the '=' an expression? E.g.,
x = ( foo(x) where:
x = math.pi/4.0
) where:
def foo(x): print 'just for illustration', x
How would that be any
Paul Rubin wrote:
What would be the advantage of that over this?
. x = sqrt(a) + sqrt(b) where:
. a = 2.0
. b = 3.0
The idea of where is to allow re-using variable names instead of
having to keep track of which ones are in use. I just tried to give a
very simple example of how you might
Nick Coghlan [EMAIL PROTECTED] writes:
I think having to keep the names unique within the statement you are
currently writing is a reasonable request :)
Um, you could say the same thing about the function, the module, etc. ;)
--
http://mail.python.org/mailman/listinfo/python-list
Paul Rubin wrote:
AdSR [EMAIL PROTECTED] writes:
Killer app for this keyword:
class C(object):
x = property(get, set) where:
def get(self):
return Silly property
def set(self, val):
self.x = Told you it was silly
Hey, this is super-elegant!
Heh, even further:
z = C() where:
Paul Rubin wrote:
Nick Coghlan [EMAIL PROTECTED] writes:
I think having to keep the names unique within the statement you are
currently writing is a reasonable request :)
Um, you could say the same thing about the function, the module, etc. ;)
And, indeed, that is what Python currently says. When
Nick Coghlan [EMAIL PROTECTED] writes:
x = (sqrt(a) where (a=2.0)) + (sqrt(b) where (a=3.0))
Hmm, I like that too.
--
http://mail.python.org/mailman/listinfo/python-list
Andrey Tatarinov wrote:
Hi.
It would be great to be able to reverse usage/definition parts in
haskell-way with where keyword. Since Python 3 would miss lambda, that
would be extremly useful for creating readable sources.
Usage could be something like:
res = [ f(i) for i in objects ] where:
Steven Bethard wrote:
How often is this really necessary? Could you describe some benefits of
this? I think the only time I've ever run into scoping problems is with
lambda, e.g.
[lambda x: f(x) for x, f in lst]
instead of
[lambda x, f=f: for x, f in lst]
Sorry, bad example, this
In article [EMAIL PROTECTED],
Steven Bethard [EMAIL PROTECTED] wrote:
Andrey Tatarinov wrote:
It would be great to be able to reverse usage/definition parts in
haskell-way with where keyword. Since Python 3 would miss lambda, that
would be extremly useful for creating readable sources.
Andrey Tatarinov wrote:
Hi.
It would be great to be able to reverse usage/definition parts in
haskell-way with where keyword. Since Python 3 would miss lambda, that
would be extremly useful for creating readable sources.
Usage could be something like:
res = [ f(i) for i in objects ] where:
Donn Cave [EMAIL PROTECTED] writes:
I don't by any means agree that this notation is worth adopting, and
in general I think this kind of readability issue is more or less a lost
cause for a language with Python's scoping rules, but the motive makes
sense to me.
But we're talking about the
Andrey Tatarinov wrote:
Hi.
It would be great to be able to reverse usage/definition parts in
haskell-way with where keyword. Since Python 3 would miss lambda, that
would be extremly useful for creating readable sources.
Usage could be something like:
res = [ f(i) for i in objects ] where:
Nick Coghlan [EMAIL PROTECTED] writes:
Usage could be something like:
res = [ f(i) for i in objects ] where:
def f(x):
#do something
Hmm, this is actually a really interesting idea. Avoiding accidental
namespace conflicts is certainly one of the advantages of using
Nick Coghlan wrote:
It also allows the necessary but uninteresting setup for an expression
to be moved out of the way, bringing the expression that does the real
work to prominence.
Killer app for this keyword:
class C(object):
x = property(get, set) where:
def get(self):
return
Paul Rubin wrote:
the suite has its own scope so any variable created there is local to
the suite plus the following statement. The scope vanishes after the
statement.
The second part of the idea is to give the statement greater prominence and
'hide' the uninteresting setup (the contents of the
But we're talking about the mythical/hypothetical Python 3, so maybe
there's a chance of fixing the scoping rules, which it seems to me
are
currently pretty badly broken.
I don't think the current scoping rules will be changed in Python 3.0.
I can't give you the link right now, but there are
73 matches
Mail list logo
