[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Łukasz Langa added the comment: Hopefully both RawConfigParser and ConfigParser will be successfully deprecated as part of #10499. The discussion goes on there. -- resolution: -> duplicate status: open -> closed superseder: -> Modular interpolation in configparser __

[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Changes by Łukasz Langa : -- assignee: -> lukasz.langa nosy: -brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Michael Foord added the comment: If we merge the functionality in a single class with a new name then I guess that is fine as it will simplify the documentation rather than complexify it (good word hey). We still need to *mention* the old names so that people finding them in old code can find

[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Changes by Łukasz Langa : -- versions: -Python 2.6, Python 2.7, Python 3.1 ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Fred L. Drake, Jr. 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

[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Łukasz Langa added the comment: There IS one more option that seems to be better than all of the above: 1. Add an interpolation=True argument to RawConfigParser __init__ and move the interpolating functionality from SafeConfigParser to it. 2. Rename RawConfigParser to ConfigParser leaving the

[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Michael Foord added the comment: Getting *rid* of the name ConfigParser would be annoying and cause *gratuitous* code breakage. If we are going to keep the name but get rid of the "unsafe" version then we can only replace it with what is now SafeConfigParser - as it is almost entirely compat

[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Éric Araujo added the comment: Agree on the proposal of Łukasz, with the caveat mentioned by Fred (rename the class and make the old name an alias, for pickle and all). I’ll let Michael and Fred decide if the name ConfigParser has to go or not, I’m happy enough that the class will be deprecat

[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Michael Foord added the comment: By the way, given that deprecation warnings are silent I am strongly -1 on removing the ConfigParser name altogether. That would cause far more breakage. As ConfigParser should not be used at all, and SafeConfigParser provides its functionality minus bugs, Saf

[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Michael Foord added the comment: Sorry - I misunderstood your earlier suggestion Fred. configparser.ConfigParser is the *natural* name for SafeConfigParser. I'm strongly +1 on moving towards that. (I doubt there would *actually* be any real code breakage if we did it earlier though ;-) -

[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Łukasz Langa added the comment: Unfortunately, I have to agree with Fred here. We'll stick to renaming and the deprecation process. -- ___ Python tracker ___ ___

[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Fred L. Drake, Jr. added the comment: Making ConfigParser an alias for SafeConfigParser creates a silent behavioral change. An application developer may not realize that users rely on the "full" ConfigParser anti-glory and end up breaking their configurations without so much as providing a head

[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Michael Foord added the comment: I'd be happy with aliasing SafeConfigParser to ConfigParser in 3.2. Can we just do this without a deprecation process? -- ___ Python tracker ___

[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Fred L. Drake, Jr. added the comment: 2010/8/3 Łukasz Langa : > 1) In 3.2 we add an alias: > > InterpolatingConfigParser = SafeConfigParser I'd rather see the class renamed and SafeConfigParser made the alias in 3.2. Otherwise, +1 for this plan (msg 112589), as there's no silent breakage. ---

[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Łukasz Langa added the comment: Eric, while I agree that would be nice as well, renaming each and every parser in the module will be more problematic for sure. *** TO ALL: WHAT DO YOU SAY TO A PATH LIKE THIS *** 1) In 3.2 we add an alias: InterpolatingConfigParser = SafeConfigParser 1.1)

[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Éric Araujo added the comment: > The first sentence is "Derived class of ConfigParser that implements > a sane variant of the magical interpolation feature." I think it's > enough for an explanation. True. >> but I don’t know if python-dev will agree with this deprecation. I wrote that before

[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Georg Brandl added the comment: Agree with Michael, +1. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Łukasz Langa added the comment: > If ConfigParser is not documented first, the name “SafeConfigParser” becomes > strange—safe compared to what? The first sentence is "Derived class of ConfigParser that implements a sane variant of the magical interpolation feature." I think it's enough for an

[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Éric Araujo added the comment: If ConfigParser is not documented first, the name “SafeConfigParser” becomes strange—safe compared to what? These names have an historical motivation and could become clearer if renamed, but I don’t know if python-dev will agree with this deprecation. Renaming a

[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Michael Foord added the comment: +1 for deprecation. Nobody *should* be using ConfigParser anyway, and of those who are 99% either wouldn't notice or would have bugs in their code *fixed* by the rename, so I can't see much of a downside. -- ___ Pyt

[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Łukasz Langa added the comment: Yes, so the patch part is already solved. The thing that is still open to discussion is whether we should do something like this: 1. Pending-Deprecate naked the ConfigParser class in 3.2. 2. Deprecate it in 3.3. 3. Remove it in 3.4 and rename SafeConfigParser to

[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Georg Brandl added the comment: The 3.2 docs now don't mention ConfigParser prominently anymore (as part of a different patch that added some features). Could be done in other branches as well. -- ___ Python tracker

[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Changes by Éric Araujo : -- nosy: +merwok ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser

Michael Foord added the comment: Note that the patch doesn't apply cleanly. Łukasz Langa is going to update it. There is still discussion as to whether we should *also* deprecate ConfigParser (well - PendingDeprecation in 3.2, Deprecation in 3.3 and in 3.4 making ConfigParser an alias for Saf