Nick Coghlan added the comment: Future proofing is irrelevant at this point - this is just about what can realistically be implemented in 3.4, not what can be implemented with the luxury of several months to rearchitect the codec system (and if we were going to do that, we'd just fix the type mapping introspection problem).
There is no "codec registry" - there is only the default codec search function, the encodings import namespace, the normalisation algorithm and the alias dictionary. It sounds to me like you still believe it is possible to stick the genie back in the bottle and limit the codec system to what *you* think is a good idea. It doesn't work like that - the codecs module already provides a fully general data transformation system backed by lazy imports, and that isn't going to change due to backwards compatibility constraints. The only option we have is whether or not we file off the rough edges and try to ease the transition for users migrating from Python 2, where all of the standard library codecs fit within the limits of the text model, so the general purpose codec infrastructure almost never came into play. Getting rid of it is no longer a realistic option - documenting it, improving the failure modes and potentially adding some features (in Python 3.5+) are the only improvements that are genuinely feasible. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19619> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
