On Sat, May 12, 2018 at 02:37:20AM +0100, Rob Cliffe via Python-ideas wrote:
> Yeah, well, I'm totally lost. Even after trying out this code, and
> refactoring it once if not twice, I didn't understand it. I don't know
> what point you're trying to prove, but you seem to have comprehensively
On Fri, May 11, 2018, 17:04 Tim Peters wrote:
> [Matt Arcidy]
> >> Note Tim came up with a real metric:
> >> 2 * count(":=")/len(statement).
> >> It's objective. it's just unclear if a higher score is better or worse.
> >> However, one could say "a Tim of .3 is considered too high" as a
> guidel
Concerning my previous email,
Yes, my mistake. I'd forgotten (ironically) that the whole point is that
it's an expression itself.
So
> while (value:=get_next_pool_item()).in_use:
>print(value.refcount())
would be the appropriate analogue.
Consequently, my example is invalid. A better example
There's a lot of things in Brendan's email which I disagree with but
will skip to avoid dragging this out even further. But there's one point
in particular which I think is important to comment on.
On Thu, May 10, 2018 at 11:23:00AM -0700, Brendan Barnwell wrote:
> One of the great things about
[Tim]
> ...
> But an assignment expression target name always has the
> same scope within a comprehension. [which is a consequence
> of the rules - not a rule of its own]
Something related to ponder: what's the meaning of the following
_without_ the proposed scope change? So the Golden Binding
2018-05-12 11:36 GMT+03:00 Angus Hollands :
> Concerning my previous email,
>
> Yes, my mistake. I'd forgotten (ironically) that the whole point is that
> it's an expression itself.
>
> So
> > while (value:=get_next_pool_item()).in_use:
> >print(value.refcount())
> would be the appropriate ana
Great! Also emailed you with logistics.
On Sat, May 12, 2018, 01:43 Jelle Zijlstra wrote:
> 2018-05-11 22:01 GMT-04:00 Robert Roskam :
>
>> Hey Steven,
>>
>> I'm also at PyCon. Shall we take this off list and attempt to meet up and
>> discuss?
>>
>> I'm also at PyCon and interested in meeting ab
I find it weird for case statements to be "inside" match statements.
There's isn't a statement "group" that works this way right now, AFAIK.
This would also be weird:
match X:
case Y:
...
I thought a form based on try would make more coherent:
match:
suite
case x:
suite1
else:
suite
I love given compared with := mainly because
Simpler is better than complex:
* given breaks a complex statement into two simpler ones, which is putting
people off in the simple examples shown here (some people are annoyed by
the extra characters). However, when given is used in a list comprehen
On Sun, May 06, 2018 at 02:00:35AM +1000, Nick Coghlan wrote:
> 3. You can stick in an explicit "if True" if you don't need the given
> variable in the filter condition
>
> [(fx**2, fx**3) for x in xs if True given fx = f(x)]
o_O
I'm replying to an email which is a week old. I haven't seen
On Sat, May 12, 2018 at 08:16:07AM -0700, Neil Girdhar wrote:
> I love given compared with := mainly because
>
> Simpler is better than complex:
> * given breaks a complex statement into two simpler ones,
(Foreshadowing: this argument applies to augmented assignment. See
below.)
I don't see ho
In some sense async and await are like this group you describe, the keyword
"await" doesn't have meaning outside a function annotated with "async".
The issue I'd have with your proposal is that it requires the "suite" to be
an expression-based multi-line statement, ie. where the last statement
Just clarifying a fine point here:
[Steven D'Aprano ]
> ...
> average = 0
> smooth_signal = [(average := (1-decay)*average + decay*x) for x in signal]
> assert average == smooth_signal[-1]
>
> I'm not even sure if "given" will support this. Nick is arguing strongly
> that bound targets should be l
Minor gripe: The ability to *articulate* Python is not the same as the
ability to *type Python verbally*.
Nobody articulates `def area(width, height): return width * height` as *def
area, open paren, width, comma, space, height, closed paren..*.
They would say something like *def area as a functi
Part 2.
On Sat, May 12, 2018 at 08:16:07AM -0700, Neil Girdhar wrote:
> I love given compared with := mainly because
[...]
> * Python has a reputation for being working pseudocode, and given reads
> like pseudocode. := needs to be deciphered by comparison especially in the
> complicated cases
David Mertz writes:
> Only the BDFL has a vote with non-zero weight.
"Infinitesimal" != "zero".
Pedantically yours,
___
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://py
On Sun, May 13, 2018 at 6:37 AM, Stephen J. Turnbull
wrote:
> David Mertz writes:
>
> > Only the BDFL has a vote with non-zero weight.
>
> "Infinitesimal" != "zero".
>
> Pedantically yours,
Correct, infinitesimal is not zero. This does not contradict David's statement.
ChrisA
__
On 2018-05-12 18:24, Steven D'Aprano wrote:
> On Sat, May 12, 2018 at 08:16:07AM -0700, Neil Girdhar wrote:
>> I love given compared with := mainly because
>>
>> Simpler is better than complex: * given breaks a complex statement
>> into two simpler ones,
>
> [snip]
>
> Nick's syntax is *much mo
On Sun, May 13, 2018 at 7:33 AM, Ed Kellett wrote:
> On 2018-05-12 19:27, Steven D'Aprano wrote:
>> What you probably want is the second version:
>>
>> (a := c.d()).b(a)
>>
>> which of course looks like utter crap. It might look better if we
>> use at least half-way sensible variable names and a m
On 2018-05-12 22:42, Chris Angelico wrote:
> It's documented. It's guaranteed not to change.
>
> https://docs.python.org/3/reference/expressions.html#evaluation-order
Thanks. That's good to know, though I continue to hope nobody makes a
habit of writing code that depends on it.
signature.asc
D
On 06May2018 02:00, Nick Coghlan wrote:
On 5 May 2018 at 13:36, Tim Peters wrote:
If only one trailing "given" clause can be given per `if` test
expression, presumably I couldn't do that without trickery.
I was actually thinking that if we did want to allow multiple assignments,
and we limit
On 13May2018 07:07, Cameron Simpson wrote:
Similar to import statements, optional parentheses could be included in the
grammar, allowing the name bindings to be split across multiple lines:
if diff and g > 1 given (
diff = x - x_base,
g = gcd(diff, n),
):
return g
I'm we
Just showing an example of "by hand" code emulating nesting of
comprehensions, with a highly dubious rebinding, in the inner
comprehension, of an outer comprehension's local for-target.
list(i + sum((i := i+1) + i for j in range(i))
for i in range(5))
I don't believe I have compelling use c
Ah, fudge - I pasted in the wrong "high-level" code. Sorry! The code
that's actually being emulated is not
> list(i + sum((i := i+1) + i for j in range(i))
> for i in range(5))
but
list(i + sum((i := i+1) for j in range(i)) + i
for i in range(5))
> ...
I have piles of th
> My main point here is that "with" works as well as "given" in this form
> from an English prose point of view.
>
+1 for "with...as", -1 for ":="
About affecting existing contexts, it seems that "with..as" would create a
new context just for the expression, and the control statement it is
embedd
On Sat, May 12, 2018 at 5:54 PM Cameron Simpson wrote:
> On 06May2018 02:00, Nick Coghlan wrote:
> >On 5 May 2018 at 13:36, Tim Peters wrote:
> >> If only one trailing "given" clause can be given per `if` test
> >> expression, presumably I couldn't do that without trickery.
> >
> >I was actuall
On Sun, May 13, 2018 at 8:47 AM, Juancarlo Añez wrote:
>
>> My main point here is that "with" works as well as "given" in this form
>> from an English prose point of view.
>
>
> +1 for "with...as", -1 for ":="
>
> About affecting existing contexts, it seems that "with..as" would create a
> new con
> LOOK similar, but are subtly different. The current 'with' statement
> doesn't create a subscope; the only "context" it creates is regarding
> the resource represented by the context manager. For instance, opening
> a file in a 'with' block will close the file at the end of the block -
> but you
On Sat, May 12, 2018 at 1:25 PM Steven D'Aprano wrote:
> On Sat, May 12, 2018 at 08:16:07AM -0700, Neil Girdhar wrote:
>
> > I love given compared with := mainly because
> >
> > Simpler is better than complex:
> > * given breaks a complex statement into two simpler ones,
>
> (Foreshadowing: this
On 2018-05-12 22:07, Cameron Simpson wrote:
On 06May2018 02:00, Nick Coghlan wrote:
On 5 May 2018 at 13:36, Tim Peters wrote:
If only one trailing "given" clause can be given per `if` test
expression, presumably I couldn't do that without trickery.
I was actually thinking that if we did wan
On Sat, May 12, 2018 at 2:28 PM Steven D'Aprano wrote:
> Part 2.
>
> On Sat, May 12, 2018 at 08:16:07AM -0700, Neil Girdhar wrote:
> > I love given compared with := mainly because
>
> [...]
> > * Python has a reputation for being working pseudocode, and given reads
> > like pseudocode. := needs
[attributions lost - sorry, but I can't get 'em back]
...
>>> Similar to import statements, optional parentheses could be included in
>>> the
>>> grammar, allowing the name bindings to be split across multiple lines:
>>>
>>>if diff and g > 1 given (
>>>diff = x - x_base,
>>>g =
A new thread just to suggest taking the discussion about PEP572 well beyond
python-ideas (PyConn is good for that).
The least anyone should want is a language change that immediately gets
tagged on the networks as "don't use", or "use only for...", etc.
To be honest, I'll likely be on the "don't
> if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
> return g
>
>
I don't see the advantage in that succinctness:
g = special_gcd(x - x_base, n)
if g:
return g
The code bases I work on constantly move towards having the next guy grok
what's going on just by reading the cod
Sorry for chiming in so late; I was lurking using google groups and had to
subscribe to post - hence this new thread.
I gather that *where* has been discarded as a possible new keywords given
its use as a function in numpy (
https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.where.
On Sun, May 13, 2018 at 10:06 AM, Neil Girdhar wrote:
>
>> Take your choice of which you want:
>>
>> (spam if (mylist := expr) else eggs) + mylist
>> ((mylist := expr) if condition else eggs) + mylist
>> (spam if condition else (mylist := expr)) + mylist
>>
>> Of course, in the last two cases, you
On Sun, May 13, 2018 at 10:27 AM, Juancarlo Añez wrote:
>
>> if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
>> return g
>>
>
> I don't see the advantage in that succinctness:
>
> g = special_gcd(x - x_base, n)
>
> if g:
>
> return g
>
>
> The code bases I work on constantly
On Sun, May 13, 2018 at 10:34 AM, Andre Roberge wrote:
> Second example: multiple assignments.
>
> When we have multiple temporary assignments, the situation can be more
> complicated. In the following series of examples, I will start in reverse
> order compared to above.
>
> 5) using *where* bef
On 13May2018 08:55, Chris Angelico wrote:
On Sun, May 13, 2018 at 8:47 AM, Juancarlo Añez wrote:
My main point here is that "with" works as well as "given" in this form
from an English prose point of view.
+1 for "with...as", -1 for ":="
About affecting existing contexts, it seems that "
On 13May2018 00:51, MRAB wrote:
On 2018-05-12 22:07, Cameron Simpson wrote:
On 06May2018 02:00, Nick Coghlan wrote:
Similar to import statements, optional parentheses could be included in the
grammar, allowing the name bindings to be split across multiple lines:
if diff and g > 1 given (
[Nick]
>> That's all well and good, but it is *completely insufficient for the
>> language specification*.
> I haven't been trying to write reference docs here, but so far as
> supplying a rigorous specification goes, I maintain the above gets
> "pretty close". It needs more words, and certainly
On Sat, May 12, 2018 at 01:13:05PM -0500, Tim Peters wrote:
> Just clarifying a fine point here:
>
> [Steven D'Aprano ]
> > ...
> > average = 0
> > smooth_signal = [(average := (1-decay)*average + decay*x) for x in signal]
> > assert average == smooth_signal[-1]
> >
> > I'm not even sure if "given
Are votes cast in Edwin Hewitt's Hyperreals? I had thought python-ideas
voted in the domain R rather than *R. :-)
On Sat, May 12, 2018, 5:20 PM Stephen J. Turnbull <
[email protected]> wrote:
> David Mertz writes:
>
> > Only the BDFL has a vote with non-zero weight.
>
> "Infini
Another benefit of given compared with := that I just thought of is this.
Suppose you have a generator like
(expression(f(x), y, z)
for x in xs
for y in ys(x)
for z in zs(y))
With given notation you can optimize:
(expression(f_x, y, z)
for x in xs
given f_x = f(x)
for y in ys(x)
for z in
On Sat, May 12, 2018 at 11:04:45PM -0400, Neil Girdhar wrote:
> Another benefit of given compared with := that I just thought of is this.
> Suppose you have a generator like
>
> (expression(f(x), y, z)
> for x in xs
> for y in ys(x)
> for z in zs(y))
>
> With given notation you can optimize:
>
On Sat, May 12, 2018 at 11:48 PM Steven D'Aprano
wrote:
> On Sat, May 12, 2018 at 11:04:45PM -0400, Neil Girdhar wrote:
> > Another benefit of given compared with := that I just thought of is this.
> > Suppose you have a generator like
> >
> > (expression(f(x), y, z)
> > for x in xs
> > for y i
On 11May2018 11:40, Jacco van Dorp wrote:
[...] That all said, I would still prefer:
if re.match(stuff) as m:
which is exactly equal to the := in line length and parallels with.
While that may -technically- be a different beast.
Yeah, this is my favorite also. Has the same feel and ordering
On 11May2018 11:45, Tim Peters wrote:
[Gustavo Carneiro]
IMHO, all these toy examples don't translate well to the real world
because they tend to use very short variable names while in real world [good
written code] tends to select longer more descriptive variable names.
[Greg Ewing]
I don't
On Sun, May 13, 2018 at 2:05 PM, Cameron Simpson wrote:
> On 11May2018 11:40, Jacco van Dorp wrote:
>>
>> [...] That all said, I would still prefer:
>>
>> if re.match(stuff) as m:
>>
>> which is exactly equal to the := in line length and parallels with.
>> While that may -technically- be a differ
On 13May2018 14:23, Chris Angelico wrote:
On Sun, May 13, 2018 at 2:05 PM, Cameron Simpson wrote:
Could someone point me to a post which nicely describes the rationale behind
its rejection? I'm sure there's one in the many in this discussion but I've
not found it yet.
https://www.python.org
On Sun, May 13, 2018 at 2:58 PM, Cameron Simpson wrote:
> On 13May2018 14:23, Chris Angelico wrote:
>>
>> On Sun, May 13, 2018 at 2:05 PM, Cameron Simpson wrote:
>>>
>>> Could someone point me to a post which nicely describes the rationale
>>> behind
>>> its rejection? I'm sure there's one in t
[Tim, suggests changes to the Reference Manual's 4.2.1]
> """
> An assignment expression binds the target, except in a function F
> synthesized to implement a list comprehension or generator expression
> (see XXX). In the latter case, if the target is not in F's
> environment (see section 4.2.2) ,
52 matches
Mail list logo
