>>>> 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. 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. >> 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. > 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
