Nick Coghlan added the comment: Victor, the general purpose codec infrastructure is more than a decade old, and supported in both Python 2 and Python 3, so you're not going to get it deprecated in the last few days before the 3.4 feature freeze. You've already succeeded in inconveniencing affected users migrating from Python 2 for another release by blocking the restoration of the transform codec aliases, but I'm definitely not going to revert any of the other already implemented codec handling improvements without a direct request from Larry as release manager or Guido as BDFL.
If you propose a new codec architecture as a PEP for Python 3.5 and get it accepted, then *that* would be the appropriate time to remove these improvements to the existing architecture. Until such a PEP is put forward and accepted, I will continue to work on documenting the status quo as clearly as I can (especially since the only thing I see wrong with it is the challenges it poses for type inference, and that's a pretty minor gripe in a language as resistant to static analysis as Python). I've tried to persuade you that lowering the barriers to adoption for Python 3 is a more significant concern than a mythical nirvana of conceptual purity that *runs directly counter to the stated intent of the creator of the current codec architecture*, but if you wish to exercise your core developer veto and deliberately inconvenience users, even though the original problems cited in issue 7475 have all been addressed, that's your choice. Just don't expect me to try to defend that decision to any users that complain, because I think it's completely the wrong thing to do. ---------- _______________________________________ 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
