On 10/26/12 19:18, Steven D'Aprano wrote:
> def iterate_until_none_or_false(func, *args, **kwargs):
> while True:
> x = func(*args, **kwargs)
> # Halt if x is None or False, but not other falsey values.
> if x is None or x is False:
> return
> yield x
Steven D'Aprano writes:
> There's no need for it *inside* of while expressions. It doesn't add to
> the expressiveness of the language, or increase the power of the
> language, or help people write correct code. It saves one trivial line of
> code in some, but not all, while loops, at the cost
On Sat, Oct 27, 2012 at 10:19 AM, Devin Jeanpierre
wrote:
> On Fri, Oct 26, 2012 at 2:23 AM, Chris Angelico wrote:
>> while (client.spop("profile_ids") as profile_id) is not None:
>> print profile_id
>>
>> Why is everyone skirting around C-style assignment expressions as
>> though they're sim
On Fri, Oct 26, 2012 at 8:18 PM, Steven D'Aprano
wrote:
>> I would like a better iter(), rather than a better while loop. It is
>> irritating to pass in functions that take arguments, and it is
>> impossible to, say, pass in functions that should stop being iterated
>> over when they return _eithe
On 26Oct2012 19:19, Devin Jeanpierre wrote:
| (I've always been partial to ":=", personally.)
I'm less so. It is hard to type (on my keyboard anyway, that's a shifted
keystroke followed by an unshifted one). I mank that up often enough
that I would resent it for something as oft used as an assign
On Fri, 26 Oct 2012 19:12:17 -0400, Devin Jeanpierre wrote:
> I would like a better iter(), rather than a better while loop. It is
> irritating to pass in functions that take arguments, and it is
> impossible to, say, pass in functions that should stop being iterated
> over when they return _eithe
On 26Oct2012 16:48, Ian Kelly wrote:
| On Fri, Oct 26, 2012 at 4:03 PM, Cameron Simpson wrote:
| > It will work anywhere an expression is allowed, and superficially
| > doesn't break stuff that exists if "as" has the lowest precedence.
|
| Please, no. There is no need for it outside of while ex
On 27Oct2012 10:56, I wrote:
| On 26Oct2012 19:41, Devin Jeanpierre wrote:
| | But function calls with side effects _do_ have a defined order of
| | evaluation. Left to right.
| | And the answer should be 4.
| | http://docs.python.org/reference/expressions.html#evaluation-order
|
| No. Separate _
On 26Oct2012 18:26, Tim Chase wrote:
| On 10/26/12 17:03, Cameron Simpson wrote:
| > On 26Oct2012 09:10, Paul Rubin 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
On Fri, Oct 26, 2012 at 7:56 PM, Cameron Simpson wrote:
> No. Separate _expressions_ are evaluated left to right.
>
> So this:
>
> f(1), f(2)
>
> calls "f(1)" first, then "f(2)". But this:
>
> f(1) + f(2)
>
> need not do so. Counter-documentation welcomed, but the doco you cite
> does not defi
On Fri, Oct 26, 2012 at 7:41 PM, Dan Loewenherz wrote:
-- snip insanity --
>
> But this is yucky. I'd much rather have something a bit more clear to the
> reader.
That's why I said I wanted a better iter, not some equality-overriding
object strawman thing.
I was thinking more like this:
for
On 26Oct2012 19:41, Devin Jeanpierre wrote:
| On Fri, Oct 26, 2012 at 6:03 PM, Cameron Simpson wrote:
| > 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
On Fri, Oct 26, 2012 at 6:03 PM, Cameron Simpson wrote:
> 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.
On Fri, Oct 26, 2012 at 4:12 PM, Devin Jeanpierre wrote:
>
> For loops are pythonic. You can do this in Python today:
>
> client = StrictRedis()
> for profile_id in iter(lambda: client.spop("profile_ids"), None):
> pass
>
> I would like a better iter(), rather than a better while l
On 10/26/12 17:03, Cameron Simpson wrote:
> On 26Oct2012 09:10, Paul Rubin 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:
>
>
On Fri, Oct 26, 2012 at 2:23 AM, Chris Angelico wrote:
> while (client.spop("profile_ids") as profile_id) is not None:
> print profile_id
>
> Why is everyone skirting around C-style assignment expressions as
> though they're simultaneously anathema and the goal? :)
Why should these two statem
On Fri, Oct 26, 2012 at 1:12 AM, Dan Loewenherz wrote:
> It seems the topic of this thread has changed drastically from the original
> message.
>
> 1) "while EXPR as VAR" in no way says that EXPR must be a boolean value. In
> fact, a use case I've run into commonly in web development is popping
On Fri, Oct 26, 2012 at 4:03 PM, Cameron Simpson wrote:
> It will work anywhere an expression is allowed, and superficially
> doesn't break stuff that exists if "as" has the lowest precedence.
Please, no. There is no need for it outside of while expressions, and
anywhere else it's just going to
On 26Oct2012 09:10, Paul Rubin wrote:
| However, if the "as" can be part of an expression as in Chris Angelico's
| post, Chris's suggestion
|
| while (client.spop("profile_ids") as profile_id) is not None:
| print profile_id
|
| looks good to me.
Now this pulls me from a -0 to a +
Dan Loewenherz writes:
> We also don't special case things like this just because x is an empty
> string. If this "while EXPR as VAR" thing were to move forward, we
> shouldn't treat the truth testing any differently than how we already
> do. IMO we should write our applications with the understan
On Fri, Oct 26, 2012 at 9:29 AM, Dan Loewenherz wrote:
> while client.spop("profile_ids") as truthy, profile_id:
> if not truthy:
> break
>
> print profile_id
>
> Here, client.spop returns a tuple, which will always returns true. We then
> extract the first element
On Thursday, October 25, 2012 11:06:01 PM UTC-7, Paul Rubin wrote:
> Dan Loewenherz writes:
>
> > In this case, profile_id is "None" when the loop breaks. It would be
>
> > much more straightforward (and more Pythonic, IMO), to write:
>
> >
>
> > client = StrictRedis()
>
> > while cli
On Fri, 26 Oct 2012 17:23:12 +1100, Chris Angelico wrote:
> Why is everyone skirting around C-style assignment expressions as though
> they're simultaneously anathema and the goal? :)
Only if your goal is to introduce an anathema :P
--
Steven
--
http://mail.python.org/mailman/listinfo/python-
On Fri, Oct 26, 2012 at 5:06 PM, Paul Rubin wrote:
> Dan Loewenherz writes:
>> In this case, profile_id is "None" when the loop breaks. It would be
>> much more straightforward (and more Pythonic, IMO), to write:
>>
>> client = StrictRedis()
>> while client.spop("profile_ids") as profile_
Dan Loewenherz writes:
> In this case, profile_id is "None" when the loop breaks. It would be
> much more straightforward (and more Pythonic, IMO), to write:
>
> client = StrictRedis()
> while client.spop("profile_ids") as profile_id:
> print profile_id
That is pretty loose, in my
It seems the topic of this thread has changed drastically from the original
message.
1) "while EXPR as VAR" in no way says that EXPR must be a boolean value. In
fact, a use case I've run into commonly in web development is popping from a
redis set. E.g.
client = StrictRedis()
while Tru
Am 25.10.2012 18:36 schrieb Ian Kelly:
On Thu, Oct 25, 2012 at 1:21 AM, Thomas Rachel
wrote:
j = next(j for j in iter(partial(randrange, n), None) if j not in
selected)
This generator never ends. If it meets a non-matching value, it just skips
it and goes on.
next() only returns one value.
On 10/25/2012 6:50 AM, Steven D'Aprano wrote:
On Thu, 25 Oct 2012 11:52:31 +0200, Thomas Rachel wrote:
Am 25.10.2012 06:50 schrieb Terry Reedy:
Keep in mind that any new syntax has to be a substantial improvement in
some sense or make something new possible. There was no new syntax in
3.2 and
On Thu, Oct 25, 2012 at 10:36 AM, Ian Kelly wrote:
> On Thu, Oct 25, 2012 at 1:21 AM, Thomas Rachel
>
> wrote:
>>> j = next(j for j in iter(partial(randrange, n), None) if j not in
>>> selected)
>>
>>
>> This generator never ends. If it meets a non-matching value, it just skips
>> it and goes on.
On Thu, Oct 25, 2012 at 3:52 AM, Thomas Rachel
wrote:
> Am 25.10.2012 06:50 schrieb Terry Reedy:
>
>
>> Keep in mind that any new syntax has to be a substantial improvement in
>> some sense or make something new possible. There was no new syntax in
>> 3.2 and very little in 3.3.
>
>
> I would cons
On Thu, Oct 25, 2012 at 1:21 AM, Thomas Rachel
wrote:
>> j = next(j for j in iter(partial(randrange, n), None) if j not in
>> selected)
>
>
> This generator never ends. If it meets a non-matching value, it just skips
> it and goes on.
next() only returns one value. After it is returned, the gene
Am 25.10.2012 16:15 schrieb Grant Edwards:
I guess that depends on what sort of programs you write. In my
experience, EXPR is usually a read from a file/socket/pipe that
returns '' on EOF. If VAR is not '', then you process, then you
process it inside the loop.
Right. The same as in
if regex
On 2012-10-25, Terry Reedy wrote:
> The op wondered if these proposals have been made before. They have
> been, and have been rejected. Some of the discussion has been on
> python-ideas list. But go ahead and brainstorm and discuss.
>
> Keep in mind that any new syntax has to be a substantial i
On 2012-10-24, Cameron Simpson wrote:
>| I must say I really like the parity of Dan's
>| while EXPR as VAR:
>| BLOCK
>| proposal with the "with" statement.
>
> Well, it's nice. But usually EXPR will be a boolean.
I guess that depends on what sort of programs you write. In my
experience,
Am 25.10.2012 12:50 schrieb Steven D'Aprano:
Then I think you have misunderstood the purpose of "yield from".
Seems so. As I have not yet switched to 3.x, I haven't used it till now.
[quote]
However, if the subgenerator is to interact properly with the caller in
the case of calls to send(),
On 25-10-12 06:50, Terry Reedy wrote:
> On 10/24/2012 7:19 PM, Evan Driscoll wrote:
>> On 10/24/2012 05:26 PM, Cameron Simpson wrote:
>>> But I'm still -0 on it, because it supplants the glaringly obvious:
>>>
>>>m = ...
>>>
>>> assignment with the far less in your face:
>>>
>>>possibly-lon
On Thu, 25 Oct 2012 11:52:31 +0200, Thomas Rachel wrote:
> Am 25.10.2012 06:50 schrieb Terry Reedy:
>
>> Keep in mind that any new syntax has to be a substantial improvement in
>> some sense or make something new possible. There was no new syntax in
>> 3.2 and very little in 3.3.
>
> I would con
Am 25.10.2012 09:21 schrieb Thomas Rachel:
I think
# iterate ad inf., because partial never returns None:
i1 = iter(partial(randrange, n), None)
# take the next value, make it None for breaking:
i2 = (j if j in selected else None for j in i1)
# and now, break on None:
i3 = iter(lambda: next(i2)
Am 25.10.2012 06:50 schrieb Terry Reedy:
Keep in mind that any new syntax has to be a substantial improvement in
some sense or make something new possible. There was no new syntax in
3.2 and very little in 3.3.
I would consinder this at least as new substantial than
yield_from it
as oppo
Am 25.10.2012 00:26 schrieb Cameron Simpson:
If I could write this as:
if re_FUNKYPATTERN.match(test_string) as m:
do stuff with the results of the match, using "m"
then some cascading parse decisions would feel a bit cleaner. Where I
current have this:
m = re_CONSTRUCT1.match(line
Paul Rubin writes:
> kind of ugly, makes me wish for a few more itertools primitives
JOOI, do you have specific primitives in mind?
--
http://mail.python.org/mailman/listinfo/python-list
Am 25.10.2012 01:39 schrieb Ian Kelly:
On Wed, Oct 24, 2012 at 5:08 PM, Paul Rubin wrote:
from itertools import dropwhile
j = dropwhile(lambda j: j in selected,
iter(lambda: int(random() * n), object()))
.next()
kind of ugly, makes me wish for a few more iterto
On 10/24/2012 7:19 PM, Evan Driscoll wrote:
On 10/24/2012 05:26 PM, Cameron Simpson wrote:
But I'm still -0 on it, because it supplants the glaringly obvious:
m = ...
assignment with the far less in your face:
possibly-long-expr as m
and I think it would get quite heavily used, to the
On Wed, Oct 24, 2012 at 5:08 PM, Paul Rubin wrote:
> from itertools import dropwhile
>
> j = dropwhile(lambda j: j in selected,
> iter(lambda: int(random() * n), object()))
> .next()
>
> kind of ugly, makes me wish for a few more itertools primitives, but I
> think it
On 10/24/2012 05:26 PM, Cameron Simpson wrote:
> But I'm still -0 on it, because it supplants the glaringly obvious:
>
> m = ...
>
> assignment with the far less in your face:
>
> possibly-long-expr as m
>
> and I think it would get quite heavily used, to the detriment of
> assignment reada
Ian Kelly writes:
> j = int(random() * n)
> while j in selected:
> j = int(random() * n)
from itertools import dropwhile
j = dropwhile(lambda j: j in selected,
iter(lambda: int(random() * n), object()))
.next()
kind of ugly, makes me wish for a few more itertoo
On 24Oct2012 15:37, Paul Rubin wrote:
| Cameron Simpson writes:
| > if re_FUNKYPATTERN.match(test_string) as m:
| > do stuff with the results of the match, using "m"
|
| class memo:
| def __call__(f, *args, **kw):
| self.result = f(*args, **kw)
|
| m = memo()
| if resul
On 25Oct2012 09:40, Chris Angelico wrote:
| On Thu, Oct 25, 2012 at 9:26 AM, Cameron Simpson wrote:
| > If I could write this as:
| >
| > if re_FUNKYPATTERN.match(test_string) as m:
| > do stuff with the results of the match, using "m"
|
| Then you'd be right there with C-like languages wh
On Wed, Oct 24, 2012 at 3:54 PM, Tim Chase
wrote:
> It may be idiomatic, but that doesn't stop it from being pretty
> ugly. I must say I really like the parity of Dan's
>
> while EXPR as VAR:
> BLOCK
>
> proposal with the "with" statement. It also doesn't fall prey to
> the "mistaken-assi
On 10/24/12 17:26, Cameron Simpson wrote:
> On 24Oct2012 16:54, Tim Chase wrote:
> | On 10/24/12 16:34, Ian Kelly wrote:
> | > The idiomatic way to do this is:
> | >
> | > while True:
> | > VAR = EXPR
> | > if not VAR:
> | > break
> | > BLOCK
> |
> | It may be idiomatic, but
Paul Rubin writes:
> class memo:
> def __call__(f, *args, **kw):
> self.result = f(*args, **kw)
obviously add
return self.result
--
http://mail.python.org/mailman/listinfo/python-list
On Thu, Oct 25, 2012 at 9:26 AM, Cameron Simpson wrote:
> If I could write this as:
>
> if re_FUNKYPATTERN.match(test_string) as m:
> do stuff with the results of the match, using "m"
Then you'd be right there with C-like languages where assignment is an
expression :)
while (tok = strtok(b
Cameron Simpson writes:
> if re_FUNKYPATTERN.match(test_string) as m:
> do stuff with the results of the match, using "m"
class memo:
def __call__(f, *args, **kw):
self.result = f(*args, **kw)
m = memo()
if result(re_FUNKYPATTERN.match, test_string):
do stuff wit
On 24Oct2012 16:54, Tim Chase wrote:
| On 10/24/12 16:34, Ian Kelly wrote:
| > On Wed, Oct 24, 2012 at 2:40 PM, Dan Loewenherz
wrote:
| >> So I'm sure a lot of you have run into the following pattern. I use it
| >> all the time and it always has felt a bit awkward due to the duplicate
| >> varia
Dan Loewenherz writes:
> VAR = EXPR
> while VAR:
> BLOCK
> VAR = EXPR
for VAR in iter(lambda: EXPR, None):
BLOCK
where the termination sentinel might be False or '' or whatever instead
of None. Of course if EXPR is a callable, there's no lambda.
> while EXPR as VAR:
> BLOCK
Thi
On 10/24/12 16:34, Ian Kelly wrote:
> On Wed, Oct 24, 2012 at 2:40 PM, Dan Loewenherz wrote:
>> So I'm sure a lot of you have run into the following pattern. I use it
>> all the time and it always has felt a bit awkward due to the duplicate
>> variable assignment.
>>
>> VAR = EXPR
>> while VAR:
>>
On Wed, Oct 24, 2012 at 2:40 PM, Dan Loewenherz wrote:
> So I'm sure a lot of you have run into the following pattern. I use it
> all the time and it always has felt a bit awkward due to the duplicate
> variable assignment.
>
> VAR = EXPR
> while VAR:
> BLOCK
> VAR = EXPR
The idiomatic wa
57 matches
Mail list logo
