Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > generic object - moving toward PEP

Reply
Thread Tools

generic object - moving toward PEP

 
 
Steven Bethard
Guest
Posts: n/a
 
      11-19-2004
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
 
Reply With Quote
 
 
 
 
Dieter Maurer
Guest
Posts: n/a
 
      11-21-2004
Steven Bethard <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Reinhold Birkenfeld
Guest
Posts: n/a
 
      11-21-2004
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
 
Reply With Quote
 
Steve Holden
Guest
Posts: n/a
 
      11-21-2004
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
 
Reply With Quote
 
Paul McGuire
Guest
Posts: n/a
 
      11-21-2004
"Steven Bethard" <(E-Mail Removed)> 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


 
Reply With Quote
 
Steven Bethard
Guest
Posts: n/a
 
      11-21-2004
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
 
Reply With Quote
 
Steven Bethard
Guest
Posts: n/a
 
      11-21-2004
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Toward a generic Disk Sort for Java Roedy Green Java 14 06-28-2008 05:12 PM
Free Moving Estimate, Local Movers, Long Distance Moving, PackingSupplies, Storage Rental, Home Moving, Apartment Moving, Office Moving,Commercial Moving linkswanted ASP .Net 0 01-06-2008 04:45 AM
About Rational Number (PEP 239/PEP 240) Lie Python 25 12-18-2007 06:13 AM
namespaces module (a.k.a. bunch, struct, generic object, etc.) PEP Jeremy Bowers Python 18 02-13-2005 04:50 AM
PEP for new modules (I read PEP 2) Christoph Becker-Freyseng Python 3 01-16-2004 04:26 PM



Advertisments