Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Python (http://www.velocityreviews.com/forums/f43-python.html)
-   -   python3: 'where' keyword (http://www.velocityreviews.com/forums/t340042-python3-where-keyword.html)

Andrey Tatarinov 01-07-2005 05:56 PM

python3: 'where' keyword
 
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.

Steven Bethard 01-07-2005 06:17 PM

Re: python3: 'where' keyword
 
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 01-07-2005 06:23 PM

Re: python3: 'where' keyword
 
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

Donn Cave 01-07-2005 07:53 PM

Re: python3: 'where' keyword
 
In article <xdCdnUz9muXfT0PcRVn-vg@comcast.com>,
Steven Bethard <steven.bethard@gmail.com> 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, donn@u.washington.edu

AdSR 01-07-2005 08:04 PM

Re: python3: 'where' keyword
 
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


I don't know haskell, but it looks SQL-ish to me (only by loose
association). And it's not that unpythonic - it resembles

>>> res = [x for x in sequence if x.isOk()]


> or
>
> >>> print words[3], words[5] where:
> >>> words = input.split()


Here's a shorter version:

>>> print input.split()[3:5:2]


(Does it qualify as obfuscated Python code? :) )

> - 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,


Yes, I like the readability of it, too.

> 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.


When I first read your post, I thought "Well, just one more of those
Py3k ideas that appear on c.l.py every day." But as I look at the latter
example, I think you have just scratched my itch. The same thing has
bugged me more than once in my code.

I think this idea is of the same kind as the @decorator syntax. Guido
moved an operation to a point in the code where it was more visible. You
moved an operation to a more local context where (pun not intended) it
really belongs.

I'm usually rather conservative about Python syntax (@decorators,
absolute/relative imports, if-else operator), but this one could appear
in Python tomorrow and that would be too far in the future for me ;)

Cheers,

AdSR

Paul Rubin 01-07-2005 09:28 PM

Re: python3: 'where' keyword
 
Donn Cave <donn@u.washington.edu> 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 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.

Nick Coghlan 01-08-2005 06:08 AM

Re: python3: 'where' keyword
 
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


Hmm, this is actually a really interesting idea. Avoiding accidental namespace
conflicts is certainly one of the advantages of using lambdas.

This idea has the virtue of being able to do the same thing, but have full
access to Python's function syntax and assignment statements in the 'expression
local' suite.

In fact, any subexpressions in a complicated expression can be extracted and
named for clarity without fear of screwing up the containing namespace, which
would be an enormous boon for software maintainers.

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.

From the interpreter's point of view, the meaning would probably be something like:

namespace = locals()
exec where_suite in globals(), namespace
exec statement in globals(), namespace
res = namespace["res"]
del namespace

Making the 'where' clause part of the grammar for the assignment statement
should be enough to make the above example parseable, too.

The clause might actually make sense for all of the simple statement forms in
the grammar which contain an expression:
expression statement
assignment statement
augmented assignment statement
del statement
print statement
return statement
yield statement
raise statement
exec statement

The clause really isn't appropriate for break, continue, import or global
statements, as they don't contain any expressions :)

For compound statements, a where clause probably isn't appropriate, as it would
be rather unclear what the where clause applied to.

Cheers,
Nick.

--
Nick Coghlan | ncoghlan@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

Paul Rubin 01-08-2005 06:30 AM

Re: python3: 'where' keyword
 
Nick Coghlan <ncoghlan@iinet.net.au> 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 lambdas.


I like it too. Seems a little perl-ish, but what the hey.

> In fact, any subexpressions in a complicated expression can be
> extracted and named for clarity without fear of screwing up the
> containing namespace, which would be an enormous boon for software
> maintainers.


Sure, why not:

x = (-b + sqrt(discriminant))/(2*a) where:
discriminant = b*b - 4*a*c

Maybe you could just have a where: suite that binds variables
within the suite:

where:
def f(x):
#do something
res = [ f(i) for i in objects ]

where:
discriminant = b*b - 4*a*c
x = (-b + sqrt(discriminant))/(2*a)

Syntax is
where:
suite
statement

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.

Nick Coghlan 01-08-2005 06:42 AM

Re: python3: 'where' keyword
 
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 "Silly property"
def set(self, val):
self.x = "Told you it was silly"

Cheers,
Nick.

--
Nick Coghlan | ncoghlan@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

Nick Coghlan 01-08-2005 06:47 AM

Re: python3: 'where' keyword
 
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 where clause).

Putting the statement of interest after the where suite still gives the benefits
of avoiding namespace clutter, but doesn't really help readability (it makes it
worse, if you ask me).

Particularly, what if the next statement is a compound statement?

Cheers,
Nick.

--
Nick Coghlan | ncoghlan@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net


All times are GMT. The time now is 04:06 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.