>> 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 _______________________________________________ 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
