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 something
or
print words[3], words[5] where:
words = input.split()
- defining variables in "where" block would restrict their visibility to
one expression
- it''s more easy to read sources when you know which part you can skip,
compare to
def f(x):
#do something
res = [ f(i) for i in objects ]
in this case you read definition of "f" before you know something about
it usage.
解决方案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:
>>> def f(x):
>>> #do something
or
>>> print words[3], words[5] where:
>>> words = input.split()
- defining variables in "where" block would restrict their visibility to
one expression
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]
Are there other situations where you run into these kinds of problems?
- it''s more easy to read sources when you know which part you can skip,
compare to
>>> def f(x):
>>> #do something
>>> res = [ f(i) for i in objects ]
in this case you read definition of "f" before you know something about
it usage.
Hmm... This seems very heavily a matter of personal preference. I find
that your where clause makes me skip the ''res'' assignment to read what
the ''res'' block contains. I had to read it twice before I actually
looked at the list comprehension. Of course, I''m sure I could be
retrained to read it the right way, but until I see some real benefit
from it, I''d rather not have to.
TOOWTDI-ily-yrs,
Steve
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 should have looked something more like:
[lambda y: f(x, y) for x, f in lst]
....
[lambda y, x=x, f=f: f(x, y) for x, f in lst]
where you actually need the lambda.
Steve
In article ,
Steven Bethard 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.
Usage could be something like:
>>> res = [ f(i) for i in objects ] where:
>>> def f(x):
>>> #do something
or
>>> print words[3], words[5] where:
>>> words = input.split()
- defining variables in "where" block would restrict their visibility to
one expression
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]
Are there other situations where you run into these kinds of problems?
Note that he says "would be extremely useful for creating readable
sources", so the "these kinds of problems" he would have been thinking
of would be where source was not as readable as it could be. You seem
to be concerned about something else.
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. One way to look at it might be, if I observe that "words"
is assigned to in a where clause, then I know it will not be used
elsewhere in the surrounding scope so I can forget about it right away.
If the name does occur elsewhere, it evidently refers to something else.
Donn Cave, do**@u.washington.edu