Łukasz Langa <luk...@langa.pl> 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 for this functionality, the patch includes 
some comments that are meant to aid reviewers and the developer (me). They are 
obviously not supposed to be included in the final patch. There is neither any 
ReST documentation and only the BasicTest was ported to check for the mapping 
behaviour as well at the moment. All of these will be corrected once there is 
agreement upon the interface and its implementation.

The mapping interface implementation is using the parser['section']['value'] 
notation that seems to be more popular amongst the developers. The alternative 
implementation presented in the first patch shall not be included because 
"There should be preferably only one obvious way to do it". Implementing both 
approaches in a consistent manner would be needlessly tricky and would bloat 
the code, the tests and the documentation. I believe it's not worth it.

The mapping interface implementation enables getting parser['section'] which 
returns a mutable view on the section. This means that:
- the values are not copied but they are taken from the original parser on 
demand
- the values mutated using this view are mutated in the original parser

The implementation is using the existing high-level API so that subclassing the 
original interface makes the mappings work as expected as well. This has the 
drawback of having potentially weak performance (especially __len__ and 
__iter__ on a section). One difference is the explicit lack of support for the 
`__name__` special key. This is because the existing behaviour of `__name__` is 
very inconsistent and supporting it would only lead to problems. Details here: 
http://mail.python.org/pipermail/python-dev/2010-July/102556.html

The mapping interface was implemented so that it behaves as close to an actual 
dictionary as possible. The existing differences are:
- all sections do include DEFAULTSECT values as well
  -- these values cannot be deleted from the section (because technically they 
are not there). If they are overriden in the section, deleting causes the 
default value to be visible again. Trying to delete a default value causes a 
KeyError
  -- because of this reason, .clear() on a section does not leave the section 
empty
- trying to delete the DEFAULTSECT throws ValueError
- the mapping interface is complete thanks to using the MutableMapping ABC. 
However, there are two methods in the old API that hide the dictionary 
interface:
  -- .get() - this one is unsolvable even when we get to implementing default= 
for it because invoking as .get('string1', 'string2') would be ambiguous. This 
difference shall be explicitly documented in the docs.
  -- .items() - this one could potentially be solvable by providing a special 
case when no arguments are passed. The problem is with existing subclasses 
(possibly 3rd party) which override this method without handling this case. I'm 
still on the fence whether to include a special case here.

As for adding a section with the mapping protocol access, I like the current 
behaviour used for instance in ConfigObj is good for us. They use something 
like:

parser['section'] = {'key1': 'value', 'key2': 'value'}

This should overwrite existing sections as well. If no-one objects, I'll 
implement this behaviour as well.

----------
Added file: http://bugs.python.org/file18276/issue5412.diff

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue5412>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to