Hi, while "as" is being made a keyword, I remembered parallels between "with" and a proposal made some time ago: with expr as f: do something with f while expr as f: do something with f if expr as f: do something with f elif expr as f: do something else with f What do you think? Georg
I suggest you file those as products of an overactive imagination. :-)
Have you even tried to define precise semantics for any of those, like
the expansion of "with E as V: B" in PEP 343?
--Guido
On 3/7/06, Georg Brandl
Hi,
while "as" is being made a keyword, I remembered parallels between "with" and a proposal made some time ago:
with expr as f: do something with f
while expr as f: do something with f
if expr as f: do something with f elif expr as f: do something else with f
What do you think?
Georg
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
[HPH the BDFL]
I suggest you file those as products of an overactive imagination. :-)
At least not only mine. ;)
Have you even tried to define precise semantics for any of those, like the expansion of "with E as V: B" in PEP 343?
Easily. if expr as name: BLOCK would be equivalent to name = expr if name: BLOCK del name Same for while. Georg
On 3/7/06, Georg Brandl
Have you even tried to define precise semantics for any of those, like the expansion of "with E as V: B" in PEP 343?
Easily.
if expr as name: BLOCK
would be equivalent to
name = expr if name: BLOCK del name
You need to be a little more formal. What happens when there are elif or else clauses? Why the del at all? (with doesn't delete VAR). You also need to present a better motivation. What would be the point of having a separate name for the value True or False when you already know its value based on which branch you execute? And what exactly is the big savings? If you look at the motivation for with E as V, V is *not* assigned the value of E (but rather E.__context__().__enter__()) and the with statement as a whole has a very good reason for its existence. Your proposal here lacks that.
Same for while.
You aren't really trying, are you? What would the point be of NAME = EXPR while NAME: BLOCK del NAME (Hint: while needs EXPR to be reevaluated each time through the loop.) -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
On 3/7/06, Georg Brandl
wrote: Have you even tried to define precise semantics for any of those, like the expansion of "with E as V: B" in PEP 343?
Easily.
if expr as name: BLOCK
would be equivalent to
name = expr if name: BLOCK del name
You need to be a little more formal. What happens when there are elif or else clauses? Why the del at all? (with doesn't delete VAR).
You also need to present a better motivation. What would be the point of having a separate name for the value True or False when you already know its value based on which branch you execute? And what exactly is the big savings? If you look at the motivation for with E as V, V is *not* assigned the value of E (but rather E.__context__().__enter__()) and the with statement as a whole has a very good reason for its existence. Your proposal here lacks that.
Thinking over it, this is too much a difference between the with-"as" and my "as", so I'm abandoning this idea. My "as" would just have been a shortcut to avoid writing longish expressions that have to be checked for true-ness and then tinkered with.
Same for while.
You aren't really trying, are you?
No ;) I would have written a PEP anyway. Cheers, Georg
Thinking over it, this is too much a difference between the with-"as" and my "as", so I'm abandoning this idea. My "as" would just have been a shortcut to avoid writing longish expressions that have to be checked for true-ness and then tinkered with.
ML has a similar feature, which you may consider as an argument either for or against it depending on your taste. The point is that ML lets you write "patterns" that decompose data structures, and the "as" usage lets you talk about the whole data structure and the decomposed one at the same time. For example, in ML, :: works like "cons" in Lisp, so that x::y is a list with a first element of x and a tail of y, which must be a list. In other words, [3, 4, 5] is equivalent to (3::4::5::nil) in ML. Now consider the following: fun merge(nil, y) = y | merge(x, nil) = x | merge (x as xh::ht, y as yh::yt) = if xh < yh then xh::merge(xt, y) else xt::merge(x, yt) Without the "as" clause, we would have had to write fun merge(nil, y) = y | merge(x, nil) = x | merge(x, y) = let val xh::xt = x val yh::yt = y in if xh < yh then xh::merge(xt, y) else xt::merge(x, yt) end which is somewhat longer and harder to follow. As it turns out, Python has similar ways of decomposing data structures: (x, y) = foo or def bar((x, y)): # etc. and I have sometimes wished I could write z as (x, y) = foo or def bar(z as (x, y)): # etc. However, it's not real high on my list of priorities, and I suspect that many Pythonists consider these usages to be a frill anyway.
On 3/7/06, Andrew Koenig
As it turns out, Python has similar ways of decomposing data structures:
(x, y) = foo
or
def bar((x, y)): # etc.
and I have sometimes wished I could write
z as (x, y) = foo
or
def bar(z as (x, y)): # etc.
However, it's not real high on my list of priorities, and I suspect that many Pythonists consider these usages to be a frill anyway.
For the assignment case, you can do this:
foo = (1,2) (x,y) = z = foo x 1 y 2 z (1, 2)
Function arguments are not covered by this trick, but def bar(z): (x,y) = z probably isn't too much overhead... (Or did I miss your point?) Paul.
Function arguments are not covered by this trick, but
def bar(z): (x,y) = z
probably isn't too much overhead...
It's not the machine overhead, it's the intellectual overhead. I know there are some who will disagree with me, but I would find it easier to read def foo(origin as (x1, y1), corner as (x2, y2)): than to read def foo(origin, corner): (x1, y1) = origin (x2, y2) = corner It's not a big deal, but it is not completely negligible either.
Andrew Koenig wrote:
Function arguments are not covered by this trick, but
def bar(z): (x,y) = z
probably isn't too much overhead...
It's not the machine overhead, it's the intellectual overhead. I know there are some who will disagree with me, but I would find it easier to read
def foo(origin as (x1, y1), corner as (x2, y2)):
than to read
def foo(origin, corner): (x1, y1) = origin (x2, y2) = corner
It's not a big deal, but it is not completely negligible either.
On the third hand, what about
def foo((x1, y1), (x2, y2)): ... print x1, y1, x2, y2 ... origin = (10, 1) corner = (20, 2) foo(origin, corner) 10 1 20 2
Follow-ups set to comp.lang.python :-) regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd www.holdenweb.com Love me, love my blog holdenweb.blogspot.com
On Mar 7, 2006, at 6:15 AM, Georg Brandl wrote:
Hi,
while "as" is being made a keyword, I remembered parallels between "with" and a proposal made some time ago:
with expr as f: do something with f
while expr as f: do something with f
if expr as f: do something with f elif expr as f: do something else with f
What do you think?
I think the best use cases for 'assignment inside an if or while' condition, as far as they go, require `capturing' a SUB-expression of the condition, rather than the whole condition. E.g., in C, while ( (x=next_x()) < threshold ) ... being able to capture (by `as') only the whole (true or false) condition meets a minority of the use cases, so I'm unenthusiastic about it. Alex
Alex Martelli wrote:
I think the best use cases for 'assignment inside an if or while' condition, as far as they go, require `capturing' a SUB-expression of the condition, rather than the whole condition. E.g., in C,
while ( (x=next_x()) < threshold ) ...
being able to capture (by `as') only the whole (true or false) condition meets a minority of the use cases, so I'm unenthusiastic about it.
There are use cases (because every value can be tested for true-ness), such as the likes of while file.readline() as line: BLOCK (which is not needed for builtin file objects, I know) or something like m = re.match(...) if m.group(1) as filename: do something with filename Georg
Georg Brandl
or something like
m = re.match(...) if m.group(1) as filename: do something with filename
Except that m could be None, which would raise an exception during the .group(1) call. Perhaps you meant... m = re.match(...) if m and m.group(1) as filename: do something with filename I'm -1 on the 'as'-itis. - Josiah
Alex Martelli wrote:
On Mar 7, 2006, at 6:15 AM, Georg Brandl wrote:
with expr as f: do something with f
I expect the "with" example here is a red herring, not intended to have anything to do with the new "with" statement that's just been added.
I think the best use cases for 'assignment inside an if or while' condition, as far as they go, require `capturing' a SUB-expression of the condition, rather than the whole condition. E.g., in C,
while ( (x=next_x()) < threshold ) ...
IIUC, that would be while (next_x() as x) < threshold: ... i.e. 'x as y' would be an expression. -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | greg.ewing@canterbury.ac.nz +--------------------------------------+
participants (8)
-
Alex Martelli
-
Andrew Koenig
-
Georg Brandl
-
Greg Ewing
-
Guido van Rossum
-
Josiah Carlson
-
Paul Moore
-
Steve Holden