Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Mon, Mar 26, 2018 at 3:34 PM, Guido van Rossum wrote: > On Sun, Mar 25, 2018 at 6:29 PM, Chris Angelico wrote: >> >> On Mon, Mar 26, 2018 at 12:24 PM, Guido van Rossum >> wrote: >> > The scope question is far from easy though. I find it

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Sun, Mar 25, 2018 at 6:29 PM, Chris Angelico wrote: > On Mon, Mar 26, 2018 at 12:24 PM, Guido van Rossum > wrote: > > The scope question is far from easy though. I find it particularly > grating > > that an inline assignment occurs in an 'if' statement,

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

[Tim] >> I wonder whether Guido remembers this ;-) In the very, very, VERY >> early days, Python didn't have "==". Plain single "=" was used for >> both assignment and equality testing. [Guido] > Wow, I did not remember this. In fact I had to track down the 0.9.1 release > that's somewhere on

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Mon, Mar 26, 2018 at 12:24 PM, Guido van Rossum wrote: > I gotta say I'm warming up to := in preference over 'as', *if* we're going > to do this at all (not a foregone conclusion at all). So am I, primarily due to its lack of syntactic ambiguities. > The scope question is

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Sun, Mar 25, 2018 at 4:40 PM, Tim Peters wrote: > [Chris Angelico ] > > ... > > Not qualitative, but anecdotal: I do sometimes have to remind my > > JavaScript students to check whether they've typed enough equals > > signs. And that's in a language

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Mon, Mar 26, 2018 at 10:40 AM, Tim Peters wrote: > Here's one that baffled an office full of MIT grads for half a day > before I noticed the real problem: > > assert(n=2); > > You can fill in the rest of the story yourself - but you'll miss the > full extent of the

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

[Chris Angelico ] > ... > Not qualitative, but anecdotal: I do sometimes have to remind my > JavaScript students to check whether they've typed enough equals > signs. And that's in a language where the normal comparison operator > is ===. It's *still* not uncommon to see a

Re: [Python-ideas] New PEP proposal -- Pathlib Module Should Contain All File Operations -- version 2

On Sat, Mar 17, 2018 at 10:42 AM, George Fischhof wrote: > > All functions from os module accept path-like objects, > and none of the shutil functions. shutil indirectly supports __fspath__ paths via os and os.path. One exception is shutil.disk_usage() on Windows, which only

Re: [Python-ideas] New PEP proposal -- Pathlib Module ShouldContain All File Operations -- version 2

Hi folks, according to comments it seems, it would better to propose a new module. I start to work out a new proposal. I created a BitBucket repo to be able to work together with folks who want help ;-) the repo address is: https://bitbucket.org/GeorgeFischhof/pep_for_filesystem_operations.git

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On 03/24/2018 09:24 PM, Nick Coghlan wrote: No, the fact that the expression defining the outermost iterable gets evaluated in the outer scope is behaviour that's explicitly tested for in the regression test suite. The language reference spells out that this is intentional for generator

Re: [Python-ideas] Fixing class scope brainstorm

On Sun, Mar 25, 2018 at 5:51 PM Guido van Rossum wrote: > In the PEP 572 threads there's some grumbling about class scopes. > > Here's a random brainstorm. How about we change the scoping rules so that > only functions defined with 'def' (or inside one of those) cannot see the

[Python-ideas] Fixing class scope brainstorm

In the PEP 572 threads there's some grumbling about class scopes. Here's a random brainstorm. How about we change the scoping rules so that only functions defined with 'def' (or inside one of those) cannot see the class scope, and comprehensions and lambdas treat the class scope as an outer scope

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Sun, Mar 25, 2018 at 12:18 AM, Chris Angelico wrote: > [...] > Agreed. I'm currently thinking that I need to do what several people > have suggested and break this into two completely separate PEPs: > > 1) Sublocal namespacing > 2) Assignment expressions > > Sublocal names

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

: On 25 March 2018 at 02:34, Guido van Rossum wrote: > [...] I think we need a short, crisp name for the new variable type. Disposables? -[]z. ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On 25 March 2018 at 22:44, Christoph Groth wrote: > I think that it's a helpful guideline to imagine what the ideal behavior > should be if we were not constrained by backwards compatibility, and > then try to follow it. In the case at hand, we all seem to agree that >

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

Chris Angelico wrote: > On Sun, Mar 25, 2018 at 8:31 PM, Christoph Groth > wrote: > > That's indeed a bit strange, and I would consider it somewhat of a wart > > of the language. But as far as I can tell remaining compatible with the > > above behavior does not force us

Re: [Python-ideas] PEP proposal: unifying function/method classes

On Sun, Mar 25, 2018 at 9:53 PM, Steven D'Aprano wrote: > On Sun, Mar 25, 2018 at 06:52:09PM +1100, Chris Angelico wrote: > >> If people are checking "if type(x) is types.FunctionType", they're >> doing it wrong. > > That depends on what "it" is that they're doing. > > If

Re: [Python-ideas] PEP proposal: unifying function/method classes

On Sun, Mar 25, 2018 at 06:52:09PM +1100, Chris Angelico wrote: > If people are checking "if type(x) is types.FunctionType", they're > doing it wrong. That depends on what "it" is that they're doing. If they want a callable, then they're doing it wrong. If they want a function regardless of

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Sun, Mar 25, 2018 at 05:00:37PM +1000, Nick Coghlan wrote: > Given the existing namespace stack of > builtin<-global<-nonlocal<-local, one potential short name would be > "sublocal", to indicate that these references are even more local than > locals (they're *so* local, they don't even

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On Sun, Mar 25, 2018 at 8:31 PM, Christoph Groth wrote: > That's indeed a bit strange, and I would consider it somewhat of a wart > of the language. But as far as I can tell remaining compatible with the > above behavior does not force us to leak assignments from the

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

Nick Coghlan wrote: > It would also result in two different ways to handle traditional > assignments: > > x = expr > x := expr > > Perhaps ":=" could be explicitly restricted to only single names on > the LHS, without any of the clever unpacking features of full > assignment statements?

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

Nick Coghlan wrote: > On 24 March 2018 at 23:29, Christoph Groth wrote: > > x = [n * m for n in range(4) for m in range(5)] > > > > be equally well equivalent to > > > > def (): > > ret = [] > > for n in range(4): > > for m in range(5): > >

[Python-ideas] Inplace assignment for "boolean or"?

Hi, I find a common idiom in Python is: x = x or 'some other value' This is highly reminiscent of the problem inplace operators solve. Would it be a good idea to consider an inplace operator for this, perhaps: x or= 'some other value' ? Thanks, Cammil

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 25 March 2018 at 17:18, Chris Angelico wrote: > Agreed. I'm currently thinking that I need to do what several people > have suggested and break this into two completely separate PEPs: > > 1) Sublocal namespacing > 2) Assignment expressions > > Sublocal names can be used in a

Re: [Python-ideas] PEP proposal: unifying function/method classes

On Sun, Mar 25, 2018 at 6:22 PM, Stefan Behnel wrote: > Jeroen Demeyer schrieb am 24.03.2018 um 22:38: >> On 2018-03-24 09:09, Nick Coghlan wrote: >>> If it was just about introspection, then we could define a new protocol >>> method or attribute, update the inspect module to

Re: [Python-ideas] PEP proposal: unifying function/method classes

Jeroen Demeyer schrieb am 24.03.2018 um 22:38: > On 2018-03-24 09:09, Nick Coghlan wrote: >> If it was just about introspection, then we could define a new protocol >> method or attribute, update the inspect module to respect it, and call >> it done. > > True. In fact, I got a long way by just

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Sun, Mar 25, 2018 at 4:34 PM, Guido van Rossum wrote: > This is a super complex topic. There are at least three separate levels of > critique possible, and all are important. Thank you for your detailed post. I'll respond to some of it here, and some more generally below. >

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 25 March 2018 at 15:34, Guido van Rossum wrote: > > This is a super complex topic. There are at least three separate levels of > critique possible, and all are important. > > First there is the clarity of the PEP. Steven D'Aprano has given you great > detailed feedback here