[Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

Andrew McNamara andrewm at object-craft.com.au
Wed Sep 22 01:37:55 CEST 2010


>> On the other hand, it is dangerous to provide a polymorphic API which
>> does that more extensive parsing, because a less than paranoid
>> programmer will have very likely allowed the parsed components to
>> escape from the context where their encodings can be reliably
>> determined. =A0Remember, *it is unlikely that they will ever be punished
>> for their own lack of caution.* =A0The person who is doomed is somebody
>> who tries to take that code and reuse it in a different context.
>
>Yeah, that's the original reasoning that had me leaning towards the
>parallel API approach. If I seem to be changing my mind a lot in this
>thread it's because I'm genuinely torn between the desire to make it
>easier to port existing 2.x code to 3.x by making the current API
>polymorphic and the fear that doing so will reintroduce some of the
>exact same bytes/text confusion that the bytes/str split is trying to
>get rid of.

I don't think polymorphic API's do anyone any favours in the long
run. My experience of the Py2 email API was that it would give the
developer false comfort, only to blow up when the app was in the hands
of users, and it didn't seem to matter how careful I was. Py3 has gone
the pure/strict route in the core, and I think libs should be consistent
with that choice.  Developers will have work a little harder, but there
will be less surprises.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/


More information about the Python-Dev mailing list