list/tuple to dict...

Discussion in 'Python' started by Pierre Fortin, Sep 15, 2004.

  1. Hi,

    Is the following a reasonable generic approach for converting python
    returned tuples/lists into dicts...? I'm not advocating library functions
    also return dicts (I'd probably spend more time looking up the real
    names... :) I'm just looking to make my code more readable and
    self-documenting...


    --------
    class todict:
    """ Converts a list/tuple to a dict: foo = todict(values,names) """
    def __init__(self,values,names):
    self.d = {}
    for i,name in enumerate(names.split(",")):
    self.d[name.strip()]=values
    def __setitem__(self, name, value):
    self.d[name]=value
    def __getitem__(self, name):
    return self.d[name]

    import os

    # called this way, I can see what is returned in what order
    uname = todict(os.uname(), "sysname, nodename,release,version, machine")

    filename = "/etc/passwd"
    osstat = todict(os.stat("%s" % filename),
    "mode,inode,dev,nlink,uid,gid,size,atime,mtime,ctime")
    osstat['filename'] = filename

    print "You're running %(sysname)s %(release)s on %(nodename)s" % uname
    # mtime needs formatting...
    print "File '%(filename)s' was last modified %(mtime)s" % osstat
    ---------
    Returns:
    You're running Linux 2.6.3-15mdk on gypsy.pfortin.com
    File '/etc/passwd' was last modified 1080568025

    A number of values are set and not used; though I think it's a small
    price to pay for making the results of lists/tuples more readable and
    useful...

    Over time, I'll probably build a list of functions I use and just
    copy/paste the line(s) I need:

    ~/pytemplates:
    osstat = todict(os.stat("%s" % path),
    "mode,inode,dev,nlink,uid,gid,size,atime,mtime,ctime")
    uname = todict(os.uname(),
    "sysname, nodename,release,version, machine")
    etc...

    The only part I still don't like is:
    osstat['filename'] = filename

    Is there a way to rewrite the class to allow for calls which take parms to
    include the parms in the resulting dict..? I'm probably trying to get too
    cute here though... :^)

    The newbie who gets to read (maintain?) my code should have an easier
    time; at least, that's my intent... Though Alex will probably consider
    this boilerplating... I think .some. boilerplating is good... B-]

    Other suggestions welcome :^)

    Thanks,
    Pierre
    Pierre Fortin, Sep 15, 2004
    #1
    1. Advertising

  2. Pierre Fortin wrote:

    > osstat = todict(os.stat("%s" % path),
    > "mode,inode,dev,nlink,uid,gid,size,atime,mtime,ctime")
    > uname = todict(os.uname(),
    > "sysname, nodename,release,version, machine")


    Use

    dict(zip(["mode,inode,dev,nlink,uid,gid,size,atime,mtime,ctime"],
    os.stat("%s" % path)))


    --
    Regards,

    Diez B. Roggisch
    Diez B. Roggisch, Sep 15, 2004
    #2
    1. Advertising

  3. [Pierre Fortin]
    > > I'm just looking to make my code more readable and
    > > self-documenting...

    . . .
    > > osstat = todict(os.stat("%s" % path),
    > > "mode,inode,dev,nlink,uid,gid,size,atime,mtime,ctime")


    [Diez B. Roggisch]
    > Use
    >
    > dict(zip(["mode,inode,dev,nlink,uid,gid,size,atime,mtime,ctime"],
    > os.stat("%s" % path)))


    Why build the dictionary at all. Use the named attributes provided by os.stat:

    mode = os.stat(f).st_mode

    That should meet the original readability goals.


    Raymond Hettinger
    Raymond Hettinger, Sep 15, 2004
    #3
  4. On Wed, 15 Sep 2004 22:58:26 GMT Raymond wrote:

    > [Pierre Fortin]
    > > > I'm just looking to make my code more readable and
    > > > self-documenting...

    > . . .
    > > > osstat = todict(os.stat("%s" % path),
    > > > "mode,inode,dev,nlink,uid,gid,size,atime,mtime,ctim
    > > > e")

    >
    > [Diez B. Roggisch]
    > > Use
    > >
    > > dict(zip(["mode,inode,dev,nlink,uid,gid,size,atime,mtime,ctime"],
    > > os.stat("%s" % path)))


    What does zip() have to do with this situation...?


    > Why build the dictionary at all. Use the named attributes provided by
    > os.stat:
    >
    > mode = os.stat(f).st_mode
    >
    > That should meet the original readability goals.


    That'll teach me to use examples that already have named attributes... :^)
    I'm looking to do this generically -- ignore the few that do have named
    attributes; there are plenty without that I'd like to address...

    The goal is to use the dict in string mapping keys as indicated in my
    original post.
    Pierre Fortin, Sep 16, 2004
    #4
  5. Pierre Fortin

    Peter Otten Guest

    Pierre Fortin wrote:

    >> > dict(zip(["mode,inode,dev,nlink,uid,gid,size,atime,mtime,ctime"],
    >> > os.stat("%s" % path)))

    >
    > What does zip() have to do with this situation...?


    It combines the items in the names list with the os.stat() result tuple to a
    list of (name, value) pairs that are then used to initialize the
    dictionary. For example:

    >>> name_value_pairs = zip(["name1", "name2", "nameN"], ["va11", "val2",

    "valN"])
    >>> name_value_pairs

    [('name1', 'va11'), ('name2', 'val2'), ('nameN', 'valN')]
    >>> dict(name_value_pairs)

    {'nameN': 'valN', 'name2': 'val2', 'name1': 'va11'}


    >> Why build the dictionary at all. Use the named attributes provided by
    >> os.stat:
    >>
    >> mode = os.stat(f).st_mode
    >>
    >> That should meet the original readability goals.

    >
    > That'll teach me to use examples that already have named attributes... :^)
    > I'm looking to do this generically -- ignore the few that do have named
    > attributes; there are plenty without that I'd like to address...
    >
    > The goal is to use the dict in string mapping keys as indicated in my
    > original post.


    You can still do that while relying on the existing names:

    >>> class ObjectAsDictAdapter:

    .... def __init__(self, obj):
    .... self.obj = obj
    .... def __getitem__(self, key):
    .... return getattr(self.obj, key)
    ....
    >>> import os
    >>> st = os.stat("tmp.py")
    >>> "%(st_mtime)s %(st_size)s" % ObjectAsDictAdapter(st)

    '1095318348 2'
    >>>


    You can easily add an analogous

    def __setitem__(self, key, value):
    setattr(self.obj, key, value)

    but it won't work in the above example as the stat tuple is immutable.
    If you need other attributes (like filename in your original post) you can
    solve that with Raymond Hettinger's Chainmap

    http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/305268

    #untested
    "%(filename)s %(st_size)s" % Chainmap(ObjectAsDictAdapter(st),
    dict(filename=filename))

    Peter
    Peter Otten, Sep 16, 2004
    #5
  6. Pierre Fortin <> wrote:
    ...
    > class todict:
    > """ Converts a list/tuple to a dict: foo = todict(values,names) """
    > def __init__(self,values,names):
    > self.d = {}
    > for i,name in enumerate(names.split(",")):
    > self.d[name.strip()]=values
    > def __setitem__(self, name, value):
    > self.d[name]=value
    > def __getitem__(self, name):
    > return self.d[name]


    You can implement this exact functionality (not worth it for os.stat, of
    course, which already does return a pseudotuple with named items) in a
    probably better way...:

    import itertools

    ...

    def __init__(self, values, names):
    self.d = dict(itertools.izip(
    map(str.strip, names.split(',')),
    values))

    However, as recently discussed on this group, this is going to put a
    dictionary in EVERY instance of 'todict' dealing with the same sequence
    of names. Normally when you deal with tuples whose items have certain
    names, you will deal with a lot of such tuples with the same item names.
    It seems better to me to make a TYPE which deals with the name-to-index
    mapping, then instantiate that type as needed with tuples of values.

    > Over time, I'll probably build a list of functions I use and just
    > copy/paste the line(s) I need:


    Copy and paste is a BAD way to reuse software. Very, very bad. Anybody
    with the least experience maintaining big programs will confirm.

    > Is there a way to rewrite the class to allow for calls which take parms to
    > include the parms in the resulting dict..? I'm probably trying to get too
    > cute here though... :^)


    You can easily add keyword args to the __init__:

    def __init__(self, values, names, **kw):
    self.d = dict(itertools.izip(
    map(str.strip, names.split(',')),
    values), **kw)

    This way you can set extra parameters as you instantiate todict.


    > The newbie who gets to read (maintain?) my code should have an easier
    > time; at least, that's my intent... Though Alex will probably consider
    > this boilerplating... I think .some. boilerplating is good... B-]
    >
    > Other suggestions welcome :^)


    My suggestion is to rethink your thesis that some boilerplate is good.
    The first time in your life you must make a change and hunt down every
    place you have c&p'd your boilerplate -- forget some place and get
    anomalies -- etc, etc -- you'll see why. But why _must_ some people
    make themselves the mistakes many previous generations have already
    made, when members of those older generations keep alerting them to said
    mistakes? Can't you be original and make YOUR OWN brand-new mistakes?!

    Ah well. Making a specific type for each given sequence of item names
    is clearer, conceptually preferable, faster, not wasteful of memory, and
    lacks any countervailing counterindication -- yet you like boilerplate,
    you like copy and paste, and _want_ all of the overheads you pay to get
    them. OK, I'm not going to repeat once again the details on how to make
    a type -- I must have posted them three times over the last 10 days or
    so, enough is enough. Just one last attempt at motivation in case you
    are at all superstitious...: should anybody else ever find themselves
    maintaining your sw and find out that you DELIBERATELY inflicted this
    chore on them because of your preference for boilerplate and c&p over
    cleaner and lighter-weight approaches, don't be surprised if your tea
    kettles never boil, your cat scratches you, and you find yourself having
    to get new tires often because you keep hitting nails and shards of
    glass on the street... it's just the MILDEST kind of curses those poor
    software maintainers are streaming towards you constantly, starting to
    work on the astral plane... ((ok, ok, I don't necessarily _believe_
    this, but hey, if anybody does and I can thereby motivate them to write
    better sw than they otherwise would, why, I think that's justification
    enough for this little white, ahem, working hypothesis I'm
    presenting!-))


    Alex
    Alex Martelli, Sep 16, 2004
    #6
  7. Pierre Fortin wrote:

    > On Wed, 15 Sep 2004 22:58:26 GMT Raymond wrote:
    >
    >> [Pierre Fortin]
    >> > > I'm just looking to make my code more readable and
    >> > > self-documenting...

    >> . . .
    >> > > osstat = todict(os.stat("%s" % path),
    >> > > "mode,inode,dev,nlink,uid,gid,size,atime,mtime,ctim
    >> > > e")

    >>
    >> [Diez B. Roggisch]
    >> > Use
    >> >
    >> > dict(zip(["mode,inode,dev,nlink,uid,gid,size,atime,mtime,ctime"],
    >> > os.stat("%s" % path)))

    >
    > What does zip() have to do with this situation...?


    Uhm - its needed?

    It creates a list of pairs from the two argument lists, and dict() takes a
    list of pairs of (key, value) to form a dictionary.

    --
    Regards,

    Diez B. Roggisch
    Diez B. Roggisch, Sep 16, 2004
    #7
  8. Pierre Fortin

    Steve Holden Guest

    Alex Martelli wrote:

    > Pierre Fortin <> wrote:
    > ...

    [...]
    >
    >>Over time, I'll probably build a list of functions I use and just
    >>copy/paste the line(s) I need:

    >
    >
    > Copy and paste is a BAD way to reuse software. Very, very bad. Anybody
    > with the least experience maintaining big programs will confirm.
    >

    Yup. Make a mistake before c&p and you then have two places to fix it
    rather than one. Or three, or four, or an unknown number ...

    >
    >>Is there a way to rewrite the class to allow for calls which take parms to
    >>include the parms in the resulting dict..? I'm probably trying to get too
    >>cute here though... :^)

    >
    >
    > You can easily add keyword args to the __init__:
    >
    > def __init__(self, values, names, **kw):
    > self.d = dict(itertools.izip(
    > map(str.strip, names.split(',')),
    > values), **kw)
    >
    > This way you can set extra parameters as you instantiate todict.
    >
    >
    >
    >>The newbie who gets to read (maintain?) my code should have an easier
    >>time; at least, that's my intent... Though Alex will probably consider
    >>this boilerplating... I think .some. boilerplating is good... B-]
    >>
    >>Other suggestions welcome :^)

    >
    >
    > My suggestion is to rethink your thesis that some boilerplate is good.
    > The first time in your life you must make a change and hunt down every
    > place you have c&p'd your boilerplate -- forget some place and get
    > anomalies -- etc, etc -- you'll see why. But why _must_ some people
    > make themselves the mistakes many previous generations have already
    > made, when members of those older generations keep alerting them to said
    > mistakes? Can't you be original and make YOUR OWN brand-new mistakes?!
    >

    One of the nicest things about c.l.py is its ability to soak up endless
    repetitions of the same enquiries from newcomers and remain (almost)
    unfailingly polite. I sense you are holding sclerotic tendencies in
    check with the utmost self-control here - well done! Humor, that's the
    trick.

    > Ah well. Making a specific type for each given sequence of item names
    > is clearer, conceptually preferable, faster, not wasteful of memory, and
    > lacks any countervailing counterindication -- yet you like boilerplate,
    > you like copy and paste, and _want_ all of the overheads you pay to get
    > them.


    More accurately, probably hasn't yet written enough code to appreciate
    the disadvantages of cut-and-paste methods. And I hope, now clued-up b y
    a master, likely to eschew the vile habit forthwith.

    > OK, I'm not going to repeat once again the details on how to make
    > a type -- I must have posted them three times over the last 10 days or
    > so, enough is enough. Just one last attempt at motivation in case you
    > are at all superstitious...: should anybody else ever find themselves
    > maintaining your sw and find out that you DELIBERATELY inflicted this
    > chore on them because of your preference for boilerplate and c&p over
    > cleaner and lighter-weight approaches, don't be surprised if your tea
    > kettles never boil, your cat scratches you, and you find yourself having
    > to get new tires often because you keep hitting nails and shards of
    > glass on the street... it's just the MILDEST kind of curses those poor
    > software maintainers are streaming towards you constantly, starting to
    > work on the astral plane... ((ok, ok, I don't necessarily _believe_
    > this, but hey, if anybody does and I can thereby motivate them to write
    > better sw than they otherwise would, why, I think that's justification
    > enough for this little white, ahem, working hypothesis I'm
    > presenting!-))
    >

    If only there were some way we could avoid having to repeat good advice
    so often (to avoid cutting and pasting it into so many c.l.py answers,
    for example).

    Don't forget to take your blood-pressure medication :)

    just-heard-the-kettle-boiling-ly y'rs - steve
    Steve Holden, Sep 16, 2004
    #8
  9. Pierre Fortin

    Roy Smith Guest

    (Alex Martelli) wrote:
    > Copy and paste is a BAD way to reuse software. Very, very bad. Anybody
    > with the least experience maintaining big programs will confirm.


    Absolutely agree.

    A while ago, I was working on a piece of code written by somebody who
    didn't believe in this. I found a bug and fixed it. Sometime later, we
    realized the fix was wrong and I went back to make an additional change.

    I was surprised when the file I was looking at appeared to be the
    original code. Where had my first change gone? We spent an afternoon
    looking through CVS logs, getting ourselves more and more convinced that
    CVS had somehow messed up.

    It turns out, the fix I made was in a huge function (100's of lines)
    which somebody had cut-and-pasted to make three versions which did
    almost identical things. And then they gave the functions almost
    identical names, along the lines of:

    sendMessageToServerWithAlertCondition ()
    sendMessageToServerWithErrorCondition ()
    sendMessageToServerWithOtherCondition ()

    So, yeah, Alex is right. Don't do that.
    Roy Smith, Sep 16, 2004
    #9
  10. Steve Holden <> wrote:
    ...
    > Don't forget to take your blood-pressure medication :)
    >
    > just-heard-the-kettle-boiling-ly y'rs - steve


    Heh -- thanks Steve, but you misinterpreted, that was just Anna making
    tea;-). I'm just going to take some Maalox... the pressure is fine!-)


    Alex
    Alex Martelli, Sep 16, 2004
    #10
  11. Pierre Fortin

    phansen Guest

    Steve Holden: mail problem? (was Re: list/tuple to dict...)

    Steve Holden wrote:
    [some stuff]

    Steve, I tried replying via email with a content-free
    response but got back a message that suggests your
    mail server might be having troubles. The bounce
    comes from postmaster at your site, and says
    "User mailbox exceeds allowed size: "

    Maybe you've got a "leave mail on server" checkbox ticked?

    -Peter
    phansen, Sep 16, 2004
    #11
  12. On Thu, 16 Sep 2004 09:24:16 +0200 Peter wrote:

    > Pierre Fortin wrote:
    >
    > >> > dict(zip(["mode,inode,dev,nlink,uid,gid,size,atime,mtime,ctime"],
    > >> > os.stat("%s" % path)))

    > >
    > > What does zip() have to do with this situation...?

    >
    > It combines the items in the names list with the os.stat() result tuple
    > to a list of (name, value) pairs that are then used to initialize the
    > dictionary. For example:
    >
    > >>> name_value_pairs = zip(["name1", "name2", "nameN"], ["va11", "val2",

    > "valN"])
    > >>> name_value_pairs

    > [('name1', 'va11'), ('name2', 'val2'), ('nameN', 'valN')]
    > >>> dict(name_value_pairs)

    > {'nameN': 'valN', 'name2': 'val2', 'name1': 'va11'}


    Ah... your former example wasn't as obvious since "mode,inode...." was a
    single string and produced different results... Hadn't seen zip before
    now and thought it was a compression thingy... :>


    > >> Why build the dictionary at all. Use the named attributes provided

    > >by> os.stat:
    > >>
    > >> mode = os.stat(f).st_mode
    > >>
    > >> That should meet the original readability goals.

    > >
    > > That'll teach me to use examples that already have named attributes...
    > > :^) I'm looking to do this generically -- ignore the few that do have
    > > named attributes; there are plenty without that I'd like to address...
    > >
    > > The goal is to use the dict in string mapping keys as indicated in my
    > > original post.

    >
    > You can still do that while relying on the existing names:


    True... but again, my point is that this was a bad example... I'm
    looking to use the concept where there are no "existing names"

    > Peter


    Thanks,
    Pierre
    Pierre Fortin, Sep 16, 2004
    #12
  13. On Thu, 16 Sep 2004 12:47:16 +0200 Diez wrote:

    > > What does zip() have to do with this situation...?

    >
    > Uhm - its needed?
    >
    > It creates a list of pairs from the two argument lists, and dict() takes
    > a list of pairs of (key, value) to form a dictionary.


    Thanks.... I see what was intended now... the example needed to work on a
    split string, not the one I'd provided... simply running his example
    failed and I should have read the zip() docs and debugged it...
    Pierre Fortin, Sep 16, 2004
    #13
  14. Pierre Fortin

    Steve Holden Guest

    Re: Steve Holden: mail problem? (was Re: list/tuple to dict...)

    phansen wrote:

    > Steve Holden wrote:
    > [some stuff]
    >
    > Steve, I tried replying via email with a content-free
    > response but got back a message that suggests your
    > mail server might be having troubles. The bounce
    > comes from postmaster at your site, and says
    > "User mailbox exceeds allowed size: "
    >
    > Maybe you've got a "leave mail on server" checkbox ticked?
    >
    > -Peter


    I'm not actually using that address any more, having received over
    40,000 emails in a thirty-day period. I guess to keep the auto-responder
    working I need to flush the content periodically. Sigh. F*****g spammers.

    I've changed my Reply-to address now - thanks!

    regards
    Steve
    Steve Holden, Sep 16, 2004
    #14
  15. Pierre Fortin

    Aahz Guest

    Re: Steve Holden: mail problem? (was Re: list/tuple to dict...)

    In article <1Dh2d.5820$Xc.5095@lakeread01>,
    Steve Holden <> wrote:
    >
    >I've changed my Reply-to address now - thanks!


    No, you didn't. ;-) Did you mean that you've changed your From: line?
    --
    Aahz () <*> http://www.pythoncraft.com/

    "A foolish consistency is the hobgoblin of little minds, adored by little
    statesmen and philosophers and divines." --Ralph Waldo Emerson
    Aahz, Sep 16, 2004
    #15
  16. Pierre Fortin

    Donn Cave Guest

    In article <>,
    Roy Smith <> wrote:

    > (Alex Martelli) wrote:
    > > Copy and paste is a BAD way to reuse software. Very, very bad. Anybody
    > > with the least experience maintaining big programs will confirm.

    >
    > Absolutely agree.
    >
    > A while ago, I was working on a piece of code written by somebody who
    > didn't believe in this. I found a bug and fixed it. Sometime later, we
    > realized the fix was wrong and I went back to make an additional change.
    >
    > I was surprised when the file I was looking at appeared to be the
    > original code. Where had my first change gone? We spent an afternoon
    > looking through CVS logs, getting ourselves more and more convinced that
    > CVS had somehow messed up.
    >
    > It turns out, the fix I made was in a huge function (100's of lines)
    > which somebody had cut-and-pasted to make three versions which did
    > almost identical things. And then they gave the functions almost
    > identical names, along the lines of:
    >
    > sendMessageToServerWithAlertCondition ()
    > sendMessageToServerWithErrorCondition ()
    > sendMessageToServerWithOtherCondition ()
    >
    > So, yeah, Alex is right. Don't do that.


    Sure, don't do _that_. But do you think anyone might be
    able to come up with cases where software has been unnecessarily
    fragile because of a compulsive desire to avoid repeating a
    line of similar code anywhere? Don't do that, either!

    Donn Cave,
    Donn Cave, Sep 16, 2004
    #16
  17. On Thu, 16 Sep 2004 10:16:28 +0200, (Alex Martelli) wrote:

    >Pierre Fortin <> wrote:
    > ...
    >> class todict:
    >> """ Converts a list/tuple to a dict: foo = todict(values,names) """
    >> def __init__(self,values,names):
    >> self.d = {}
    >> for i,name in enumerate(names.split(",")):
    >> self.d[name.strip()]=values
    >> def __setitem__(self, name, value):
    >> self.d[name]=value
    >> def __getitem__(self, name):
    >> return self.d[name]

    >
    >You can implement this exact functionality (not worth it for os.stat, of
    >course, which already does return a pseudotuple with named items) in a
    >probably better way...:
    >

    [...]

    Perhaps pseudo-tuples that support attribute-name access to elements could
    have a __getitem__ that would accept integers in the index way, and strings
    as a mapping-like alternative to attribute accesses of the same name.

    That way
    '%(st_size)s' % os.stat(filename)
    would work.

    And if str.__mod__ were modified to have a %** format to establish the corresponding
    argument as the effective mapping for string keys yet worked normally from the tuple
    for unnamed arguments, then you could write

    '%**%(st_size) is the size of file %r' % (os.stat(filename), filename)

    or putting the mapping object in the middle works too, so long as it's before named stuff:

    'File %r is %**%(st_size) long. (full path %r)' % (
    filename, os.stat(filename), os.path.abspath(filename))

    you could even entertain multiple mapping objects by specifying %** as you needed new ones.
    I think this could be made backwards compatible, since without %** mapping arguments would
    either get used or get repr'd, depending, as now.

    Regards,
    Bengt Richter
    Bengt Richter, Sep 16, 2004
    #17
  18. On 16 Sep 2004 19:15:42 GMT Bengt wrote:

    > On Thu, 16 Sep 2004 10:16:28 +0200, (Alex Martelli)
    > wrote:
    >
    > >Pierre Fortin <> wrote:
    > > ...
    > >> class todict:
    > >> """ Converts a list/tuple to a dict: foo = todict(values,names)

    > >"""> def __init__(self,values,names):
    > >> self.d = {}
    > >> for i,name in enumerate(names.split(",")):
    > >> self.d[name.strip()]=values
    > >> def __setitem__(self, name, value):
    > >> self.d[name]=value
    > >> def __getitem__(self, name):
    > >> return self.d[name]

    > >
    > >You can implement this exact functionality (not worth it for os.stat,
    > >of course, which already does return a pseudotuple with named items) in
    > >a probably better way...:
    > >

    > [...]
    >
    > Perhaps pseudo-tuples that support attribute-name access to elements
    > could have a __getitem__ that would accept integers in the index way,
    > and strings as a mapping-like alternative to attribute accesses of the
    > same name.
    >
    > That way
    > '%(st_size)s' % os.stat(filename)
    > would work.


    Right!


    > And if str.__mod__ were modified to have a %** format to establish the
    > corresponding argument as the effective mapping for string keys yet
    > worked normally from the tuple for unnamed arguments, then you could
    > write
    >
    > '%**%(st_size) is the size of file %r' % (os.stat(filename),
    > filename)
    >
    > or putting the mapping object in the middle works too, so long as it's
    > before named stuff:
    >
    > 'File %r is %**%(st_size) long. (full path %r)' % (
    > filename, os.stat(filename), os.path.abspath(filename))


    Would there be a problem with %(key[,len[,prec]]) for the general case?
    Notwithstanding the fact that len and prec are positional in my example...
    :^) I'd prefer keeping everything together somehoe, rather than a new
    Perl-like 'wart'... but, I'd be pleased to see your attribute-name idea go
    forward either way...

    You don't mention how %** gets its values though... typically, I would
    use this for row upon row (column widths)...

    > you could even entertain multiple mapping objects by specifying %** as
    > you needed new ones. I think this could be made backwards compatible,
    > since without %** mapping arguments would either get used or get repr'd,
    > depending, as now.
    >
    > Regards,
    > Bengt Richter


    Thanks,
    Pierre
    Pierre Fortin, Sep 17, 2004
    #18
    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. Davy
    Replies:
    3
    Views:
    1,881
    Wildemar Wildenburger
    Nov 7, 2007
  2. Jeff Nyman
    Replies:
    8
    Views:
    375
    Terry Reedy
    Jun 5, 2008
  3. bruce

    list/tuple/dict question

    bruce, Aug 17, 2008, in forum: Python
    Replies:
    3
    Views:
    310
    Gabriel Genellina
    Aug 19, 2008
  4. Akira Kitada

    Pythonic list/tuple/dict layout?

    Akira Kitada, Jan 25, 2009, in forum: Python
    Replies:
    8
    Views:
    267
  5. Wells
    Replies:
    6
    Views:
    4,358
    Syeberman
    Nov 10, 2009
Loading...

Share This Page