Antoine Pitrou, 13.04.2011 02:07:
> On Tue, 12 Apr 2011 19:50:34 -0400
> Tres Seaver wrote:
>> Trying to accelerate existing code which doesn't have the coverage is
>> insane: how can you know that the accelerator doesn't subtly change the
>> semantics without tests?
>
> Well, why do you think tes
On Apr 13, 2011, at 4:52 AM, Antoine Pitrou wrote:
> On Wed, 13 Apr 2011 06:28:58 +0200
> Stefan Behnel wrote:
>>
>> However, I think we are really discussing a theoretical issue here. All the
>> PEP is trying to achieve is to raise the bar for C code in the stdlib, for
>> exactly the reason
On 4/13/2011 7:52 AM, Antoine Pitrou wrote:
On Wed, 13 Apr 2011 06:28:58 +0200
Stefan Behnel wrote:
I think it would help to point out in the PEP that code that fails to touch
the theoretical 100% test coverage bar is not automatically excluded from
integration, but needs solid reasoning, rev
On Wed, 13 Apr 2011 06:28:58 +0200
Stefan Behnel wrote:
>
> However, I think we are really discussing a theoretical issue here. All the
> PEP is trying to achieve is to raise the bar for C code in the stdlib, for
> exactly the reason that it can easily introduce subtle semantic differences
> i
Georg Brandl, 13.04.2011 08:54:
On 13.04.2011 02:07, Antoine Pitrou wrote:
On Tue, 12 Apr 2011 19:50:34 -0400
Tres Seaver wrote:
Trying to accelerate existing code which doesn't have the coverage is
insane: how can you know that the accelerator doesn't subtly change the
semantics without tests
On 13.04.2011 02:07, Antoine Pitrou wrote:
> On Tue, 12 Apr 2011 19:50:34 -0400
> Tres Seaver wrote:
>> Trying to accelerate existing code which doesn't have the coverage is
>> insane: how can you know that the accelerator doesn't subtly change the
>> semantics without tests?
>
> Well, why do yo
Antoine Pitrou, 13.04.2011 02:07:
On Tue, 12 Apr 2011 19:50:34 -0400
Tres Seaver wrote:
Trying to accelerate existing code which doesn't have the coverage is
insane: how can you know that the accelerator doesn't subtly change the
semantics without tests?
Well, why do you think tests guarantee
On Apr 12, 2011, at 7:50 PM, Tres Seaver wrote:
> Trying to accelerate existing code which doesn't have the coverage is
> insane: how can you know that the accelerator doesn't subtly change the
> semantics without tests?
But even if you do have 100% python source code branch coverage, that's not
On Tue, 12 Apr 2011 19:50:34 -0400
Tres Seaver wrote:
> Trying to accelerate existing code which doesn't have the coverage is
> insane: how can you know that the accelerator doesn't subtly change the
> semantics without tests?
Well, why do you think tests guarantee that the semantics are the sam
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/12/2011 06:31 PM, Antoine Pitrou wrote:
> On Tue, 12 Apr 2011 23:59:53 +0200
> brett.cannon wrote:
>> Technical details of
>> +the VM providing the accelerated code are allowed to differ as
>> +necessary, e.g., a class being a ``type`` when impl
On Tue, 12 Apr 2011 17:34:42 -0500
Benjamin Peterson wrote:
> 2011/4/12 Antoine Pitrou :
> > On Tue, 12 Apr 2011 23:59:53 +0200
> > brett.cannon wrote:
> >> Technical details of
> >> +the VM providing the accelerated code are allowed to differ as
> >> +necessary, e.g., a class being a ``type`` wh
2011/4/12 Antoine Pitrou :
> On Tue, 12 Apr 2011 23:59:53 +0200
> brett.cannon wrote:
>> Technical details of
>> +the VM providing the accelerated code are allowed to differ as
>> +necessary, e.g., a class being a ``type`` when implemented in C.
>
> I don't understand what this means ("a class bei
On Tue, 12 Apr 2011 23:59:53 +0200
brett.cannon wrote:
> Technical details of
> +the VM providing the accelerated code are allowed to differ as
> +necessary, e.g., a class being a ``type`` when implemented in C.
I don't understand what this means ("a class being a ``type`` when
implemented in C")
13 matches
Mail list logo
