Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Date: Fri, 26 Oct 2012 18:26:26 -0500
From: Tim Chase <sed@thechases.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111120 Icedove/3.1.16
MIME-Version: 1.0
To: Cameron Simpson <cs@zip.com.au>
Subject: Re: while expression feature proposal
References: <7xlietjjsd.fsf@ruckus.brouhaha.com> <20121026220338.GA25126@cskk.homeip.net>
In-Reply-To: <20121026220338.GA25126@cskk.homeip.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: python-list@python.org
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.2914.1351293937.27098.python-list@python.org>
Lines: 49
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:32244

On 10/26/12 17:03, Cameron Simpson wrote:
> On 26Oct2012 09:10, Paul Rubin <no.email@nospam.invalid> wrote:
> |      while (client.spop("profile_ids") as profile_id) is not None:
> 
> Now this pulls me from a -0 to a +0.5.
> 
> Any doco would need to make it clear that no order of operation is
> implied, so that this:
> 
>   x = 1
>   y = (2 as x) + x
> 
> does not have a defined answer; might be 2, might be 3. Just like any
> other function call with side effects.

I really don't like undefined (or underdefined) specs.  If it was to
be PEP'd out, I'd want to address as many edge cases as possible.
Such as

  y = (2 as x) + (3 as x) + (4 as x)
  y = (2 as x) + 4 as x
  y = booleanish and (2 as x) or (4 as x)
  y = booleanish and 2 or 4 as x
  y = (2 as x) if booleanish else (3 as x)
  y = (2 as x) if booleanish else (3 as z)

regardless of how "$PEJORATIVE, that's a dumb thing to do!" it is.

I hate C for how underdefined a lot of corners are. ("amongst my
hatreds of C are such diverse elements as: underdefined corners, a
pitiful standard library, the ease of shooting yourself in the foot,
...")

> I'm not +1 because to my mind it still presents a way for
> assignment/binding to not be glaringly obvious at the left hand side of
> an expression.

I think this is why I like it in the "while" (and could be twisted
into accepting it for "if") because it also introduces an
implied/actual scope for which the variable is intended.  In an
arbitrary evaluation/assignment, it's much easier to lose the
"definition" nature of it at the top of a block.

-tkc