Paul Rubin wrote:
Huh? Expressions are not statements except when they're expression
statements? What kind of expression is not an expression statement?
any expression that is used in a content that is not an expression statement,
of course.
Come on, that is vacuous. The claim was
Op 2005-01-13, Terry Reedy schreef [EMAIL PROTECTED]:
Antoon Pardon [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Op 2005-01-13, Fredrik Lundh schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Well, it seems that Guido is wrong then. The documentation clearly
states that an
Op 2005-01-14, Fredrik Lundh schreef [EMAIL PROTECTED]:
Paul Rubin wrote:
Huh? Expressions are not statements except when they're expression
statements? What kind of expression is not an expression statement?
any expression that is used in a content that is not an expression
statement,
Antoon Pardon wrote:
no, expressions CAN BE USED as statements. that doesn't mean
that they ARE statements, unless you're applying belgian logic.
No I am applying set logic. Any string that is in the set of
valid expressions is also in the set of valid statements.
since you're arguing that
Op 2005-01-14, Nick Coghlan schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
No I am applying set logic. Any string that is in the set of
valid expressions is also in the set of valid statements.
According to Python's grammar, this is not the case. It requires a NEWLINE or
; token on the end
Fredrik no, expressions CAN BE USED as statements. that doesn't mean
Fredrik that they ARE statements, unless you're applying belgian logic.
Hmmm... I'd never heard the term belgian logic before. Googling provided
a few uses, but no formal definition (maybe it's a European phrase so
Op 2005-01-14, Fredrik Lundh schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
no, expressions CAN BE USED as statements. that doesn't mean
that they ARE statements, unless you're applying belgian logic.
No I am applying set logic. Any string that is in the set of
valid expressions is also
Skip Montanaro wrote:
Fredrik no, expressions CAN BE USED as statements. that doesn't
mean
Fredrik that they ARE statements, unless you're applying belgian
logic.
Hmmm... I'd never heard the term belgian logic before. Googling
provided
a few uses, but no formal definition (maybe it's
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
Craig Ringer schrieb:
And then we have iteration
(generator expressions, list comprehensions, for loops, ...?) over
(sequences, iterators, generators)
Just sequences and iterators. Generators are functions which return
iterators. Sequences and iterators provide two ways to build
containers.
Skip Montanaro wrote:
Fredrik no, expressions CAN BE USED as statements. that doesn't mean
Fredrik that they ARE statements, unless you're applying belgian
logic.
Hmmm... I'd never heard the term belgian logic before. Googling
provided a few uses, but no formal definition
Skip Montanaro wrote:
Fredrik no, expressions CAN BE USED as statements. that doesn't mean
Fredrik that they ARE statements, unless you're applying belgian logic.
Hmmm... I'd never heard the term belgian logic before. Googling provided
a few uses, but no formal definition (maybe it's a
Antoon Pardon wrote:
IMO we have a: dogs are mamals kind of relationship in Python.
I see what you mean, but I don't think it's true.
Every expression can be used where a statement is expected.
(And this can be worded as: every expression is a statement.)
Not really. An expression statement is a
Op 2005-01-14, Roel Schroeven schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
IMO we have a: dogs are mamals kind of relationship in Python.
I see what you mean, but I don't think it's true.
Every expression can be used where a statement is expected.
(And this can be worded as: every
Antoon Pardon wrote:
Well IMO I have explained clearly that I understood this in a set
logical sense in my first response.
what does first mean on your planet?
/F
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-01-12, Steve Holden schreef [EMAIL PROTECTED]:
Given that Guido is on record as saying that expressions aren't
statements because he wants those things to be separate, I don't really
see why there's this consistent pressure to reverse that decision.
Well, it seems that Guido is
Antoon Pardon wrote:
Well, it seems that Guido is wrong then. The documentation clearly
states that an expression is a statement.
no, it says that an expression statement is a statement. if you don't
understand the difference, please *plonk* yourself.
/F
--
Op 2005-01-13, Fredrik Lundh schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Well, it seems that Guido is wrong then. The documentation clearly
states that an expression is a statement.
no, it says that an expression statement is a statement. if you don't
understand the difference, please
Fredrik Lundh wrote:
Antoon Pardon wrote:
Well, it seems that Guido is wrong then. The documentation clearly
states that an expression is a statement.
no, it says that an expression statement is a statement. if you don't
understand the difference, please *plonk* yourself.
OK then, The
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 Thu, 2005-01-13 at 08:39 +, Antoon Pardon wrote:
At best it would offer new paradigms for existing constructs (violating
the there should be one obvious way to do it zen); at worst it would
obfuscate the whole language.
That zen is already broken. Look at the number of answers
Terry Reedy [EMAIL PROTECTED] writes:
Well, it seems that Guido is wrong then. The documentation clearly
states that an expression is a statement.
no, it says that an expression statement is a statement. if you don't
understand the difference, please *plonk* yourself.
And what else
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
On Thu, 13 Jan 2005 09:29:49 -0500, Steve Holden [EMAIL PROTECTED] wrote:
Fredrik Lundh wrote:
Antoon Pardon wrote:
Well, it seems that Guido is wrong then. The documentation clearly
states that an expression is a statement.
no, it says that an expression statement is a statement. if
Fredrik Lundh [EMAIL PROTECTED] writes:
Huh? Expressions are not statements except when they're expression
statements? What kind of expression is not an expression statement?
any expression that is used in a content that is not an expression statement,
of course.
Come on, that is
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
Paul Rubin wrote:
Come on, that is vacuous. The claim was expressions are not
statements. But it turns out that expressions ARE statements. The
explanation is well, that's because they're expression statements.
And there is no obvious case of an expression that can't be used as a
statement. So
Nick Coghlan [EMAIL PROTECTED] writes:
So, precisely how should one go about cleanly embedding something that
cares about whitespace into a context which doesn't care in the
slightest?
Treat the macro like a function call whose arguments are thunks made
from the macro arguments, or something
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
[EMAIL PROTECTED] writes:
I can't imagine how it could be worse than the learning curve of
__metaclass__, which we already have.
To me, learning macros *and their subtilities* was much more difficult
than learning metaclasses.
I guess I've only used Lisp macros in pretty straightforward
Paul Rubin wrote:
[EMAIL PROTECTED] writes:
2. One could proposed hygienic pattern-matching macros in Python,
similar to
Scheme syntax-rules macros. Again, it is not obvious how to
implement pattern-matching in Python in a non-butt-ugly way. Plus,
I feel hygienic macros quite limited and not worth
Paul Rubin wrote:
[EMAIL PROTECTED] writes:
I can't imagine how it could be worse than the learning curve of
__metaclass__, which we already have.
To me, learning macros *and their subtilities* was much more difficult
than learning metaclasses.
I guess I've only used Lisp macros in pretty
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
Paul Rubin wrote:
How about macros? Some pretty horrible things have been done in C
programs with the C preprocessor. But there's a movememnt afloat to
add hygienic macros to Python. Got any thoughts about that?
Movement seems quite an exaggeration. Maybe 2-3 people made some
experiments, but
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
[EMAIL PROTECTED] writes:
2. One could proposed hygienic pattern-matching macros in Python,
similar to
Scheme syntax-rules macros. Again, it is not obvious how to
implement pattern-matching in Python in a non-butt-ugly way. Plus,
I feel hygienic macros quite limited and not worth the effort.
Paul Rubin:
[EMAIL PROTECTED] writes:
about Scheme macros
It wasn't obvious how to do it in Scheme either. There was quite
a bit of head scratching and experimental implementation before
there was consensus.
Actually I am not convinced there is consensus yet, i.e. there is a
non-negligible
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
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:
def f(x):
#do
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:
1 - 100 of 104 matches
Mail list logo
