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

Can someone explain to me why it was considered a bad thing that for-clauses leaked names in comprehensions, but it will be a good thing for inline assignments to leak names from them? -- Greg ___ Python-ideas mailing list Python-ideas@python.org https:

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] 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 guess Nick is opposed t

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 = pattern.match(the_s

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 in popular package

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 right, ... > > I suspect

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 in numpy (https://docs.scip

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] > > > The scope issues are logically independent

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 foo

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 work

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] 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 you use a reserved word > as

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 ab

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

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 work. The usual way of using "and" would no lo

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

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 el

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] 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] 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 what > with does

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 define

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: https://www.python.org/dev/peps/pep-0572/#alternative-spellings [...] I'd already looked at that part of the

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 question is now whether "giv

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

On Sun, May 13, 2018 at 4:30 PM Nick Malaguti wrote: > 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 so

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 prefe

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

[Guido] > ... > I should also mention that this was inspired from some messages where Tim > Peters berated the fashion of using "reserved words", waxing nostalgically > about the old days of Fortran (sorry, FORTRAN), which doesn't (didn't?) have > reserved words at all (nor significant whitespace,

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: >> > >> > Given a, b, c three sides of a triangle, then >

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 t

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 anyone still followi

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. w

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 = sqrt(s*(s-a)*(s-b)*(s-c)) > > > > where

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 *import

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] 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: > >> For example, we could allow keywords

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 some messages where

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

On Sun, May 13, 2018 at 11:20 AM Guido van Rossum wrote: > For example, we could allow keywords after 'def' and after a period, and > then the following would become legal: > ​Our modeling database overloads getattr/setattr (think SQLAlchemy) to allow us to access to database fields as if they w

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 "operator.n

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

[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 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 order, > e.g., > > > > in a bracketed expressi

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 understand it? >> > >

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+ (heads/bpo-33217-dirty:28

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 accept and implement som

[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] 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 there just? > > > >

Re: [Python-ideas] Fwd: Pattern Matching Syntax

Is some sense, yes, but await isn't part of the "async def" structure. await is just an independent statement, related to async def, yes, but independent. My proposal links match with case/else statements as a single flow control structure, and it writes them as such, like if/for/while/try. My pro

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)) > > > > > > > > With gi

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 t

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, rig

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 mailto:ncogh...@gmail.com>> wrote: >On 5 May 2018 at 13:36, Tim Peters mailto:tim.pet...@gmail.com>> wrote: >> If only one t

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 choic

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 work

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 de

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 nicely describes the rationale behind its rejection?

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 compre

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) > for b

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 as target > expr -> target >

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 pa

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 comprehension or gene

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 F'