generic object - moving toward PEP

Discussion in 'Python' started by Steven Bethard, Nov 19, 2004.

  1. 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
     
    Steven Bethard, Nov 19, 2004
    #1
    1. Advertising

  2. Steven Bethard <> 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
     
    Dieter Maurer, Nov 21, 2004
    #2
    1. Advertising

  3. 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
     
    Reinhold Birkenfeld, Nov 21, 2004
    #3
  4. Steven Bethard

    Steve Holden Guest

    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
     
    Steve Holden, Nov 21, 2004
    #4
  5. Steven Bethard

    Paul McGuire Guest

    "Steven Bethard" <> 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
     
    Paul McGuire, Nov 21, 2004
    #5
  6. 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
     
    Steven Bethard, Nov 21, 2004
    #6
  7. 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
     
    Steven Bethard, Nov 21, 2004
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Frankie

    OT: Toward WYSIWYG Web Page Authoring

    Frankie, Oct 2, 2005, in forum: ASP .Net
    Replies:
    4
    Views:
    406
    Mr Newbie
    Oct 2, 2005
  2. Christoph Becker-Freyseng

    PEP for new modules (I read PEP 2)

    Christoph Becker-Freyseng, Jan 15, 2004, in forum: Python
    Replies:
    3
    Views:
    375
    Gerrit Holl
    Jan 16, 2004
  3. Jeremy Bowers
    Replies:
    18
    Views:
    451
    Nick Coghlan
    Feb 13, 2005
  4. Lie
    Replies:
    25
    Views:
    742
    Dafydd Hughes
    Dec 18, 2007
  5. Roedy Green

    Toward a generic Disk Sort for Java

    Roedy Green, Jun 26, 2008, in forum: Java
    Replies:
    14
    Views:
    984
    Martin Gregorie
    Jun 28, 2008
Loading...

Share This Page