[Python-ideas] Dict-like object with property access

anatoly techtonik techtonik at gmail.com
Mon Jan 30 15:43:06 CET 2012


On Thu, Jan 26, 2012 at 8:47 PM, Guido van Rossum <guido at python.org> wrote:

> On Thu, Jan 26, 2012 at 9:25 AM, anatoly techtonik <techtonik at gmail.com>
> wrote:
> > I expected to find the answer to this question in FAQ, but because there
> is
> > no FAQ I ask it anyway.
> >
> > How about adding a new standard dict-like container type that allows
> access
> > using . (dot) to its members instead of ['index']?
> > Why? It is convenient to write options.help instead of options['halp']
> etc.
> >
> > Example:
> >>>> mydict = container(someprop=somevalue)
> >>>> mydict['someprop']
> > somevalue
> >>>> mydict.someprop
> > somevalue
> >>>> mydict.otherprop
> > Exception KeyError ...
> >
> > I know that it is easy to implement, but wouldn't it be nice to make it
> > available by default?
> > A side benefit of having this in stdlib is that newbies will be aware of
> the
> > behaviour of derived classes without having to understand the mechanics
> of
> > magic methods.
>
> That is pretty much JavaScript's 'object', and I hate this ambiguity.
> If your keys are always constants, define a proper options class so
> you can say options.help instead of options['help']. You can also
> write a generic subclass of dict that works this way, if you really
> think you like it so much. But please keep it out of the stdlib. It
> leads to confused users, not happy users. An example of the problems
> that arise: If d['a'] == d.a, then how come d['clear'] != d.clear ?


In which case d['clear'] != d.clear can be true?


I've found a MIT licensed library that implements just that:
http://pypi.python.org/pypi/bunch/

Q. Why it is better than subclass of object?
A. Because it is implicit.
-- 
anatoly t.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20120130/5f35f903/attachment.html>


More information about the Python-ideas mailing list