[Python-Dev] Removal of Win32 ANSI API (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Sun Nov 14 11:14:27 CET 2010

We should also keep in mind that Microsoft have chosen to keep the bytes Win32 APIs around, despite their flaws, all in the name of backwards compatibility.

Of course, Microsoft is in a different position. If they remove a functionality in some release, their users typically can't go back and continue to use the old version - at least not on the same computer.

For Python, it's different: our users can go back to use an old version if the new one breaks their applications. And we do break applications from time to time, most notably with the introduction of Python 3.

While the goal of nudging third party developers towards the superior Unicode APIs is an admirable one, it is still the case that there is a lot of ASCII-only code out there.

The question is: is there also a lot of ASCII-only Python 3 software out there? And would developers of such software have difficulties to port it to a Unicode file name API.

E.g. applications could easily be storing filenames in an ASCII only datastore that provides them back to the application as bytes in 3.x.

That's speculation. My speculation would be that authors of such a datastore find that they can't even print the data anymore in a reasonable way, so they changed their API to return strings (i.e. decoding from ASCII) when they ported it to Python 3. They wouldn't even consider it a change, because it returned strings all the time, and now Python 3 has a different string type.

If you drop code without first deprecating it, chances are it will hurt someone. That's why having a deprecation period is the rule we usually follow (most of the time :-)).

I'm in favor of deprecating it first.

Regards, Martin

More information about the Python-Dev mailing list