Re: [Python-Dev] PEP 394: Allow the `python` command to not be installed (and other minor edits)

On 28 April 2018 at 12:34, Guido van Rossum wrote: > Um, the PEP has "Unix-Like Systems" in its heading, so discussing the > Windows situation seems out of scope to me. > Sorry, I conflated two issues there - while PEP 394 itself is specific to Unix-like systems, my thoughts

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

Hi, On 26 April 2018 at 07:50, Raymond Hettinger wrote: >> [Raymond Hettinger ] >>> After re-reading all the proposed code samples, I believe that >>> adopting the PEP will make the language harder to teach to people >>> who are not

Re: [Python-Dev] PEP 394: Allow the `python` command to not be installed (and other minor edits)

On Fri, Apr 27, 2018 at 7:23 PM, Nick Coghlan wrote: > The key missing piece for doing that would be to define how we'd want a `py` > launcher to work on *nix systems, and then provide that as part of CPython > 3.8+ (and potentially backport it to a 3.7x maintenance release).

Re: [Python-Dev] PEP 394: Allow the `python` command to not be installed (and other minor edits)

Um, the PEP has "Unix-Like Systems" in its heading, so discussing the Windows situation seems out of scope to me. You're one of its authors, so if you really want to keep the paragraph about the anticipated unified future we can keep it (though preferably this should be discussed in the issue,

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

Victor Stinner wrote: In my opinion, the largest failure of Python 3 is that we failed to provide a smooth and *slow* transition from Python 2 and Python 3. Although for some things, such as handling of non-ascii text, it's hard to see how a smooth transition *could* have been achieved. Is it

Re: [Python-Dev] PEP 394: Allow the `python` command to not be installed (and other minor edits)

On 28 April 2018 at 01:37, Petr Viktorin wrote: > Hello, > After discussion on the [Pull Request], my update to PEP 394 changed scope > somewhat. The new major changes are: > > - The `python` command may not exist at all in some cases (see the PEP for > details) > - The

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On 4/27/2018 2:11 PM, Tim Peters wrote: That's easy: any time there's a long thread to which Guido has contributed at least twice, it will be seen as a Golden Opportunity to re-litigate every decision that's ever been made;-) You're getting pretty good at that QOTD thing, Tim :)

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

It's certainly a contrived example. Actual code with such a mistake is generally far more subtle. The mistake is that it's assigning a value within a clause of a conditional that won't be evaluated. Oh well. I'll suffer the then worsened zig-zaggy eye movements in code reviews caused by defining

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Tres Seaver ] > FWIW, Ned Batchelder's 'coverage.py' does a good job with branch coverage. > I haven't seen anything in this discussion which indicates that binding > expressions will change that at all. I don't think you missed anything relevant either ;-) Binding

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

Wes, sorry, but I really don't follow what you're saying. For example, [Wes Turner ] > Do not do this: > > x = 2 > if (x == 3) or (x := 3): >print(x) > > What do we call that mistake? It displays 3 - while it appears to be silly code, there's nothing about it that's

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On 04/27/2018 05:11 PM, Tim Peters wrote: > In this specific case, line-oriented coverage tools have missed > accounting for all possible code paths since day #1; e.g., > > x = f() or g() > > You don't need to reply to messages so obviously irrelevant to the PEP > unless you want to. It's

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Sat, Apr 28, 2018 at 7:11 AM, Tim Peters wrote: > [Chris Angelico ] >> ... >> I don't understand why people bring up all these arguments that have >> absolutely nothing to do with the proposal at hand. None of this has >> in any way changed. > > That's

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Friday, April 27, 2018, Tim Peters wrote: > [Chris Angelico ] > > ... > > I don't understand why people bring up all these arguments that have > > absolutely nothing to do with the proposal at hand. None of this has > > in any way changed. > > That's

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Chris Angelico ] > ... > I don't understand why people bring up all these arguments that have > absolutely nothing to do with the proposal at hand. None of this has > in any way changed. That's easy: any time there's a long thread to which Guido has contributed at least twice,

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

On 04/27/2018 04:34 AM, Serhiy Storchaka wrote: 27.04.18 13:25, Nick Coghlan пише: and PEP 3099 (explicitly rejected ideas that also didn't get their own PEPs). "There will be no alternative binding operators such as :=." Which is why changing that requires a PEP now. -- ~Ethan~

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Sat, Apr 28, 2018 at 6:24 AM, Wes Turner wrote: > > > On Friday, April 27, 2018, Chris Angelico wrote: >> >> On Sat, Apr 28, 2018 at 6:06 AM, Wes Turner wrote: >> > >> > >> > On Friday, April 27, 2018, Chris Angelico

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Friday, April 27, 2018, Chris Angelico wrote: > On Sat, Apr 28, 2018 at 6:06 AM, Wes Turner wrote: > > > > > > On Friday, April 27, 2018, Chris Angelico wrote: > >> > >> On Fri, Apr 27, 2018 at 8:18 PM, Wes Turner

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Sat, Apr 28, 2018 at 6:06 AM, Wes Turner wrote: > > > On Friday, April 27, 2018, Chris Angelico wrote: >> >> On Fri, Apr 27, 2018 at 8:18 PM, Wes Turner wrote: >> > IDK, I could just be resistant to change, but this seems like

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Friday, April 27, 2018, Chris Angelico wrote: > On Fri, Apr 27, 2018 at 8:18 PM, Wes Turner wrote: > > IDK, I could just be resistant to change, but this seems like something > that > > will decrease readability -- and slow down code review -- without

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Lukasz] >> > And that *is* a thing that you will have to explain to newbies when >> > they encounter it for the first time. [Tim] >> Sure. That doesn't frighten me, though. It's easy to explain what it >> does - although it may be hard to explain when it's _desirable_ to use >> it. [Chris

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, Apr 26, 2018 at 1:33 PM, Tim Peters wrote: > And that *is* a thing that you will have to explain to newbies when they > encounter > > it for the first time. > > Sure. That doesn't frighten me, though. It's easy to explain what it > does - although it may be hard

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

On Tue, Apr 24, 2018 at 2:21 AM, Victor Stinner wrote: > Even if the C language allows assignments in if, I avoid them, because > I regularly have to debug my own code in gdb ;-) > I personally haven't written a lot of C, so have no personal experience, but if this is at

[Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (2018-04-20 - 2018-04-27) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open6615 (+28) closed 38510 (+26) total 45125 (+54) Open issues

[Python-Dev] quoted text not being marking correctly [was PEP 572 really the most effective way to solve the problems it's targeting?]

On 04/27/2018 05:35 AM, Ryan Gonzalez wrote: [snip] Ryan, the quoted text in your emails is not being marked as such, meaning that the entire email appears to be from you. This makes it really difficult to pick out your responses. I would really appreciate it of you could figure out why

[Python-Dev] PEP 394: Allow the `python` command to not be installed (and other minor edits)

Hello, After discussion on the [Pull Request], my update to PEP 394 changed scope somewhat. The new major changes are: - The `python` command may not exist at all in some cases (see the PEP for details) - The paragraph about the anticipated future where python points to Python 3 is removed.

Re: [Python-Dev] PEP 394 update proposal: Allow changing the `python` command in some cases

On 04/27/18 02:03, Ben Finney wrote: Ben Finney writes: Petr Viktorin writes: […] we feel that the only way to *enforce* that guidelines is to provide environments where the `python` command does not work (unless explicitly installed).

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

On Thu, Apr 26, 2018 at 10:25 AM, Eric Snow wrote: > In pondering our approach to future Python major releases, I found > myself considering the experience we've had with Python 3. The whole > Py3k effort predates my involvement in the community so I missed a > bunch

Re: [Python-Dev] Reserve ':=' for type-inferred variable initialization (was PEP 572)

On 4/27/2018 8:28 AM, Steven D'Aprano wrote: On Fri, Apr 27, 2018 at 08:13:20AM +0200, Andrea Griffini wrote: Now we got standard library features requiring type annotation We do? Did I miss them? Which std lib features are you referring to? (That's not a rhetorical question -- maybe I have

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Fri, Apr 27, 2018 at 8:18 PM, Wes Turner wrote: > IDK, I could just be resistant to change, but this seems like something that > will decrease readability -- and slow down code review -- without any real > performance gain. So, while this would be useful for golfed-down

Re: [Python-Dev] Reserve ':=' for type-inferred variable initialization (was PEP 572)

On 27 April 2018 at 22:28, Steven D'Aprano wrote: > On Fri, Apr 27, 2018 at 08:13:20AM +0200, Andrea Griffini wrote: > > Now we got standard library features requiring type annotation > > We do? Did I miss them? Which std lib features are you referring to? > > (That's not a

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

In my opinion, the largest failure of Python 3 is that we failed to provide a smooth and *slow* transition from Python 2 and Python 3. It can be explained by the long list of backward incompatible changes. My advice would be to restrict the number of backward incompatible changes per release, and

Re: [Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

On April 27, 2018 12:16:09 AM Mike Miller wrote: Sorry all, wasn't specific enough. By "modern" I mean the last decade perhaps. New languages that have had a chance to look at the older generations and choose their best ideas, while leaving behind the rest.

[Python-Dev] PEP 575 (Unifying function/method classes) update

Hello all, I have updated PEP 575 and its reference implementation. See https://www.python.org/dev/peps/pep-0575/ The main differences with respect to the previous version are: * METH_PASS_FUNCTION now passes the function *in addition* to self (previously, it was passed *instead* of self). *

Re: [Python-Dev] Reserve ':=' for type-inferred variable initialization (was PEP 572)

On Fri, Apr 27, 2018 at 08:13:20AM +0200, Andrea Griffini wrote: > >> We're focused on Python 3.8 and 3.9, not Python 5 or Python 6. > > Hmmm... When I was hearing the repeated belated saying that Python > will never ever jump on the statically typed ship on each and every > static type

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

27.04.18 13:25, Nick Coghlan пише: and PEP 3099 (explicitly rejected ideas that also didn't get their own PEPs). "There will be no alternative binding operators such as :=." ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

On Thursday, April 26, 2018, Eric Snow wrote: > In pondering our approach to future Python major releases, I found > myself considering the experience we've had with Python 3. The whole > Py3k effort predates my involvement in the community so I missed a > bunch of

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

I gave the talk "Python 3: 10 years later" at FOSDEM and Pycon Italy and will give it again at Pycon US next month: https://fosdem.org/2018/schedule/event/python3/ My talk is focused on the migration path. How to "port" Python 2 code to Python 3, 2to3 tool, six module, things done to make the

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

On 27 April 2018 at 03:18, Barry Warsaw wrote: > On Apr 26, 2018, at 09:28, Eric Snow wrote: >> >> On Thu, Apr 26, 2018 at 10:25 AM, Eric Snow >> wrote: >>> In pondering our approach to future Python major releases, I

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

So, the style guidelines for this new feature -- and also ternary expressions and comprehension -- would need to mention that: - debuggers have no idea what to do with all of this on one line - left-to-right doesn't apply to comprehensions results = [(x, y, x/y) for x in input_data if (y :=

Re: [Python-Dev] Order of positional and keyword arguments

On Thu, 26 Apr 2018 22:25:09 +0300 Serhiy Storchaka wrote: > > f(b=2, *[1]) is surprised in two ways: > > 1. Argument values are passed not in order. The first value is assigned > to the second parameter, and the second value is assigned to the first > parameter. I don't

Re: [Python-Dev] Order of positional and keyword arguments

On Thu, Apr 26, 2018 at 12:25 PM, Serhiy Storchaka wrote: > f(b=2, *[1]) is surprised in two ways: > > 1. Argument values are passed not in order. The first value is assigned to > the second parameter, and the second value is assigned to the first > parameter. > > 2. Argument

Re: [Python-Dev] Every Release Can Be a Mini "Python 4000", Within Reason (was (name := expression) doesn't fit the narrative of PEP 20)

Eric Snow wrote: Unless I've missed something, there's no prohibition against deprecating things (and then later removing them) or other breaks in backward compatibility. I suppose that's true, but even so, changing "=" is going to feel like a really big change in the style of the language,

Re: [Python-Dev] Reserve ':=' for type-inferred variable initialization (was PEP 572)

Fatty Morgan wrote: Distinguishing in a rather unobtrusive way (no 'var' or 'let') the initialization of a previously unbound variable 'name := expr' and the re-assignment of a previously bound variable 'name = expr' That would be a massively confusing change. It's a fine idea for a new

Re: [Python-Dev] Reserve ':=' for type-inferred variable initialization (was PEP 572)

>> We're focused on Python 3.8 and 3.9, not Python 5 or Python 6. Hmmm... When I was hearing the repeated belated saying that Python will never ever jump on the statically typed ship on each and every static type annotation discussion I started to worry this wasn't indeed the case (why the urge

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

On 04/26/2018 09:02 PM, Alex Walters wrote: http://pyvideo.org/pycascades-2018/bdfl-python-3-retrospective.html link to Guido’s talk, for your convenience Many thanks! -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] PEP 394 update proposal: Allow changing the `python` command in some cases

Ben Finney writes: > Petr Viktorin writes: > > > […] we feel that the only way to *enforce* that guidelines is to > > provide environments where the `python` command does not work > > (unless explicitly installed). > > Yes. The ‘python’ command is