Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

On 13 May 2018 at 14:19, Guido van Rossum wrote: > As anyone still following the inline assignment discussion knows, a > problem with designing new syntax is that it's hard to introduce new > keywords into the language, since all the nice words seem to be used as > method names

Re: [Python-ideas] "given" vs ":=" in list comprehensions

On 12 May 2018 at 20:34, Andre Roberge wrote: > 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

Re: [Python-ideas] Inline assignments using "given" clauses

[Steven D'Aprano ] >>> ... >>> average = 0 >>> smooth_signal = [(average := (1-decay)*average + decay*x) for x in signal] >>> assert average == smooth_signal[-1] [Tim] >> The scope issues are logically independent of assignment-expression >> spelling, but it's a pretty safe

Re: [Python-ideas] Inline assignments using "given" clauses

On 12 May 2018 at 14:13, 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] > > >

Re: [Python-ideas] Inline assignments using "given" clauses

On 11 May 2018 at 12:45, Tim Peters wrote: > [Nick Coghlan] > > I've been thinking about this problem, and I think for the If/elif/while > > cases it's actually possible to allow the "binding is the same as the > > condition" case to be simplified to: > > > > if command

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

Rob Cliffe via Python-ideas wrote: If you forbid redefining keywords, you remove the whole point of this proposal: I mean the keywords that are in the language as of now. There will never be a need to redefine those, since no current code uses them as names. -- Greg

Re: [Python-ideas] A comprehension scope issue in PEP 572

On 13 May 2018 at 20:00, Tim Peters wrote: > [Tim] > >> - If the target is not local to any function enclosing F, and is not > >> declared `global` in the block containing F, then the target is bound > >> in the block containing F. > > [also Tim] > > FYI, that's still not

Re: [Python-ideas] Inline assignments using "given" clauses

*Correction: Above code should read: outputs = [] state = initial_state for inp in inputs: out, state = my_update_func(inp, state) outputs.append(out) On Sun, May 13, 2018 at 11:21 AM, Peter O'Connor wrote: > target := expr > expr

Re: [Python-ideas] Inline assignments using "given" clauses

target := expr expr as target expr -> target target given target = expr let target = expr : target expr ; Although in general "target:=exp" seems the most palatable of these to me, there is one nice benefit to the "given" syntax: Suppose you have a comprehension wherein you want to

Re: [Python-ideas] "given" vs ":=" in list comprehensions

On Sun, May 13, 2018 at 1:34 AM, Andre Roberge wrote: > First example: single temporary assignment, done four different ways. > > 1) using := > > real_roots = [ (-b/(2*a) + (D:= sqrt( (b/(2*a))**2 - c/a), -b/(2*a) - D) > for a in range(10) >

Re: [Python-ideas] Inline assignments using "given" clauses

On 13.05.2018 11:23, Peter O'Connor wrote:  *Correction: Above code should read:     outputs = [] state = initial_state for inp in inputs: out, state = my_update_func(inp, state) outputs.append(out) Question still stands if this type of code needs compaction in the first place? List

Re: [Python-ideas] Inline assignments using "given" clauses

On 5/13/18 1:05 AM, Chris Angelico wrote: 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

Re: [Python-ideas] Inline assignments using "given" clauses

On Sat, May 12, 2018 at 07:36:33PM -0400, Juancarlo Añez wrote: > Python already uses "in", which is used in other languages to introduce > context. Fortunately, we don't have to come up with syntax that works with other languages, only Python. > The statement structure of "with...as" seems

Re: [Python-ideas] Inline assignments using "given" clauses

On Sun, May 13, 2018 at 10:53:50AM +1000, Cameron Simpson wrote: > For myself, I'm not a fan of a narrow scope. I'd be happy with an inline > assignment landing in the function scope (or whatever the current innermost > scope is). Like normal assignments. In how many other places does Python >

Re: [Python-ideas] Inline assignments using "given" clauses

On Sat, May 12, 2018 at 08:27:53PM -0400, 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

Re: [Python-ideas] Inline assignments using "given" clauses

Steven D'Aprano wrote: In my experience mathematicians put the given *before* the statement: Given a, b, c three sides of a triangle, then Area = sqrt(s*(s-a)*(s-b)*(s-c)) where s = (a + b + c)/2 is the semi-perimeter of the triangle. I agree, and "where" would be my first

Re: [Python-ideas] Inline assignments using "given" clauses

On 12/05/2018 23:52, Neil Girdhar wrote: 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

Re: [Python-ideas] A comprehension scope issue in PEP 572

On Sun, May 13, 2018 at 5:17 PM, Ethan Furman wrote: > On 05/12/2018 11:41 PM, Tim Peters wrote: >> >> [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

Re: [Python-ideas] A comprehension scope issue in PEP 572

On 05/12/2018 11:41 PM, Tim Peters wrote: [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

Re: [Python-ideas] A comprehension scope issue in PEP 572

[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)

[Python-ideas] Crazy idea: allow keywords as names in certain positions

As anyone still following the inline assignment discussion knows, a problem with designing new syntax is that it's hard to introduce new keywords into the language, since all the nice words seem to be used as method names in popular packages. (E.g. we can't use 'where' because there's numpy.where

Re: [Python-ideas] Inline assignments using "given" clauses

On 2018-05-13 04:23, Steven D'Aprano wrote: In my experience mathematicians put the given *before* the statement: Given a, b, c three sides of a triangle, then Area = sqrt(s*(s-a)*(s-b)*(s-c)) where s = (a + b + c)/2 is the semi-perimeter of the triangle. For the record, that

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

On Mon, May 14, 2018 at 4:19 AM, Guido van Rossum wrote: > The idea I had (not for the first time :-) is that in many syntactic > positions we could just treat keywords as names, and that would free up > these keywords. > ... > I should also mention that this was inspired from

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

On 2018-05-13 11:19, Guido van Rossum wrote: As anyone still following the inline assignment discussion knows, a problem with designing new syntax is that it's hard to introduce new keywords into the language, since all the nice words seem to be used as method names in popular packages. (E.g. we

Re: [Python-ideas] Inline assignments using "given" clauses

On Sun, May 13, 2018, 11:28 Brendan Barnwell wrote: > On 2018-05-13 04:23, Steven D'Aprano wrote: > > In my experience mathematicians put the given *before* the statement: > > > > Given a, b, c three sides of a triangle, then > > > > Area =

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

Apologies for my initial response. Looks like I failed to expand the initial email fully, which would have shown me the following :) > Of course this would still not help for names of functions that might be imported directly (do people write 'from numpy import where'?). -- I do think the

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

Care would have to be taken in the grammar to avoid syntactic ambiguity. For example: x = 1 def not(x): ... if not - x: # Is this 'not' the keyword or the identifier? not (-x), or not minus x? ... Nathan On Sun, May 13, 2018 at 2:20 PM Guido van Rossum wrote: > As

Re: [Python-ideas] Inline assignments using "given" clauses

On Sun, May 13, 2018 at 2:54 PM Matt Arcidy wrote: > > > On Sun, May 13, 2018, 11:28 Brendan Barnwell > wrote: > >> On 2018-05-13 04:23, Steven D'Aprano wrote: >> > In my experience mathematicians put the given *before* the statement: >> > >> >

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

I like it! The obvious question, though: How would "*from package import keyword*" be handled, if not simply by SyntaxError? Would *from package import keyword as keyword_* be allowed? In a similar vein, what would happen with stdlib functions like operator.not_? The thought of writing

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

Note that Javascript does something similar, in that reserved keywords are allowed in member access. var x = {if : 42}; console.log(x.if); Stephan 2018-05-13 20:42 GMT+02:00 Eric Fahlgren : > On Sun, May 13, 2018 at 11:20 AM Guido van Rossum > wrote:

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

On 13/05/2018 19:19, Guido van Rossum wrote: As anyone still following the inline assignment discussion knows, a problem with designing new syntax is that it's hard to introduce new keywords into the language, since all the nice words seem to be used as method names in popular packages. (E.g.

Re: [Python-ideas] Inline assignments using "given" clauses

On 2018-05-13 11:53, Matt Arcidy wrote: again, you want to use given, that's fine, but the math argument is wrong, as is the "it doesn't matter" argument, assuming the current neurological model for working memory continues to hold. Sorry, but that's nonsense. In the message you're replying

Re: [Python-ideas] Inline assignments using "given" clauses

> That's an excellent point. What's "special_gcd" and how does it differ > from normal gcd? How am I supposed to grok that just from reading the > code above? > > Do I have to dig into the source of special_gcd to understand it? > > One would usually define functions like special_gcd() inline,

Re: [Python-ideas] Inline assignments using "given" clauses

On Sun, May 13, 2018 at 12:10:08AM -0400, Neil Girdhar wrote: > > > 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: Actually, as you admitted, you can't, since

Re: [Python-ideas] Inline assignments using "given" clauses

On Sun, May 13, 2018 at 12:06 PM Steven D'Aprano wrote: > On Sat, May 12, 2018 at 08:06:02PM -0400, Neil Girdhar wrote: > > On Sat, May 12, 2018 at 2:28 PM Steven D'Aprano > wrote: > > > > > * there are no difficult mental questions about evaluation

Re: [Python-ideas] Inline assignments using "given" clauses

On Sat, May 12, 2018 at 08:06:02PM -0400, Neil Girdhar wrote: > On Sat, May 12, 2018 at 2:28 PM Steven D'Aprano wrote: > > > * there are no difficult mental questions about evaluation order, e.g., > > > in a bracketed expression having multiple assignments. > > > > Aren't

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Tim[ >> ... If a comprehension C is in class scope S, apparently the >> class locals are _not_ in C's environment. Since C doesn't >>> even have read access to S's locals, it seems to me bizarre >> that ":=" could _create_ a local in S. [Ethan Furman ] > Python 3.7.0b3+

Re: [Python-ideas] Inline assignments using "given" clauses

On Mon, May 14, 2018 at 12:20 AM, Juancarlo Añez wrote: > >> That's an excellent point. What's "special_gcd" and how does it differ >> from normal gcd? How am I supposed to grok that just from reading the >> code above? >> >> Do I have to dig into the source of special_gcd to

Re: [Python-ideas] Inline assignments using "given" clauses

On Sun, May 13, 2018 at 10:56 AM Steven D'Aprano wrote: > On Sun, May 13, 2018 at 12:10:08AM -0400, Neil Girdhar wrote: > > > > > 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)) >

[Python-ideas] keywords and backward compatibility

There seems to be a recurring theme of ideas wanting a new keyword but not being able to have one because of backwards compatibility. What if I have a way to ask for the new keyword? Would that make it easier to accept and implement some of the new ideas? The "given" keyword for example could be

Re: [Python-ideas] keywords and backward compatibility

On Mon, May 14, 2018 at 2:08 AM, Barry Scott wrote: > There seems to be a recurring theme of ideas wanting a new keyword > but not being able to have one because of backwards compatibility. > > What if I have a way to ask for the new keyword? Would that make it > easier to

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Tim] >> - If the target is not local to any function enclosing F, and is not >> declared `global` in the block containing F, then the target is bound >> in the block containing F. [also Tim] > FYI, that's still not right, ... > I suspect that the above should be reworded to the simpler: > > - If

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

On 13/05/2018 19:19, Guido van Rossum wrote: As anyone still following the inline assignment discussion knows, a problem with designing new syntax is that it's hard to introduce new keywords into the language, since all the nice words seem to be used as method names in popular packages.

Re: [Python-ideas] Inline assignments using "given" clauses

I think Peter tried to outline this earlier, but what he was laying out wasn't clear to me at first. There seem to be 4 variations when it comes to assignment expressions. I'm going to try to ignore exact keywords here since we can sort those out once we have settled on which variation we

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Tim] > ... > - If the target is not local to any function enclosing F, and is not > declared `global` in the block containing F, then the target is bound > in the block containing F. FYI, that's still not right, but I've been distracted by trying to convince myself that the manual actually

Re: [Python-ideas] Inline assignments using "given" clauses

On Mon, May 14, 2018 at 7:00 AM, Cameron Simpson wrote: > While I can see the issue, on a personal basis I'd accept it: import and > except don't do this and they happily use "as". In my mind the problem lies > with "with" (and is a perfectly acceptable inconsistency there, given

Re: [Python-ideas] Inline assignments using "given" clauses

On 14May2018 02:04, Steven D'Aprano wrote: "Outer parentheses" is a red herring. I should have written: (x + x) given x = 50 # this ought to return 100 x + (x given x = 50) # this ought to return 51 and now there are no outer parentheses to worry about. The

Re: [Python-ideas] Inline assignments using "given" clauses

On 13May2018 06:45, Eric V. Smith wrote: On 5/13/18 1:05 AM, Chris Angelico wrote: On Sun, May 13, 2018 at 2:58 PM, Cameron Simpson wrote: On 13May2018 14:23, Chris Angelico wrote:

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

Guido van Rossum wrote: Of course this would still not help for names of functions that might be imported directly (do people write 'from numpy import where'?). Maybe things could be rigged so that if you use a reserved word as a name in an import statement, it's treated as a name everywhere

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

Elias Tarhini wrote: The thought of writing "operator.not" is appealing, but being forced to use *that* (with *from operator import not* being non-allowable) may not be. Under the proposal I made in my last post, "from operator import not" would be fine -- you just wouldn't be able to use the

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

New Python versions already use backwards incompatible syntax, but it has to be a strict superset so the new parser still parses old code. If a new Python version introduced syntax that would break old code, it would still work, so long as the parser knew which syntax the file contained, and was

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

On Sun, May 13, 2018 at 9:00 PM, Greg Ewing wrote: > Guido van Rossum wrote: >> >> Of course this would still not help for names of functions that might be >> imported directly (do people write 'from numpy import where'?). > > > Maybe things could be rigged so that if

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

On 13/05/2018 19:19, Guido van Rossum wrote: As anyone still following the inline assignment discussion knows, a problem with designing new syntax is that it's hard to introduce new keywords into the language, since all the nice words seem to be used as method names in popular packages.

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

On 14/05/2018 02:28, Greg Ewing wrote: Rob Cliffe via Python-ideas wrote:     def and(x, y):     return ... #   and(1,2)   #  Oops, SyntaxError.  Oh, I know:     globals()['and'](1,2)    # Works! If the rule I proposed for "import" were extended to "def" then and(1,2) would

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

As long as any new syntax allowed us to still reference the occassional thing in the older libraries that used newly reserved names, it would not come up that often, and would avoid the biggest cost of a whole new version. If `foo` was a reserved word, then this could be allowed... import