By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,246 Members | 2,131 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,246 IT Pros & Developers. It's quick & easy.

generic object - moving toward PEP

P: n/a
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:

Hung Jung Lu wrote:
It seems odd that there is no standard generic object in Python.
Fernando Perez wrote: 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:
def f(x): .... return bunch(double=2*x, squared=x**2)
.... y = f(10)
y.double 20 y.squared 100

(2) Allows simple representation of hierarchical data:
x = bunch(a=bunch(b=1, c=10), d=100)
x.a.b 1 x.d 100

Note that without a generic object class of some sort this would
probably be written as something like:
class C1(object): .... def __init__(self, a, d):
.... self.a, self.d = a, d
.... class C2(object): .... def __init__(self, b, c):
.... self.b, self.c = b, c
.... x = C1(a=C2(b=1, c=10), d=100)
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:
d = {'a':2, 'b':4, 'c':{'d':16, 'e':256}}
b = bunch.frommapping(d)
b.c.d

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
Jul 18 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Steven Bethard <st************@gmail.com> writes on Fri, 19 Nov 2004 21:38:14 GMT:
...
Some arguments for a generic object:

(1) Allows a simple syntax for returning named results:
>>> def f(x): .... return bunch(double=2*x, squared=x**2)
.... >>> y = f(10)
>>> y.double 20 >>> y.squared 100

(2) Allows simple representation of hierarchical data:
>>> x = bunch(a=bunch(b=1, c=10), d=100)
>>> x.a.b 1 >>> x.d 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:
>>> d = {'a':2, 'b':4, 'c':{'d':16, 'e':256}}
>>> b = bunch.frommapping(d)
>>> b.c.d

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.

--
Dieter
Jul 18 '05 #2

P: n/a
Steven Bethard wrote:
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

--
[Windows ist wie] die Bahn: Man muss sich um nichts kuemmern, zahlt fuer
jede Kleinigkeit einen Aufpreis, der Service ist mies, Fremde koennen
jederzeit einsteigen, es ist unflexibel und zu allen anderen Verkehrs-
mitteln inkompatibel. -- Florian Diesch in dcoulm
Jul 18 '05 #3

P: n/a
Reinhold Birkenfeld wrote:
Steven Bethard wrote:
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?)


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

regards
Steve
--
http://www.holdenweb.com
http://pydish.holdenweb.com
Holden Web LLC +1 800 494 3119
Jul 18 '05 #4

P: n/a
"Steven Bethard" <st************@gmail.com> wrote in message
news:aJtnd.118100$HA.81413@attbi_s01...
<snip>
(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:
>>> d = {'a':2, 'b':4, 'c':{'d':16, 'e':256}}
>>> b = bunch.frommapping(d)
>>> b.c.d

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
Jul 18 '05 #5

P: n/a
Steve Holden wrote:
Reinhold Birkenfeld wrote:
+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.


Yeah, this is definitely targeted at 2.5.

The other Steve
Jul 18 '05 #6

P: n/a
Paul McGuire wrote:

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
Jul 18 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.