M.-A. Lemburg schrieb: > On 2008-05-27 12:56, Thomas Heller wrote: >> M.-A. Lemburg schrieb: >>> On 2008-05-26 23:34, Christian Heimes wrote: >>>> M.-A. Lemburg schrieb: >>>>> Isn't that an awefuly confusing approach ? >>>>> >>>>> Wouldn't it be better to keep PyString APIs and definitions in >>>>> stringobject.c|h and only add a new bytesobject.h header file >>>>> that #defines the PyBytes APIs in terms of PyString APIs ? That >>>>> maintains backwards compatibility and allows Python internals to >>>>> use the new API names. >>>>> >>>>> With your approach, you've basically backported the confusing >>>>> notion in Py3k that str() maps PyUnicode, only that in Py2 str() >>>>> will now map to PyBytes. >>>> The last time I brought up the topic, I had a lengthy discussion >>>> with Guido. At first I wanted to rename the API in Python 3.0 only. >>>> Guido argued that it's going to cause too much merge conflicts. He >>>> then suggested the approach I implemented today. >>> That's the same argument that came up in the module renaming >>> discussion. >>> >>> I have a feeling that we should be looking for better merge tools, >>> rather than implement code changes that cause more trouble than do >>> good, just because our existing tools aren't smart enough. >> >> There are applications out there that dynamically import the python dll >> and link to the exported functions by name; they will all break. > > The exported APIs still use the old names. Just the source code > versions of the APIs change to the new names and they now live > in different files as well. > Sorry, then, I confused it with py3k. Thomas
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