I just want to say upfront that my personal life has just gotten very hectic as of late (green card stuff for my wife who is Canadian) and probably will not let up until June. So if I go a while without replying to points being made for quite a while, I apologize. Luckily there seem to be others here who understand the direction I am coming from so there is no need to stop talking while I am pre-occupied with the real world.

On Sun, Apr 17, 2011 at 00:30, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:

>>>> In the grand python-dev tradition of "silence means acceptance", I consider
>>>> this PEP finalized and implicitly accepted.
>>
>> I haven't seen any responses that said, yes this is a well thought-out proposal
>> that will actually benefit any of the various implementations.
>
> In that case it may well be that the silence is because the other
> implementations think the PEP is OK.  They certainly voted in favor of
> the broad outline of it at the language summit.

Sounds like it was implicitly accepted even before it was written or any of the details were discussed.

Actually I directly emailed the relevant people from the other VMs to make sure they were happy with what I was aiming for before I approached python-dev with the PEP. So IronPython, Jython, and PyPy lead developers have all told me that they want something along the lines of this PEP to happen.
 

The big picture of "let's do something to make life easier for other implementations" is a worthy goal.  What that something should be is still a bit ambiguous.


>> every branch in a given implementation now guarantee every implementation detail
>> or do we only promise the published API (historically, we've *always* done the
>> latter)?
>
> As Brett said, people do come to depend on the details of the
> implementation.  But IMO the PEP should be clarified to say that the
> tests we are talking about should be tests *of the published API*.
> That is, blackbox tests, not whitebox tests.

+1 That's an excellent suggestion.  Without that change, it seems like the PEP is overreaching.

I'm okay with going with this line of through, including R. David's "100% branch coverage is but one way to achieve extensive testing of the published API".
 


>> Is there going to be any guidance on the commonly encountered semantic
>> differences between C modules and their Python counterparts (thread-safety,
>> argument handling, tracebacks, all possible exceptions, monkey-patchable pure
>> python classes versus hard-wired C types etc)?
>
> Presumably we will need to develop such guidance.

+1 That would be very helpful.  Right now, the PEP doesn't address any of the commonly encountered differences.

If people are willing to help me (i.e., go ahead and edit the PEP) with this then I am okay with adding some common issues (but I don't expect it to be exhaustive).
 


> I personally have no problem with the 100% coverage being made a
> recommendation in the PEP rather than a requirement.  It sounds like
> that might be acceptable to Antoine.  Actually, I would also be fine with
> saying "comprehensive" instead, with a note that 100% branch coverage is
> a good way to head toward that goal, since a comprehensive test suite
> should contain more tests than the minimum set needed to get to 100%
> branch coverage.

+1 better test coverage is always a good thing (IMO).


Raymond