Re: [Python-Dev] PEP 572: Assignment Expressions

Steven D'Aprano wrote: "Not sure"? Given that you listed seven ways, how much more evidence do you need to conclude that it is simply wrong to say that Python has a single way to assign a value to a name? Yes, but six of those are very specialised, and there's rarely any doubt about when it's

Re: [Python-Dev] [RELEASE] Python 2.7.15

Congrats to all involved! -- H On 30 April 2018 at 21:09, Benjamin Peterson wrote: > Greetings, > I'm pleased to announce the immediate availability of Python 2.7.15, the > latest bug fix release in the senescent Python 2.7 series. > > Source and binary downloads may be found on python.org: > >

[Python-Dev] [RELEASE] Python 2.7.15

Greetings, I'm pleased to announce the immediate availability of Python 2.7.15, the latest bug fix release in the senescent Python 2.7 series. Source and binary downloads may be found on python.org: https://www.python.org/downloads/release/python-2715/ Bugs should be reported to https://bu

Re: [Python-Dev] PEP 572: Usage of assignment expressions in C

[Raymond Hettinger ] > Thanks Antoine, this is an important point that I hope doesn't get lost. > In a language with exceptions, assignment expressions are less needful. > Also, the pattern of having of having mutating methods return None > further limits the utility. It doesn't diminish the utili

Re: [Python-Dev] PEP 572: Usage of assignment expressions in C

> On Apr 28, 2018, at 8:45 AM, Antoine Pitrou wrote: > >> I personally haven't written a lot of C, so have no personal experience, >> but if this is at all a common approach among experienced C developers, it >> tells us a lot. > > I think it's a matter of taste and personal habit. Some peopl

Re: [Python-Dev] PEP 572: A backward step in readability

> On Apr 30, 2018, at 9:37 AM, Steven D'Aprano wrote: > > On Mon, Apr 30, 2018 at 08:09:35AM +0100, Paddy McCarthy wrote: > [...] >> A PEP that can detract from readability; *readability*, a central >> tenet of Python, should >> be rejected, (on principle!), when such objections are treated so

Re: [Python-Dev] PEP 572: Assignment Expressions

On Thu, Apr 26, 2018 at 10:33 AM, Sven R. Kunze wrote: > On 25.04.2018 01:19, Steven D'Aprano wrote: >> >> Sorry, gcd(diff, n) is not the "perfect name", and I will tell you that >> sometimes g is better. [...] > > We were talking about the real-world code snippet of Tim (as a justification > of :

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

On 4/30/2018 4:00 PM, Jeff Allen wrote: They were not "statements", but "formulas" while '=' was assignment (sec 8) *and* comparison (sec 10B). So conversely to our worry, they actually wanted users to think of assignment initially as a mathematical formula (page 2) in order to exploit the sim

Re: [Python-Dev] PEP 572: Assignment Expressions

On Mon, Apr 30, 2018 at 05:27:08PM -0700, Larry Hastings wrote: > > On 04/30/2018 07:30 AM, Mark Shannon wrote: > >Would Python be better with two subtly different assignment operators? > >The answer of "no" seems self evident to me. > > Maybe this has been covered in the thread earlier--if so, I

Re: [Python-Dev] PEP 572: Assignment Expressions

On 04/30/2018 07:30 AM, Mark Shannon wrote: Would Python be better with two subtly different assignment operators? The answer of "no" seems self evident to me. Maybe this has been covered in the thread earlier--if so, I missed it, sorry.  But ISTM that Python already has multiple ways to perf

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

On 30/04/2018 07:22, Greg Ewing wrote: Jeff Allen wrote: I speculate this all goes back to some pre-iteration version of FORmula TRANslation, where to its inventors '=' was definition and these really were "statements" in the normal sense of stating a truth. Yeah, also the earliest FORTRAN di

Re: [Python-Dev] PEP 572: A backward step in readability

On 30 April 2018 at 17:37, Steven D'Aprano wrote: > > On Mon, Apr 30, 2018 at 08:09:35AM +0100, Paddy McCarthy wrote: > [...] > > A PEP that can detract from readability; *readability*, a central > > tenet of Python, should > > be rejected, (on principle!), when such objections are treated so > >

Re: [Python-Dev] [python-committers] IMPORTANT - final 3.7.0 beta cutoff!

Hi, I modified the behaviour of the socketserver module: ThreadingMixIn now waits until all threads complete and ForkingMixIn now waits until all child processes complete https://bugs.python.org/issue31233 https://bugs.python.org/issue31151 I was supposed to do something, like add an option to a

Re: [Python-Dev] PEP 572: A backward step in readability

On 04/30/2018 12:37 PM, Steven D'Aprano wrote: > - comprehensions? not readable, easy to abuse, hard for beginners > to comprehend; I still refer to them as "list incomprehensions" in my head, particularly for those whic expand across line breaks. Tres. --

[Python-Dev] IMPORTANT - final 3.7.0 beta cutoff!

Just a reminder that 3.7.0b4 is almost upon us. Please get your feature fixes, bug fixes, and documentation updates in before 2018-04-30 ~23:59 Anywhere on Earth (UTC-12:00). That's about 16 hours from now. IMPORTANT: We are now in the final phase of 3.7.0. Tomorrow's 3.7.0b4 is the final beta pla

Re: [Python-Dev] PEP 572: A backward step in readability

TBH I think the text of the PEP could be much improved -- for example it should use motivating examples from real code, not artificial examples to show edge cases of the semantics. At this point I don't think that more people expressing an opinion one way or another are going to make a difference.

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

On Apr 30, 2018, at 06:36, Nick Coghlan wrote: > Instead of editing old PEPs, would it make sense to write a new one > which replaces the old one? As a general rule, at least the way I think about it, Informational PEPs can mostly be updated inline, evolving with new insights as we go along. A

Re: [Python-Dev] PEP 572: Assignment Expressions

On Mon, Apr 30, 2018 at 1:03 PM Chris Angelico wrote: > > That's a weird argument, Chris :-) > > > > If `f(x)` has no meaningful name, then *what* is the result of the > > comprehension? Perhaps some meaningless data? ;) > f(x) might have side effects. Can you give a meaningful name to the > tri

Re: [Python-Dev] PEP 572: Assignment Expressions

On Tue, May 1, 2018 at 2:53 AM, Yury Selivanov wrote: > On Mon, Apr 30, 2018 at 11:32 AM Chris Angelico wrote: > >> On Tue, May 1, 2018 at 12:30 AM, Mark Shannon wrote: >> > List comprehensions >> > --- >> > The PEP uses the term "simplifying" when it really means "shortening". >

Re: [Python-Dev] PEP 572: Assignment Expressions

On Mon, Apr 30, 2018 at 11:32 AM Chris Angelico wrote: > On Tue, May 1, 2018 at 12:30 AM, Mark Shannon wrote: > > List comprehensions > > --- > > The PEP uses the term "simplifying" when it really means "shortening". > > One example is > > stuff = [[y := f(x), x/y] for x in range

Re: [Python-Dev] PEP 572: A backward step in readability

On 30 April 2018 at 17:37, Steven D'Aprano wrote: > On Mon, Apr 30, 2018 at 08:09:35AM +0100, Paddy McCarthy wrote: > [...] >> A PEP that can detract from readability; *readability*, a central >> tenet of Python, should >> be rejected, (on principle!), when such objections are treated so >> dismi

Re: [Python-Dev] PEP 572: A backward step in readability

On Mon, Apr 30, 2018 at 08:09:35AM +0100, Paddy McCarthy wrote: [...] > A PEP that can detract from readability; *readability*, a central > tenet of Python, should > be rejected, (on principle!), when such objections are treated so > dismissively. Unless you have an objective measurement of reada

Re: [Python-Dev] PEP 575: Unifying function/method classes

On 2018-04-30 15:38, Mark Shannon wrote: While a unified *interface* makes sense, a unified class hierarchy and implementation, IMO, do not. The main reason for the common base class is performance: in the bytecode interpreter, when we call an object, CPython currently has a special case for

Re: [Python-Dev] PEP 572: Assignment Expressions

Le 30/04/2018 à 17:30, Chris Angelico a écrit : def do_things(fire_missiles=False, plant_flowers=False): ... do_things(plant_flowers:=True) # whoops! If you want your API to be keyword-only, make it keyword-only. If you want a linter that recognizes unused variables, get a linter that recogni

[Python-Dev] PEP 572: A backward step in readability

The PEP s section on Frequently raised objections includes: (https://www.python.org/dev/peps/pep-0572/#this-could-be-used-to-create-ugly-code) > This could be used to create ugly code! > > So can anything else. This is a tool, and it is up to the programmer to use > it where > it makes sense, an

Re: [Python-Dev] PEP 572: Assignment Expressions

On Tue, May 1, 2018 at 12:30 AM, Mark Shannon wrote: > List comprehensions > --- > The PEP uses the term "simplifying" when it really means "shortening". > One example is > stuff = [[y := f(x), x/y] for x in range(5)] > as a simplification of > stuff = [(lambda y: [y,x/y])(f(x)) fo

Re: [Python-Dev] PEP 572: Assignment Expressions

Hi, On 17/04/18 08:46, Chris Angelico wrote: Having survived four rounds in the boxing ring at python-ideas, PEP 572 is now ready to enter the arena of python-dev. I'm very strongly opposed to this PEP. Would Python be better with two subtly different assignment operators? The answer of "no"

Re: [Python-Dev] PEP 575: Unifying function/method classes

On 30 April 2018 at 23:38, Mark Shannon wrote: > > On 12/04/18 17:12, Jeroen Demeyer wrote: > >> Dear Python developers, >> >> I would like to request a review of PEP 575, which is about changing the >> classes used for built-in functions and Python functions and methods. The >> text of the PEP c

Re: [Python-Dev] PEP 575: Unifying function/method classes

On 12/04/18 17:12, Jeroen Demeyer wrote: Dear Python developers, I would like to request a review of PEP 575, which is about changing the classes used for built-in functions and Python functions and methods. The text of the PEP can be found at The motivation of PEP 575 is to allow introspe

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

On 30 April 2018 at 18:11, Victor Stinner wrote: > 2018-04-27 17:37 GMT+02:00 Petr Viktorin : > > (...) > > - The paragraph about the anticipated future where python points to > Python 3 > > is removed. > > Instead of editing old PEPs, would it make sense to write a new one > which replaces the o

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

2018-04-27 17:37 GMT+02:00 Petr Viktorin : > (...) > - The paragraph about the anticipated future where python points to Python 3 > is removed. Instead of editing old PEPs, would it make sense to write a new one which replaces the old one? The PEP 394 has been written in 2011 and accepted in 2012

Re: [Python-Dev] PEP 572: Usage of assignment expressions in C

2018-04-28 17:45 GMT+02:00 Antoine Pitrou : > // Read up to n bytes from file descriptor > if ((bytes_read = read(fd, buf, n)) == -1) { > // Error occurred while reading, do something > } About C, there is a popular coding style (not used by our PEP 7) for comparison: if (-1 == n)

Re: [Python-Dev] Bugs Migration to OpenShift

Does it mean that the final switch will happen during the sprints? Would it be possible to do it before or after? If bugs.python.org doesn't work during the sprint, it will be much harder to contribute to CPython during the sprints. (If I misunderstood, ignore my message :-)) Victor 2018-04-29 1

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

On 4/29/2018 11:51 PM, Guido van Rossum wrote: On Sun, Apr 29, 2018 at 10:45 AM, Eitan Adler > wrote: On 29 April 2018 at 01:34, Jeff Allen mailto:ja...@farowl.co.uk>> wrote: > On 27/04/2018 08:38, Greg Ewing wrote: > I speculate this all goes back to so

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

2018-04-28 3:33 GMT+02:00 Greg Ewing : > 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 s