>> No, potentially wrong in cases where the APIs are different. Even with the >> try...except ImportError dance around StringIO / cStringIO there are some >> API differences. But for a lot of use cases it works fine (simplejson and >> json aren't *identical*, but it works for most people). > > > > Okay, granted, I accept your point. > > But I think we need to distinguish between these cases. > > In the case of StringIO and cStringIO, API compatibility is expected, and > differences are either bugs or implementation differences that you shouldn't > be relying on. > I just recently ran into a compatibility of StringIO and cStringIO. It's a good thing it's documented: "Another difference from the StringIO module is that calling StringIO() with a string parameter creates a read-only object. Unlike an object created without a string parameter, it does not have write methods. These objects are not generally visible. They turn up in tracebacks as StringI and StringO." But it did cause me a couple of minutes of grief until I found this piece in the docs and wrote a work-around. But no, even in the current stable stdlib, the "try import ... except import from elsewhere" trick doesn't "just work" for StringIO/cStringIO. And as far as I can understand this is documented, not a bug or some obscure implementation detail. My point is that if our users accept *this*, in the stable stdlib, I see no reason they won't accept the same happening between __preview__ and a graduated module, when they (hopefully) understand the intention of __preview__. Eli
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