generic object - moving toward PEP

[Steven Bethard]

So I thought I'd try to summarize a few things here and maybe we can
move toward filing a PEP. I'm not really sure I'm the right person to
champion it because, as I've mentioned, I usually eventually replace
generic objects with concrete classes, but I'm certainly willing to do
some of the work writing it up, etc. If you're interested in helping
me, let me know (off-list).

Some quotes from this thread:

> It seems odd that there is no standard generic object in Python.

> IPython has this fairly fancy Struct module, which is yet-another-shot
> at the same thing. [snip]
> But if someone does add a fully functional contribution of this kind,
> with enough bells and whistles to cover the more advanced cases, I'd
> be +100 on that

Some arguments for a generic object:

(1) Allows a simple syntax for returning named results:
.... return bunch(double=2*x, squared=x**2)
....100

(2) Allows simple representation of hierarchical data:
100

Note that without a generic object class of some sort this would
probably be written as something like:
.... def __init__(self, a, d):
.... self.a, self.d = a, d
.... .... def __init__(self, b, c):
.... self.b, self.c = b, c
....
Because the generic object version requires only one class (called
'bunch' above), only this class would be needed for
unpickling/unserializing. If the generic object class was easily
available (e.g. in the standard library), this could simplify the
unpickling process somewhat.

(3) Allows simple conversion from dict-style access to attribute access:

>>> d = {'a':2, 'b':4, 'c':16, 'd':256}
>>> d['a'], d['d'] (2, 256)
>>> b = bunch(**d)
>>> b.a, b.d

(2, 256)

This could actually be supported recursively, if that seems useful:
16



I think that's most of the arguments I saw on the thread. If anyone
else has arguments for/against adding a generic object type to the
standard lib, now's the time to bring them up. =)

Steve

 

[Dieter Maurer]

...
Some arguments for a generic object:

(1) Allows a simple syntax for returning named results:
.... return bunch(double=2*x, squared=x**2)
....100

(2) Allows simple representation of hierarchical data:
100
...
(3) Allows simple conversion from dict-style access to attribute access:

d = {'a':2, 'b':4, 'c':16, 'd':256}
d['a'], d['d'] (2, 256)
b = bunch(**d)
b.a, b.d

(2, 256)

This could actually be supported recursively, if that seems useful:
16

How about:

class bunch:
def __init__(self, d__=None, **kw):
d = self.__dict__
if d__ is not None: d.update(d__)
d.update(kw)


You can drop the "d__" magic, when you do not need direct
"dict --> bunch" conversion (of the form "bunch(dict)")
but use a special method ("frommapping") for this.

 

[Reinhold Birkenfeld]

So I thought I'd try to summarize a few things here and maybe we can
move toward filing a PEP. I'm not really sure I'm the right person to
champion it because, as I've mentioned, I usually eventually replace
generic objects with concrete classes, but I'm certainly willing to do
some of the work writing it up, etc. If you're interested in helping
me, let me know (off-list).

+1 on this. Would be great (would it be possible to add to 2.4 still?)

Reinhold

 

[Steve Holden]

+1 on this. Would be great (would it be possible to add to 2.4 still?)

Not with a release candidate in distribution, no - only "must-fix"
changes will be made before 2.4 final.

regards
Steve

 

[Paul McGuire]

(3) Allows simple conversion from dict-style access to attribute access:

d = {'a':2, 'b':4, 'c':16, 'd':256}
d['a'], d['d'] (2, 256)
b = bunch(**d)
b.a, b.d

(2, 256)

This could actually be supported recursively, if that seems useful:
16

Steven -

This sounds *very* much like the ParseResults class that I implemented in
pyparsing. For a given set of results from a parsing operation, one can
access them:
- as a list (tokens[0], tokens[1], ...)
- as a dict (tokens["name"], tokens["phoneNum"], ...)
- as attributes (tokens.name, tokens.phoneNum, ...)

I started out just returning lists of tokens, but found that it was
important to support some level of naming to the returned tokens -
otherwise, maintenance in the face of modifying grammars became very
difficult. For example, if an optional token were inserted between name and
phoneNum, now one would need to do a lot of testing on number and types of
returned tokens - very messy! Instead, the tokens are given names as
defined in the grammar specification, so that intervening syntax doesn't
mess things up.

Then, I added the attributes-style access because it looks more Pythonic.

ParseResults can also be accessed recursively. If phoneNum were defined
with sub-fields, one could access tokens.phoneNum.areaCode or
tokens["phoneNum"]["areaCode"], for example.

As an afterthought, I then added an XML output format for this class, so
that tokens.asXML("PERSONAL_DATA") would generate:
<PERSONAL_DATA>
<name>John Doe</name>
<phoneNum>555-1212</phoneNum>
</PERSONAL_DATA>

ParseResults defines quite a number of operators for managing and
manipulating ParseResults objects. I think this class may give you some
ideas about your bunch class. I guess some of the code may appear kludgey,
such as the __new__ handling, but it seems to be holding up reasonably well.

HTH,
-- Paul

 

[Steven Bethard]

Not with a release candidate in distribution, no - only "must-fix"
changes will be made before 2.4 final.

Yeah, this is definitely targeted at 2.5.

The other Steve

 

[Steven Bethard]

This sounds *very* much like the ParseResults class that I implemented in
pyparsing. For a given set of results from a parsing operation, one can
access them:
- as a list (tokens[0], tokens[1], ...)
- as a dict (tokens["name"], tokens["phoneNum"], ...)
- as attributes (tokens.name, tokens.phoneNum, ...) [snip]
As an afterthought, I then added an XML output format for this class, so
that tokens.asXML("PERSONAL_DATA") would generate:
<PERSONAL_DATA>
<name>John Doe</name>
<phoneNum>555-1212</phoneNum>
</PERSONAL_DATA>

Yeah, the last time I really wanted this, it was because I had an XML
document and wanted a somewhat more convenient access pattern than SAX
or DOM... I'll definitely check out your ParseResults class before I
try to submit a patch. Thanks!

Steve