[issue5412] extend configparser to support mapping access(__*item__)

2010-11-20 Thread Łukasz Langa
Changes by Łukasz Langa : -- resolution: -> accepted status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue5412] extend configparser to support mapping access(__*item__)

2010-11-11 Thread Łukasz Langa
Łukasz Langa added the comment: Fred, while you're at it have a look at your message here: http://bugs.python.org/issue9421#msg115558 (also documentation remarks on an otherwise closed issue). -- ___ Python tracker

[issue5412] extend configparser to support mapping access(__*item__)

2010-11-11 Thread Éric Araujo
Éric Araujo added the comment: Well, I suggest removing the leading spaces in the examples, except maybe in one place if you think it’s needed. -- ___ Python tracker ___ ___

[issue5412] extend configparser to support mapping access(__*item__)

2010-11-11 Thread Łukasz Langa
Łukasz Langa added the comment: Yup, most config parsers don't support that so there are not so many INI type files in the wild with this kind of formatting. On the other hand, Samba, XULRunner, mke2fs and others all use this. I mean, you're not forced to use that ugly feature but it's good t

[issue5412] extend configparser to support mapping access(__*item__)

2010-11-11 Thread Éric Araujo
Éric Araujo added the comment: In my experience of cfg files, it’s uncommon to have leading spaces (and also, may I add, ugly). It’s great that configparser supports them now, but I wouldn’t have put them in the basic examples. -- ___ Python track

[issue5412] extend configparser to support mapping access(__*item__)

2010-11-11 Thread Łukasz Langa
Łukasz Langa added the comment: Committed in r86402. Documentation changes pending, to be made after Fred's detailed review. Fred, you can review using trunk. Reassigned as a reminder. -- assignee: lukasz.langa -> fdrake keywords: +needs review -patch stage: unit test needed -> commit

[issue5412] extend configparser to support mapping access(__*item__)

2010-11-06 Thread R. David Murray
R. David Murray added the comment: Email uses 'failobj' instead of 'default'. I find that kind of odd, but oh well. I'm not sure how useful a single data point is, but just last month I wrote an application that uses the DEFAULT section. Each configfile section gives a set of parameters de

[issue5412] extend configparser to support mapping access(__*item__)

2010-11-05 Thread Fred L. Drake, Jr.
Fred L. Drake, Jr. added the comment: Code - The __name__-aversion in the mapping interface is a little heavy-handed, but given the implementation of __name__ elsewhere, I think this can be revisited separately if anyone cares enough. In particular, it should be allowed to give an _

[issue5412] extend configparser to support mapping access(__*item__)

2010-11-05 Thread Łukasz Langa
Changes by Łukasz Langa : Removed file: http://bugs.python.org/file19501/issue5412.diff ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue5412] extend configparser to support mapping access(__*item__)

2010-11-05 Thread Łukasz Langa
Łukasz Langa added the comment: Documentation complete. -- Added file: http://bugs.python.org/file19506/issue5412.diff ___ Python tracker ___

[issue5412] extend configparser to support mapping access(__*item__)

2010-11-04 Thread Łukasz Langa
Łukasz Langa added the comment: Patch updated yet again: * optional .get() arguments are now keyword only. This is a bit backwards incompatible but: * protects users of mapping protocol access from invoking get() as if the last positional argument was the `fallback` value (it would

[issue5412] extend configparser to support mapping access(__*item__)

2010-11-04 Thread Łukasz Langa
Changes by Łukasz Langa : Removed file: http://bugs.python.org/file19010/issue5412.diff ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue5412] extend configparser to support mapping access(__*item__)

2010-09-25 Thread Łukasz Langa
Łukasz Langa added the comment: Patch updated: * uses collections because they are built into the executable for 3.2 * uses itertools for the same reasons * in the end doesn't use weakrefs since after recent commits (Raymond removed __del__ from OrderedDict) the reference cycle problem went

[issue5412] extend configparser to support mapping access(__*item__)

2010-09-25 Thread Łukasz Langa
Changes by Łukasz Langa : Removed file: http://bugs.python.org/file18760/issue5412.diff ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue5412] extend configparser to support mapping access(__*item__)

2010-09-05 Thread Łukasz Langa
Łukasz Langa added the comment: Patch updated to avoid fuzzes from other commits. -- Added file: http://bugs.python.org/file18760/issue5412.diff ___ Python tracker ___ __

[issue5412] extend configparser to support mapping access(__*item__)

2010-09-05 Thread Łukasz Langa
Changes by Łukasz Langa : Removed file: http://bugs.python.org/file18441/issue5412.diff ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue5412] extend configparser to support mapping access(__*item__)

2010-08-08 Thread Łukasz Langa
Łukasz Langa added the comment: I am mostly gathering information for inclusion in the docs. So the comments about differences in behaviour are rather "for the record". Still, I'm happy that your +1 on them, too :) -- ___ Python tracker

[issue5412] extend configparser to support mapping access(__*item__)

2010-08-08 Thread Éric Araujo
Éric Araujo added the comment: No time to review the patch, but quick feedback: Your mappings behaving a bit differently than dicts but in a way compatible with usual configparser access is +1 for me. -- ___ Python tracker

[issue5412] extend configparser to support mapping access(__*item__)

2010-08-08 Thread Łukasz Langa
Changes by Łukasz Langa : -- assignee: -> lukasz.langa ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue5412] extend configparser to support mapping access(__*item__)

2010-08-08 Thread Łukasz Langa
Łukasz Langa added the comment: Patch updated for a state when #9452 is applied. Creating/overwriting sections with __setitem__ on the parser added. More thorough unit test suite for the mapping protocol. No documentation created yet. Fred, if you applied #9452 you might review this patch,

[issue5412] extend configparser to support mapping access(__*item__)

2010-08-08 Thread Łukasz Langa
Changes by Łukasz Langa : Removed file: http://bugs.python.org/file18276/issue5412.diff ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue5412] extend configparser to support mapping access(__*item__)

2010-08-02 Thread Fred L. Drake, Jr.
Changes by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue5412] extend configparser to support mapping access(__*item__)

2010-07-30 Thread Łukasz Langa
Łukasz Langa added the comment: OK, please find attached a preliminary patch for the functionality. This patch is complete in terms of implementation with one significant ommision, __setitem__ on the parser (adding a section), which needs further discussion. Because of the development state f

[issue5412] extend configparser to support mapping access(__*item__)

2010-07-28 Thread Ray.Allen
Ray.Allen added the comment: > Note that the two versions are not exclusive: We can look for an item if a > tuple is given and look for a section if it’s a string. Maybe confusing. +1. I think this is a good idea. Getting a section and Getting a key-value are both very common operations when

[issue5412] extend configparser to support mapping access(__*item__)

2010-07-28 Thread Michael Foord
Michael Foord added the comment: > The winning argument in my opinion is user convenience Well yes, for me too - as the user will always be operating on (section, key) pairs the extra level of indirection seems pointless. -- ___ Python tracker

[issue5412] extend configparser to support mapping access(__*item__)

2010-07-28 Thread Éric Araujo
Éric Araujo added the comment: Note that the two versions are not exclusive: We can look for an item if a tuple is given and look for a section if it’s a string. Maybe confusing. > - we can implement a cohesive mapping protocol that extends to get(), > del, in, etc. For now get() seems somewha