Re: [Python-Dev] [Speed] speed.python.org

On 6 February 2016 at 04:07, Brett Cannon wrote: > On Thu, 4 Feb 2016 at 05:46 Nick Coghlan wrote: >> Heh, cdecimal utterly demolishing the old pure Python decimal module >> on the telco benchmark means normalising against CPython 3.5 rather >> than 2.7

Re: [Python-Dev] Opcode cache in ceval loop

On 05.02.2016 00:06, Matthias Bussonnier wrote: On Feb 4, 2016, at 08:22, Sven R. Kunze wrote: On 04.02.2016 16:57, Matthias Bussonnier wrote: On Feb 3, 2016, at 13:22, Yury Selivanov wrote: An ideal way would be to calculate a hit/miss ratio over

[Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (2016-01-29 - 2016-02-05) Python tracker at http://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: open5413 (+32) closed 32641 (+26) total 38054 (+58) Open issues

Re: [Python-Dev] [Speed] speed.python.org

On Thu, 4 Feb 2016 at 05:46 Nick Coghlan wrote: > On 4 February 2016 at 16:48, Zachary Ware > wrote: > > I'm happy to announce that speed.python.org is finally functional! > > There's not much there yet, as each benchmark builder has only sent >

Re: [Python-Dev] More optimisation ideas

On 2/5/2016 12:27, Emile van Sebille wrote: On 2/1/2016 9:20 AM, Ethan Furman wrote: On 02/01/2016 08:40 AM, R. David Murray wrote: On the other hand, if the distros go the way Nick has (I think) been advocating, and have a separate 'system python for system scripts' that is independent of

Re: [Python-Dev] speed.python.org

To piggyback on Zach's speed.python.org announcement, we will most likely be kicking off a discussion of redoing the benchmark suite, tweaking the test runner, etc. over on the speed@ ML. Those of us who have been doing perf work lately have found some shortcoming we would like to fix in our

Re: [Python-Dev] speed.python.org

Big thanks to you, Zachary (and everyone involved)! It's a very good news. Yury On 2016-02-04 1:48 AM, Zachary Ware wrote: I'm happy to announce that speed.python.org is finally functional! There's not much there yet, as each benchmark builder has only sent one result so far (and one of those

Re: [Python-Dev] More optimisation ideas

On Fri, 5 Feb 2016 at 10:34 Emile van Sebille wrote: > On 2/5/2016 9:37 AM, Alexander Walters wrote: > > > > > > On 2/5/2016 12:27, Emile van Sebille wrote: > >> On 2/1/2016 9:20 AM, Ethan Furman wrote: > >>> On 02/01/2016 08:40 AM, R. David Murray wrote: > >> > On the

Re: [Python-Dev] More optimisation ideas

On 2/1/2016 9:20 AM, Ethan Furman wrote: On 02/01/2016 08:40 AM, R. David Murray wrote: On the other hand, if the distros go the way Nick has (I think) been advocating, and have a separate 'system python for system scripts' that is independent of the one installed for user use, having the

Re: [Python-Dev] More optimisation ideas

On 2/5/2016 9:37 AM, Alexander Walters wrote: On 2/5/2016 12:27, Emile van Sebille wrote: On 2/1/2016 9:20 AM, Ethan Furman wrote: On 02/01/2016 08:40 AM, R. David Murray wrote: On the other hand, if the distros go the way Nick has (I think) been advocating, and have a separate 'system

Re: [Python-Dev] More optimisation ideas

On Friday, February 5, 2016 11:57 AM, Emile van Sebille wrote: > Aah, 'must' is less restrictive in this context than I expected. When > you combine the two halves the first part might be more accurately > phrased as 'The program must make source code available' rather than

Re: [Python-Dev] More optimisation ideas

On 2/5/2016 10:38 AM, Brett Cannon wrote: On Fri, 5 Feb 2016 at 10:34 Emile van Sebille > wrote: >> Except for that nasty licensing issue requiring source code. >> >> Emile > Licensing requires, in the GPL at least, that the

Re: [Python-Dev] More optimisation ideas

On 5 February 2016 at 15:05, Steven D'Aprano wrote: > (I'm not even sure if this suggestion makes sense, since I'm not really > sure what "freezing" the stdlib entails. Is it documented anywhere?) It's not particularly well documented - most of the docs you'll find are about

Re: [Python-Dev] Licensing issue (?) for Frozen Python? [was: More optimisation ideas]

On Sat, Feb 6, 2016 at 3:31 PM, Stephen J. Turnbull wrote: > Of course if *you* want to you can GPL Python (I think that's now > possible, at one time there was a issue with the CNRI license IIRC), > and then licensees of *your* distribution (but not you!) are required > to

Re: [Python-Dev] Licensing issue (?) for Frozen Python? [was: More optimisation ideas]

Chris Angelico writes: > And even the GPL doesn't require you to distribute the source along > with every copy of the binary. As long as the source is *available*, > it's acceptable to distribute just the binary for convenience. True (and it would apply to frozen Python as long as the source

Re: [Python-Dev] Licensing issue (?) for Frozen Python? [was: More optimisation ideas]

On Sat, Feb 6, 2016 at 4:31 PM, Stephen J. Turnbull wrote: > However, the technical problem remains. For example, you mention > Debian. While Debian keeps its source and binary packages very close > to "in sync" on the server, there are several gotchas. For example, >

[Python-Dev] Licensing issue (?) for Frozen Python? [was: More optimisation ideas]

Executive summary: There is no licensing issue because Python isn't copyleft. Stick to the pragmatic *technical* issue of how to reliably provide corresponding source to those who want to look at that source (just because that's how we do things in Python). Emile van Sebille writes: > Except