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

2010-11-21 Thread Łukasz Langa
Łukasz Langa luk...@langa.pl 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

2010-08-08 Thread Łukasz Langa
Changes by Łukasz Langa luk...@langa.pl: -- assignee: - lukasz.langa nosy: -brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6517 ___

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

2010-08-03 Thread Éric Araujo
Changes by Éric Araujo mer...@netwok.org: -- nosy: +merwok ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6517 ___ ___ Python-bugs-list mailing

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

2010-08-03 Thread Georg Brandl
Georg Brandl ge...@python.org 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

2010-08-03 Thread Łukasz Langa
Łukasz Langa luk...@langa.pl 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

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

2010-08-03 Thread Michael Foord
Michael Foord mich...@voidspace.org.uk 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. --

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

2010-08-03 Thread Éric Araujo
Éric Araujo mer...@netwok.org 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

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

2010-08-03 Thread Łukasz Langa
Łukasz Langa luk...@langa.pl 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

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

2010-08-03 Thread Georg Brandl
Georg Brandl ge...@python.org added the comment: Agree with Michael, +1. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6517 ___ ___

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

2010-08-03 Thread Éric Araujo
Éric Araujo mer...@netwok.org 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

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

2010-08-03 Thread Łukasz Langa
Łukasz Langa luk...@langa.pl 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 =

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

2010-08-03 Thread Fred L. Drake, Jr.
Fred L. Drake, Jr. fdr...@acm.org added the comment: 2010/8/3 Łukasz Langa rep...@bugs.python.org: 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),

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

2010-08-03 Thread Michael Foord
Michael Foord mich...@voidspace.org.uk 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 rep...@bugs.python.org

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

2010-08-03 Thread Fred L. Drake, Jr.
Fred L. Drake, Jr. fdr...@acm.org 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

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

2010-08-03 Thread Łukasz Langa
Łukasz Langa luk...@langa.pl added the comment: Unfortunately, I have to agree with Fred here. We'll stick to renaming and the deprecation process. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6517

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

2010-08-03 Thread Michael Foord
Michael Foord mich...@voidspace.org.uk 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

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

2010-08-03 Thread Michael Foord
Michael Foord mich...@voidspace.org.uk 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

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

2010-08-03 Thread Éric Araujo
Éric Araujo mer...@netwok.org 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

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

2010-08-03 Thread Michael Foord
Michael Foord mich...@voidspace.org.uk 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

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

2010-08-03 Thread Łukasz Langa
Łukasz Langa luk...@langa.pl 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

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

2010-08-03 Thread Fred L. Drake, Jr.
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

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

2010-08-03 Thread Łukasz Langa
Changes by Łukasz Langa luk...@langa.pl: -- versions: -Python 2.6, Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6517 ___

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

2010-08-03 Thread Michael Foord
Michael Foord mich...@voidspace.org.uk 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

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

2010-07-26 Thread Michael Foord
Michael Foord mich...@voidspace.org.uk 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