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

To keep this a manageable length, I've trimmed vigourously. Apologies in advance if I've been too enthusiastic with the trimming :-) On Sat, Mar 24, 2018 at 05:09:54AM +1100, Chris Angelico wrote: > No, I haven't yet. Sounds like a new section is needed. Thing is, > there's a HUGE family of

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

FWIW, I thought another way which provides cache object library, it seems to just work in some cases. But it doesn't create statement local scope and might be difficult to read because looks ordinary expression doing magic. Chris, would you append the library to alternative proposal section?

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

On Sat, Mar 24, 2018 at 2:09 PM, Ethan Furman wrote: > On 03/23/2018 07:38 PM, Chris Angelico wrote: >> >> On Sat, Mar 24, 2018 at 3:58 AM, Guido van Rossum wrote: >>> >>> On Fri, Mar 23, 2018 at 9:34 AM, Christoph Groth wrote: > > But wouldn't it be a good alternative to

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

On 03/23/2018 07:38 PM, Chris Angelico wrote: On Sat, Mar 24, 2018 at 3:58 AM, Guido van Rossum wrote: On Fri, Mar 23, 2018 at 9:34 AM, Christoph Groth wrote: But wouldn't it be a good alternative to PEP 572 to *add* an assignment operator that is an expression to Python, and is distinct

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

On Sat, Mar 24, 2018 at 3:58 AM, Guido van Rossum wrote: > I also think it's fair to at least reconsider adding inline assignment, with > the "traditional" semantics (possibly with mandatory parentheses). This > would be easier to learn and understand for people who are familiar

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

On Fri, Mar 23, 2018 at 3:38 PM, Wes Turner wrote: > Here's a comparison table of os, os.path, shutil, pathlib, and path.py. > Darn, that's a big list -- exactly what we want to avoid :-( Though there are bunch of string methods in there that we can dump right off the

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

On Fri, Mar 23, 2018 at 1:47 PM, Jason Maldonis > > I can find the time I'll write the PEP (although I'd rather just > contribute to it). Figuring out what to include and how to change the > methods' APIs seems like one of the easier PEPs to write in terms of > required knowledge (I don't know

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

On 23 March 2018 at 22:22, Mike Miller wrote: > > On 2018-03-23 13:47, Jason Maldonis wrote: >> >> I’ve found it odd that there doesn’t even seem to be acknowledgment >> among >> longtime python users that the current hodgepodge is pretty >> dysfunctional >>

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

Here's a comparison table of os, os.path, shutil, pathlib, and path.py. The full version is at https://github.com/westurner/pyfilemods (README.rst) and at https://westurner.github.io/pyfilemods. I ran a few set intersections and went ahead and wrote a report to compare function/method signatures

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

On 2018-03-23 13:47, Jason Maldonis wrote: I’ve found it odd that there doesn’t even seem to be acknowledgment among longtime python users that the current hodgepodge is pretty dysfunctional for new users. I'll acknowledge it too, just that after X years it becomes second nature

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

> > I’ve found it odd that there doesn’t even seem to be acknowledgment among > longtime python users that the current hodgepodge is pretty dysfunctional > for new users. > I find this odd too. There have been a few comments along the lines of this being a problem for newbies or for *some* people

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

On Mar 23, 2018, at 7:26 AM, Steve Dower wrote: I had a colleague complaining to me the other day about having to search multiple packages for the right function to move a file (implying: with the same semantics as drag-drop). Thanks Steve — I know there isn’t any kind

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

On Sat, Mar 24, 2018 at 2:00 AM, Steven D'Aprano wrote: > On Fri, Mar 23, 2018 at 09:01:01PM +1100, Chris Angelico wrote: > >> PEP: 572 >> Title: Syntax for Statement-Local Name Bindings > [...] >> Abstract >> >> >> Programming is all about reusing code rather than

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

I also think it's fair to at least reconsider adding inline assignment, with the "traditional" semantics (possibly with mandatory parentheses). This would be easier to learn and understand for people who are familiar with it from other languages (C++, Java, JavaScript). On Fri, Mar 23, 2018 at

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

Disclaimer: I skimmed/searched through the PEP 572 threads (or should I say "literature"?) and did not find a discussion of the following point. If it has been discussed already, I'd be glad to be pointed to it. I am aware that Python, in contrast to C-like languages, has chosen not to treat

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

On Fri, Mar 23, 2018 at 09:01:01PM +1100, Chris Angelico wrote: > PEP: 572 > Title: Syntax for Statement-Local Name Bindings [...] > Abstract > > > Programming is all about reusing code rather than duplicating it. I don't think that editorial comment belongs here, or at least, it is

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

I had a colleague complaining to me the other day about having to search multiple packages for the right function to move a file (implying: with the same semantics as drag-drop). If there isn’t a pathtools library on PyPI yet, this would certainly be valuable for newer developers. My view on

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

On 23/03/18 10:01, Chris Angelico wrote: Apologies for letting this languish; life has an annoying habit of getting in the way now and then. Feedback from the previous rounds has been incorporated. From here, the most important concern and question is: Is there any other syntax or related

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

On Fri, Mar 23, 2018 at 9:38 PM, Paul Moore wrote: > On 23 March 2018 at 10:01, Chris Angelico wrote: >> # ... except when function bodies are involved... >> if (input("> ") as cmd): >> def run_cmd(): >> print("Running command",

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

On 23 March 2018 at 10:01, Chris Angelico wrote: > # ... except when function bodies are involved... > if (input("> ") as cmd): > def run_cmd(): > print("Running command", cmd) # NameError > > # ... but function *headers* are executed immediately

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

On Fri, 23 Mar 2018 07:25:33 +0100 Jeroen Demeyer wrote: > On 2018-03-23 00:36, Antoine Pitrou wrote: > > It does make sense, since the proposal sounds ambitious (and perhaps > > impossible without breaking compatibility). > > Well, *some* breakage of backwards

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

Apologies for letting this languish; life has an annoying habit of getting in the way now and then. Feedback from the previous rounds has been incorporated. From here, the most important concern and question is: Is there any other syntax or related proposal that ought to be mentioned here? If

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

On 2018-03-23 00:36, Antoine Pitrou wrote: It does make sense, since the proposal sounds ambitious (and perhaps impossible without breaking compatibility). Well, *some* breakage of backwards compatibility will be unavoidable. My plan (just a plan for now!) is to preserve backwards