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.
Sounds like it was implicitly accepted even before it was written or any of the details were discussed.
>>>> 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.
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.
+1 That's an excellent suggestion. Without that change, it seems like the PEP is overreaching.
>> 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 would be very helpful. Right now, the PEP doesn't address any of the commonly encountered differences.
>> 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 better test coverage is always a good thing (IMO).
> 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.
Raymond