Re: [Python-Dev] PEP 572: Assignment Expressions
On Tue, May 01, 2018 at 11:04:55AM +1000, Chris Angelico wrote: > To be fair, I don't see many people replacing "x = 1" with "for x in > [1]: pass". Even though it IS going to have the same effect. :-) Aside from the pass, that is precisely one of the current work-arounds for lack of binding-expressions inside comprehensions: # inefficient, and wrong when f(x) has side-effects [f(x) for x in iterable if f(x) > 1] # what we'd like [y for x in iterable if (y := f(x)) > 1] # a work-around [y for x in iterable for y in [f(x)] if y > 1] I think that's even in your PEP, isn't it? -- Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572: Assignment Expressions
On Tue, May 1, 2018 at 3:36 AM, Chris Jerdonek wrote: > 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 := ) and alternative rewritings of it without resorting to new syntax. > > Apologies if this idea has already been discussed (I might have missed > the relevant email), but thinking back to Tim's earlier example-- > > if (diff := x - x_base) and (g := gcd(diff, n)) > 1: > return g > > it occurs to me this could be implemented with current syntax using a > pattern like the following: > > stashed = [None] > > def stash(x): > stashed[0] = x > return x > > if stash(x - x_base) and stash(gcd(stashed[0], n)) > 1: > return stashed[0] > > There are many variations to this idea, obviously. For example, one > could allow passing a "name" to stash(), or combine stash / stashed > into a single, callable object that allows setting and reading from > its store. I wonder if one of them could be made into a worthwhile > pattern or API.. > . > I hope you don't think this recasting, is in any way less confusing to a beginner than an inline assignment. This is language abuse! In any case, what advantages would it have over simply declaring "stashed" as a global inside the function and omitting the confusing subscripting? regards Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572: Assignment Expressions
On Tue, May 1, 2018 at 2:14 AM, Steve Holden wrote: > On Tue, May 1, 2018 at 3:36 AM, Chris Jerdonek > wrote: >> >> 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 := ) and alternative rewritings of it without resorting to new >> > syntax. >> >> Apologies if this idea has already been discussed (I might have missed >> the relevant email), but thinking back to Tim's earlier example-- >> >> if (diff := x - x_base) and (g := gcd(diff, n)) > 1: >> return g >> >> it occurs to me this could be implemented with current syntax using a >> pattern like the following: >> >> stashed = [None] >> >> def stash(x): >> stashed[0] = x >> return x >> >> if stash(x - x_base) and stash(gcd(stashed[0], n)) > 1: >> return stashed[0] >> >> There are many variations to this idea, obviously. For example, one >> could allow passing a "name" to stash(), or combine stash / stashed >> into a single, callable object that allows setting and reading from >> its store. I wonder if one of them could be made into a worthwhile >> pattern or API.. > > I hope you don't think this recasting, is in any way less confusing to a > beginner than an inline assignment. This is language abuse! I didn't make any claims that it wouldn't be confusing (especially as is). It was just an _idea_. I mentioned it because (1) it uses current syntax, (2) it doesn't require intermediate assignments or extra indents in the main body of code, (3) it doesn't even require choosing intermediate names, and (4) I didn't see it mentioned in any of the previous discussion. All three of the first points have been major sources of discussion in the thread. So I thought it might be of interest. > In any case, what advantages would it have over simply declaring "stashed" > as a global inside the function and omitting the confusing subscripting? Right. Like I said, there are many variations. I just listed one to convey the general idea. --Chris ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASE] Python 2.7.15
I've gotten some mixed signals on the status of this release, notably from the BDFL: https://twitter.com/gvanrossum/status/991170064417153025 "Python 2.7.15 released -- the last 2.7 release!" (and a link to this thread) I was under the impression that 2.7 was being supported until 2020. If this is the final release of 2.7, what would "support" constitute? My assumption was that the final release of 2.7 would be sometime in 2020 (or much closer to 2020 than 19 months). > -Original Message- > From: Python-Dev list=sdamon@python.org> On Behalf Of Benjamin Peterson > Sent: Tuesday, May 1, 2018 12:10 AM > To: python-l...@python.org; python-annou...@python.org; python- > d...@python.org > Subject: [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://bugs.python.org/ > > The source tarball contains a complete changelog in the Misc/NEWS file. The > only change since the release candidate is a fix for undefined C behavior that > newer compilers (including GCC 8) have started to exploit. > > Users of the macOS binaries should note that all python.org macOS installers > now ship with a builtin copy of OpenSSL. Additionally, there is a new > additional installer variant for macOS 10.9+ that includes a built-in version of > Tcl/Tk 8.6. See the installer README for more information. > > Happy May, > Benjamin > 2.7 release manager > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/tritium- > list%40sdamon.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASE] Python 2.7.15
Simple. I misread "latest" for "last" and was hopeful that no new bugs would need to be fixed between now and 2020. I will post a correction on Twitter now. On Tue, May 1, 2018 at 2:58 AM, Alex Walters wrote: > I've gotten some mixed signals on the status of this release, notably from > the BDFL: > > https://twitter.com/gvanrossum/status/991170064417153025 > "Python 2.7.15 released -- the last 2.7 release!" (and a link to this > thread) > > I was under the impression that 2.7 was being supported until 2020. If > this > is the final release of 2.7, what would "support" constitute? My > assumption > was that the final release of 2.7 would be sometime in 2020 (or much closer > to 2020 than 19 months). > > > -Original Message- > > From: Python-Dev > list=sdamon@python.org> On Behalf Of Benjamin Peterson > > Sent: Tuesday, May 1, 2018 12:10 AM > > To: python-l...@python.org; python-annou...@python.org; python- > > d...@python.org > > Subject: [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://bugs.python.org/ > > > > The source tarball contains a complete changelog in the Misc/NEWS file. > The > > only change since the release candidate is a fix for undefined C behavior > that > > newer compilers (including GCC 8) have started to exploit. > > > > Users of the macOS binaries should note that all python.org macOS > installers > > now ship with a builtin copy of OpenSSL. Additionally, there is a new > > additional installer variant for macOS 10.9+ that includes a built-in > version of > > Tcl/Tk 8.6. See the installer README for more information. > > > > Happy May, > > Benjamin > > 2.7 release manager > > ___ > > Python-Dev mailing list > > Python-Dev@python.org > > https://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: https://mail.python.org/mailman/options/python-dev/tritium- > > list%40sdamon.com > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Every Release Can Be a Mini "Python 4000", Within Reason (was (name := expression) doesn't fit the narrative of PEP 20)
FWIW, this thread is about what "Python 4000" means and does not mean. Namely, Python feature deprecation and removal is not prohibited but the bar is high (as always), especially for syntax. While I appreciate the level of interest in certain under-consideration proposals, you'd be better served by continuing discussion about that proposal in other threads. Thanks! -eric On Mon, Apr 30, 2018 at 7:25 PM, Terry Reedy wrote: > 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 similarity to a familiar concept, albeit >> a=a+i makes no sense from this perspective. > > > When explaining iterative algorithms, such as Newton's method, > mathematicians write things like a' = a+1 or a(sub i+1 or sub new) = f(a(sub > i or sub old)) . For computer, we drop the super/subscript. Or one can > write more circuitously, > anew = update(aold) > aold = anew > The abbreviations should be explained when teaching loops. > > For proving that the body of a loop maintains a loop constant, one may > reinstate the super- or sub-script. > > -- > Terry Jan Reedy > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/ericsnowcurrently%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASE] Python 2.7.15
Is it possible to get the release notes included on the download page(s)? On Tue, May 1, 2018 at 10:35 AM, Guido van Rossum wrote: > Simple. I misread "latest" for "last" and was hopeful that no new bugs > would need to be fixed between now and 2020. I will post a correction on > Twitter now. > > On Tue, May 1, 2018 at 2:58 AM, Alex Walters > wrote: > > > I've gotten some mixed signals on the status of this release, notably > from > > the BDFL: > > > > https://twitter.com/gvanrossum/status/991170064417153025 > > "Python 2.7.15 released -- the last 2.7 release!" (and a link to this > > thread) > > > > I was under the impression that 2.7 was being supported until 2020. If > > this > > is the final release of 2.7, what would "support" constitute? My > > assumption > > was that the final release of 2.7 would be sometime in 2020 (or much > closer > > to 2020 than 19 months). > > > > > -Original Message- > > > From: Python-Dev > > list=sdamon@python.org> On Behalf Of Benjamin Peterson > > > Sent: Tuesday, May 1, 2018 12:10 AM > > > To: python-l...@python.org; python-annou...@python.org; python- > > > d...@python.org > > > Subject: [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://bugs.python.org/ > > > > > > The source tarball contains a complete changelog in the Misc/NEWS file. > > The > > > only change since the release candidate is a fix for undefined C > behavior > > that > > > newer compilers (including GCC 8) have started to exploit. > > > > > > Users of the macOS binaries should note that all python.org macOS > > installers > > > now ship with a builtin copy of OpenSSL. Additionally, there is a new > > > additional installer variant for macOS 10.9+ that includes a built-in > > version of > > > Tcl/Tk 8.6. See the installer README for more information. > > > > > > Happy May, > > > Benjamin > > > 2.7 release manager > > > ___ > > > Python-Dev mailing list > > > Python-Dev@python.org > > > https://mail.python.org/mailman/listinfo/python-dev > > > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > tritium- > > > list%40sdamon.com > > > > ___ > > Python-Dev mailing list > > Python-Dev@python.org > > https://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > > guido%40python.org > > > > > > -- > --Guido van Rossum (python.org/~guido) > -- > https://mail.python.org/mailman/listinfo/python-list > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python startup time
On 7/19/2017 12:15 PM, Larry Hastings wrote: > > > On 07/19/2017 05:59 AM, Victor Stinner wrote: >> Mercurial startup time is already 45.8x slower than Git whereas tested >> Mercurial runs on Python 2.7.12. Now try to sell Python 3 to Mercurial >> developers, with a startup time 2x - 3x slower... > > When Matt Mackall spoke at the Python Language Summit some years back, I > recall that he specifically complained about Python startup time. He > said Python 3 "didn't solve any problems for [them]"--they'd already > solved their Unicode hygiene problems--and that Python's slow startup > time was already a big problem for them. Python 3 being /even slower/ > to start was absolutely one of the reasons why they didn't want to upgrade. > > You might think "what's a few milliseconds matter". But if you run > hundreds of commands in a shell script it adds up. git's speed is one > of the few bright spots in its UX, and hg's comparative slowness here is > a palpable disadvantage. > > >> So please continue efforts for make Python startup even faster to beat >> all other programming languages, and finally convince Mercurial to >> upgrade ;-) > > I believe Mercurial is, finally, slowly porting to Python 3. > > https://www.mercurial-scm.org/wiki/Python3 > > Nevertheless, I can't really be annoyed or upset at them moving slowly > to adopt Python 3, as Matt's objections were entirely legitimate. I just now found found this thread when searching the archive for threads about startup time. And I was searching for threads about startup time because Mercurial's startup time has been getting slower over the past few months and this is causing substantial pain. As I posted back in 2014 [1], CPython's startup overhead was >10% of the total CPU time in Mercurial's test suite. And when you factor in the time to import modules that get Mercurial to a point where it can run commands, it was more like 30%! Mercurial's full test suite currently runs `hg` ~25,000 times. Using Victor's startup time numbers of 6.4ms for 2.7 and 14.5ms for 3.7/master, Python startup overhead contributes ~160s on 2.7 and ~360s on 3.7/master. Even if you divide this by the number of available CPU cores, we're talking dozens of seconds of wall time just waiting for CPython to get to a place where Mercurial's first bytecode can execute. And the problem is worse when you factor in the time it takes to import Mercurial's own modules. As a concrete example, I recently landed a Mercurial patch [2] that stubs out zope.interface to prevent the import of 9 modules on every `hg` invocation. This "only" saved ~6.94ms for a typical `hg` invocation. But this decreased the CPU time required to run the test suite on my i7-6700K from ~4450s to ~3980s (~89.5% of original) - a reduction of almost 8 minutes of CPU time (and over 1 minute of wall time)! By the time CPython gets Mercurial to a point where we can run useful code, we've already blown most of or past the time budget where humans perceive an action/command as instantaneous. If you ignore startup overhead, Mercurial's performance compares quite well to Git's for many operations. But the reality is that CPython startup overhead makes it look like Mercurial is non-instantaneous before Mercurial even has the opportunity to execute meaningful code! Mercurial provides a `chg` program that essentially spins up a daemon `hg` process running a "command server" so the `chg` program [written in C - no startup overhead] can dispatch commands to an already-running Python/`hg` process and avoid paying the startup overhead cost. When you run Mercurial's test suite using `chg`, it completes *minutes* faster. `chg` exists mainly as a workaround for slow startup overhead. Changing gears, my day job is maintaining Firefox's build system. We use Python heavily in the build system. And again, Python startup overhead is problematic. I don't have numbers offhand, but we invoke likely a few hundred Python processes as part of building Firefox. It should be several thousand. But, we've had to "hack" parts of the build system to "batch" certain build actions in single process invocations in order to avoid Python startup overhead. This undermines the ability of some build tools to formulate a reasonable understanding of the DAG and it causes a bit of pain for build system developers and makes it difficult to achieve "no-op" and fast incremental builds because we're always invoking certain Python processes because we've had to move DAG awareness out of the build backend and into Python. At some point, we'll likely replace Python code with Rust so the build system is more "pure" and easier to maintain and reason about. I've seen posts in this thread and elsewhere in the CPython development universe that challenge whether milliseconds in startup time matter. Speaking as a Mercurial and Firefox build system developer, *milliseconds absolutely matter*. Going further, *fractions of milliseconds matter*. For Mercurial's tes
