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 really isn't very readable :)
>
> I find vi
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,
> Debian does not restrict i
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
i
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 distribute source.
And
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 f
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
> 'must include'
On 2/5/2016 10:38 AM, Brett Cannon wrote:
On Fri, 5 Feb 2016 at 10:34 Emile van Sebille mailto:em...@fenx.com>> wrote:
>> Except for that nasty licensing issue requiring source code.
>>
>> Emile
> Licensing requires, in the GPL at least, that the *modified*
sources be
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 pyt
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 other hand, if the di
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
benchm
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
> > one result so far (and one of those involved a b
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
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 syst
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
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 wit
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 time
for each cached opcode, but that would
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 freeze utilities that
17 matches
Mail list logo
