This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author fdrake
Recipients brett.cannon, eric.araujo, fdrake, georg.brandl, lukasz.langa, michael.foord, r.david.murray, rhettinger, till
Date 2010-08-03.17:53:08
SpamBayes Score 2.1732616e-12
Marked as misclassified No
Message-id <>
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.
Date User Action Args
2010-08-03 17:53:10fdrakesetrecipients: + fdrake, brett.cannon, georg.brandl, rhettinger, eric.araujo, r.david.murray, michael.foord, till, lukasz.langa
2010-08-03 17:53:10fdrakesetmessageid: <>
2010-08-03 17:53:09fdrakelinkissue6517 messages
2010-08-03 17:53:08fdrakecreate