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

list/tuple to dict...

P: n/a
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[i]
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,cti me")
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,cti me")
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

Jul 18 '05 #1
Share this Question
Share on Google+
17 Replies


P: n/a
Pierre Fortin wrote:
osstat = todict(os.stat("%s" % path),
"mode,inode,dev,nlink,uid,gid,size,atime,mtime,cti me")
uname = todict(os.uname(),
"sysname, nodename,release,version, machine")


Use

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

Diez B. Roggisch
Jul 18 '05 #2

P: n/a
[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,cti me")

[Diez B. Roggisch] Use

dict(zip(["mode,inode,dev,nlink,uid,gid,size,atime,mtime,cti me"],
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
Jul 18 '05 #3

P: n/a
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,cti m
e")

[Diez B. Roggisch]
Use

dict(zip(["mode,inode,dev,nlink,uid,gid,size,atime,mtime,cti me"],
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.
Jul 18 '05 #4

P: n/a
Pierre Fortin wrote:
> dict(zip(["mode,inode,dev,nlink,uid,gid,size,atime,mtime,cti me"],
> 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/Coo.../Recipe/305268

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

Peter
Jul 18 '05 #5

P: n/a
Pierre Fortin <pf*****@pfortin.com> 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[i]
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
Jul 18 '05 #6

P: n/a
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,cti m
> > e")


[Diez B. Roggisch]
> Use
>
> dict(zip(["mode,inode,dev,nlink,uid,gid,size,atime,mtime,cti me"],
> 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
Jul 18 '05 #7

P: n/a
Alex Martelli wrote:
Pierre Fortin <pf*****@pfortin.com> 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
Jul 18 '05 #8

P: n/a
al*****@yahoo.com (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.
Jul 18 '05 #9

P: n/a
Steve Holden <sh*****@holdenweb.com> 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
Jul 18 '05 #10

P: n/a
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: sh*****@mail.holdenweb.com"

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

-Peter
Jul 18 '05 #11

P: n/a
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,cti me"],
> 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
Jul 18 '05 #12

P: n/a
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...
Jul 18 '05 #13

P: n/a
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: sh*****@mail.holdenweb.com"

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

P: n/a
In article <1Dh2d.5820$Xc.5095@lakeread01>,
Steve Holden <st***@holdenweb.com> 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 (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"A foolish consistency is the hobgoblin of little minds, adored by little
statesmen and philosophers and divines." --Ralph Waldo Emerson
Jul 18 '05 #15

P: n/a
In article <ro***********************@reader1.panix.com>,
Roy Smith <ro*@panix.com> wrote:
al*****@yahoo.com (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, do**@u.washington.edu
Jul 18 '05 #16

P: n/a
On Thu, 16 Sep 2004 10:16:28 +0200, al*****@yahoo.com (Alex Martelli) wrote:
Pierre Fortin <pf*****@pfortin.com> 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[i]
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
Jul 18 '05 #17

P: n/a
On 16 Sep 2004 19:15:42 GMT Bengt wrote:
On Thu, 16 Sep 2004 10:16:28 +0200, al*****@yahoo.com (Alex Martelli)
wrote:
Pierre Fortin <pf*****@pfortin.com> 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[i]
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
Jul 18 '05 #18

This discussion thread is closed

Replies have been disabled for this discussion.