Fred L. Drake, Jr. <fdr...@acm.org> added the comment: It doesn't make sense to make any of these changes to Python 2; this really should have been separate from the documentation issue. That's probably understood by everyone, but explicit is better.
Merging implementations ----------------------- - I've no objection to merging RawConfigParser and SafeConfigParser, using a constructor argument to control whether interpolation is performed. It's not clear this provides any improvement in maintainability or usage. - Isolating the old (broken interpolation) ConfigParser behavior so it's not in the middle of the inheritance stack would be good. Changing ConfigParser behavior ------------------------------ Changing the behavior of the ConfigParser name requires the deprecation process. We may think nobody in their right mind is using that, but changing something out from under app developers is really bad. This should be considered a problem for configparser as outlined in msg 112598. Whether we can assign new semantics to the ConfigParser name in the future is questionable. I think Python's compatibility policy allows it, but that doesn't make it a good idea. (This seems to be the real sticking point, unfortunately.) Class names ----------- I don't understand Michael's objection to adding new names for the configparser classes; that's one of the few points where we don't run into backward-compatibility black holes. In the case of a merged implementation, a new name for the merged class (possibly "Configuration") may be the best bet; the old names can then be subclasses of that which generate appropriate deprecation warnings. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6517> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
