Showing content from http://mail.python.org/pipermail/python-dev/attachments/20110406/3c0cf00a/attachment.html below:
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 6, 2011, at 10:24 AM, Maciej Fijalkowski wrote:</div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>"I saw no need to complicate the pure python code for this."<br><br>if you complicate the C code for this, then please as well complicate<br>python code for this since it's breaking stuff.<br></div></blockquote><div><br></div><div><br></div><div>Do you really need a PEP for this one extraordinary and weird case?</div><div>The code is long since gone (never in 3.x). If you disagreed with</div><div>the closing of the bug report, just re-open it and a patch can go</div><div>into a 2.7 point release. The downside is that it would not be a</div><div>pretty piece of python.</div><div><br></div><br><blockquote type="cite"><div>And this:<br><br>"FWIW, the C code is not guaranteed to be exactly the same in terms of<br>implementation details, only the published API should be the same.<br>And, for this module, a decision was made for the C code to support<br>only lists eventhough the pure python version supports any sequence."<br><br>The idea of the PEP is for C code to be guaranteed to be the same as<br>Python where it matters to people.<br></div></blockquote></div><div><br></div>That is a good goal. Unfortunately, people can choose to rely on<div>all manner of implementation details (whether in C or pure Python).</div><div><br></div><div>If we want a pure python version of map() for example, the straight-forward</div><div>way doesn't work very well because "map(chr, 3)" raises a TypeError</div><div>right away in C code, but a python version using a generator wouldn't</div><div>raise until next() is called. Would this be considered a detail that</div><div>matters to people? If so, it means that all the pure python equivalents</div><div>for itertools would be have to be written as classes, making them hard</div><div>to read and making them run slowly on all implementations except for PyPy.</div><div><br></div><div>The original of the bug report you mentioned arose because a major</div><div>tool relied on the pure python heapq code comparing "not b <= a"</div><div>rather than the equivalent "a < b". So this was an implementation</div><div>detail that mattered to someone, but it went *far* beyond any guaranteed</div><div>behaviors.</div><div><br></div><div>Tracebacks are another area where C code and pure python code</div><div>can't be identical. This may or may not matter to someone.</div><div><br></div><div>The example in the PEP focused on which particular exception,</div><div>a TypeError or AttributeError, was raised in response to an</div><div>oddly constructed Spam() class. I don't know that that was</div><div>forseeable or that there would have been a reasonable way</div><div>to eliminate the difference. It does sound like the difference</div><div>mattered to someone though.</div><div><br></div><div>C code tends to use direct internal calls such as Py_SIZE(obj)</div><div>rather than doing a lookup using obj.__len__(). This is often</div><div>a detail that matters to people because it prevents them from</div><div>hooking the call to __len__. The C code has to take this </div><div>approach in order to protect its internal invariants and not crash.</div><div>If the pure python code tried to emulate this, then every call to</div><div>len(self) would need to be replaced by self.__internal_len()</div><div>where __internal_len is the real length method and __len__</div><div>is made equal to it.</div><div><br></div><div>In C to Python translations, do we want locks to be required</div><div>so that atomicity behaviors are matched? That property</div><div>likely matters to some users.</div><div><br></div><div>ISTM that every person who sets out to translate code from</div><div>C to Python or vice versa is already trying their best to make them</div><div>behave as similarly as possible. That is always the goal.</div><div><br></div><div>However, the PEP seems to be raising the bar by insisting</div><div>on the code being functionally identical. I think we should</div><div>make some decisions about what that really means; otherwise,</div><div>every piece of code will be in violation of the PEP for someone</div><div>choosing to rely on an implementation detail that isn't the same.</div><div><br></div><div>In my opinion, a good outcome of this discussion would be</div><div>a list of implementation details that we want to guarantee</div><div>and ones that we explicitly say that are allowed to vary.</div><div><br></div><div>I would also like to see strong guidance on the use of the</div><div>concrete C API which can make it impossible for client code</div><div>to use subclasses of builtin types (issue 10977). That is</div><div>another area where differences will arise that will matter</div><div>to some users.</div><div><br></div><div><br></div><div>Raymond</div><div><br></div><div><br></div><div>P.S. It would be great if the PEP were to supply a</div><div>complete, real-word example of code that is considered</div><div>to be identical. A pure python version of map() could</div><div>serve as a good example, trying to make it model all </div><div>the C behaviors as exactly as possible (argument handling,</div><div>choice of exceptions, length estimation and presizing, etc).</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></body></html>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4