list/tuple to dict...

[Pierre Fortin]

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

 

[Diez B. Roggisch]

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)))

 

[Raymond Hettinger]

[Pierre Fortin]
[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

 

[Pierre Fortin]

[Pierre Fortin]
[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.

 

[Peter Otten]

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'}

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:
.... def __init__(self, obj):
.... self.obj = obj
.... def __getitem__(self, key):
.... return getattr(self.obj, key)
....
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

 

[Alex Martelli]

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

 

[Diez B. Roggisch]

[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.

 

[Steve Holden]

... [...]

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

 

[Roy Smith]

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.

 

[Alex Martelli]

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

 

[phansen]

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: (e-mail address removed)"

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

-Peter

 

[Pierre Fortin]

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... :>

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]

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...

 

[Steve Holden]

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: (e-mail address removed)"

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

 

[Aahz]

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

No, you didn't. ;-) Did you mean that you've changed your From: line?

 

[Donn Cave]

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, (e-mail address removed)

 

[Bengt Richter]

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

 

[Pierre Fortin]

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