[Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices) (original) (raw)
Stephen J. Turnbull stephen at xemacs.org
Tue Sep 21 17:10:01 CEST 2010
- Previous message: [Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)
- Next message: [Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Nick Coghlan writes:
(Basically, while the issue of programmers assuming 'latin-1' or 'utf-8' or similar ASCII friendly encodings when they shouldn't is real, I don't believe a polymorphic API here will make things any worse than what would happen with a parallel API)
That depends on how far the polymorphic API goes. As long as the polymorphic API never ever does anything that involves decoding wire format (and I include URL-quoting here), the programmer will have to explicitly do some decoding to get into much trouble, and at that point it's really their problem; you can't stop them.
But I don't know whether the web apps programmers will be satisfied with such a minimal API. If not, you're going to have to make some delicate judgments about what to provide and what not, and whether/how to provide a safety net of some kind. I don't envy you that task.
And if this turns out to be a disaster in practice:
I would say be conservative about which APIs you make polymorphic.
And there are a lot of APIs that probably should be considered candidates for polymorphic versions (regexp matching and searching, for example). So any experience or generic functionality you develop here is likely to benefit somebody down the road.
- Previous message: [Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)
- Next message: [Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]