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