Let's take following perl code snippet:
%myhash=( one => 1 , two => 2 , three => 3 );
($v1,$v2,$v3) = @myhash{qw(one two two)}; # <-- line of interest
print "$v1\n$v2\n$v2\n";
How do I translate the second line in a similiar compact way to
python?
Below is what I tried. I'm just interested in something more compact.
mydict={ 'one' : 1 , 'two' : 2 , 'three' : 3 }
# first idea, but still a little too much to type
[v1,v2,v3] = [ mydict[k] for k in ['one','two','two']]
# for long lists lazier typing,but more computational intensive
# as split will probably be performed at runtime and not compilation
time
[v1,v2,v3] = [ mydict[k] for k in 'one two two'.split()]
print "%s\n%s\n%s" %(v1,v2,v3)
thanks for any ideas
What about:
>>> myhash={'one':1, 'two':2, 'three':3}
>>> map(myhash.get, ['one', 'two', 'two'])
[1, 2, 2]
>>>
or, to make it more similar to perl's qw() thing:
>>> map(myhash.get, 'one two two'.split())
[1, 2, 2]
>>>
...but I think that using explicit list is more pythonic.
Isn't it? ;)
--
Regards,
Wojtek Walczak,
http://tosh.pl/gminick/
Another option [note I'm not stating it's preferred, but it would
appear to be closer to some syntax that you'd prefer to use....]
>>> from operator import itemgetter
>>> x = { 'one' : 1, 'two' : 2, 'three' : 3 }
>>> itemgetter('one', 'one', 'two')(x)
(1, 1, 2)
hth
Jon.
and the point of doing that instead of calling mydict.values() is what?
</F>
It's more fun? Or if you want to sort by keys.
> Let's take following perl code snippet:
>
> %myhash=( one => 1 , two => 2 , three => 3 );
> ($v1,$v2,$v3) = @myhash{qw(one two two)}; # <-- line of interest
> print "$v1\n$v2\n$v2\n";
>
> How do I translate the second line in a similiar compact way to
> python?
>
> Below is what I tried. I'm just interested in something more compact.
Python does not try to be as compact as Perl. Pythoneers generally
consider that a feature. Anyway, the second Python version is
asymtotically as compact as the Perl code, differing only by a small
constant number of bytes while the code size grows.
> mydict={ 'one' : 1 , 'two' : 2 , 'three' : 3 }
> # first idea, but still a little too much to type
> [v1,v2,v3] = [ mydict[k] for k in ['one','two','two']]
The initial brackets add nothing. "v1,v2,v3 =" does the same.
>
> # for long lists lazier typing,but more computational intensive
> # as split will probably be performed at runtime and not compilation
> time
You have spent and will spend more time posting and reading than the
equivalent extra computation time this will take with any normal
exchange rate and computation usage.
> [v1,v2,v3] = [ mydict[k] for k in 'one two two'.split()]
This is a standard idiom for such things. If it bothers you, type "'one
two two'.split()" into an interactive window and 'in a blink' get
['one', 'two', 'two'], which you can cut and paste into a program.
> print "%s\n%s\n%s" %(v1,v2,v3)
However, more that about 3 numbered variables in a Python program
suggest the possibility of a better design, such as leaving the values
in a list vee and accessing them by indexing.
Terry Jan Reedy
> Let's take following perl code snippet:
>
> %myhash=( one => 1 , two => 2 , three => 3 );
> ($v1,$v2,$v3) = @myhash{qw(one two two)}; # <-- line of interest
> print "$v1\n$v2\n$v2\n";
>
> How do I translate the second line in a similiar compact way to
> python?
One point I haven't seen in the other responses is that, at least for the
example given, you don't need the second line at all:
mydict={ 'one': 1, 'two': 2, 'three': 3 }
print "%(one)s\n%(two)s\n%(two)s" % mydict
--
Duncan Booth http://kupuguy.blogspot.com
As an ex-perl programmer and having used python for some years now,
I'd type the explicit
v1,v2,v3 = mydict['one'], mydict['two'], mydict['two'] # 54 chars
Or maybe even
v1 = mydict['one'] # 54 chars
v2 = mydict['two']
v3 = mydict['two']
Either is only a couple more characters to type. It is completely
explicit and comprehensible to everyone, in comparison to
v1,v2,v3 = [ mydict[k] for k in ['one','two','two']] # 52 chars
v1,v2,v3 = [ mydict[k] for k in 'one two two'.split()] # 54 chars
Unlike perl, it will also blow up if mydict doesn't contain 'one'
which may or may not be what you want.
--
Nick Craig-Wood <ni...@craig-wood.com> -- http://www.craig-wood.com/nick
> As an ex-perl programmer and having used python for some years now, I'd
> type the explicit
>
> v1,v2,v3 = mydict['one'], mydict['two'], mydict['two'] # 54 chars
>
> Or maybe even
>
> v1 = mydict['one'] # 54 chars
> v2 = mydict['two']
> v3 = mydict['two']
>
> Either is only a couple more characters to type.
But that's an accident of the name you have used. Consider:
v1,v2,v3 = section_heading_to_table_index['one'], \
section_heading_to_table_index['two'], \
section_heading_to_table_index['two'] # 133 characters
versus:
v1,v2,v3 = [section_heading_to_table_index[k] for k in
['one','two','two']] # 75 characters
It also fails the "Don't Repeat Yourself" principle, and it completely
fails to scale beyond a handful of keys.
Out of interest, on my PC at least the list comp version is significantly
slower than the explicit assignments. So it is a micro-optimization that
may be worth considering if needed -- but at the cost of harder to
maintain code.
> It is completely
> explicit and comprehensible to everyone, in comparison to
>
> v1,v2,v3 = [ mydict[k] for k in ['one','two','two']] # 52 chars
> v1,v2,v3 = [ mydict[k] for k in 'one two two'.split()] # 54 chars
That's a matter for argument. I find the list comprehension perfectly
readable and comprehensible, and in fact I had to read your explicit
assignments twice to be sure I hadn't missed something. But I accept that
if you aren't used to list comps, they might look a little odd.
--
Steven
There's quite some things I learnt :-)
[v1,v2,v3] = ...
can be typed as
v1,v2,v3 = . . .
I also wasn't used to
map(myhash.get, ['one', 'two', 'two'])
itemgetter('one', 'one', 'two')(x)
I also didn't know
print "%(one)s\n%(two)s\n%(two)s" % mydict
The reason I'd like to have a short statement for above is, that this
is for me basically just
some code, to name and use certain fields of a hash in i given code
section.
The real example would be more like:
name,age,country = itemgetter('name age country'.split())(x) # or any
of my above versions
# a lot of code using name / age / country
thanks a gain and bye
H
Is your above solution robust against undefined keys.
In my example it would'nt be a problem. The dict would be fully
populated, but I'm just curious.
That solution is very clever, and the inventor smart, but it's too
much out of standard and complex to be used in normal real code.
Learning tricks is useful, but then in real code you have to use then
only once in a while. A list comp is quite more easy to understand for
Python programmers.
Bye,
bearophile
> The real example would be more like:
>
> name,age,country = itemgetter('name age country'.split())(x)
ouch.
if you do this a lot (=more than once), just wrap your dictionaries in a
simple attribute proxy, and use plain attribute access. that is, given
class AttributeWrapper:
def __init__(self, obj):
self.obj = obj
def __getattr__(self, name):
try:
return self.obj[name]
except KeyError:
raise AttributeError(name)
or, shorter but less obvious and perhaps a bit too clever for a
beginning Pythoneer:
class AttributeWrapper:
def __init__(self, obj):
self.__dict__.update(obj)
you can do
>>> some_data = dict(name="Some Name", age=123, country="SE")
>>> some_data
{'country': 'SE', 'age': 123, 'name': 'Some Name'}
>>> this = AttributeWrapper(some_data)
>>> this.name
'Some Name'
>>> this.age
123
>>> this.country
'SE'
and, if you must, assign the attributes to local variables like this:
>>> name, age, country = this.name, this.age, this.country
>>> name
'Some Name'
>>> age
123
>>> country
'SE'
>>>
(the next step towards true Pythonicness would be to store your data in
class instances instead of dictionaries in the first place, but one step
at a time...)
</F>
If undefined keys aren't a problem, then there's a value you expect
from them. Use
v1,v2,v3 = [ mydict.get(k,default) for k in 'one two two'.split()]
where default is the value you're expecting.
If you have more than a handful of keys then you have a different
problem (far too many local variables) with your code I think!
DRY is a good principle. I still prefer the 3 explicit assignments
though ;-)
> Out of interest, on my PC at least the list comp version is significantly
> slower than the explicit assignments. So it is a micro-optimization that
> may be worth considering if needed -- but at the cost of harder to
> maintain code.
>
> > It is completely
> > explicit and comprehensible to everyone, in comparison to
> >
> > v1,v2,v3 = [ mydict[k] for k in ['one','two','two']] # 52 chars
> > v1,v2,v3 = [ mydict[k] for k in 'one two two'.split()] # 54 chars
>
> That's a matter for argument. I find the list comprehension perfectly
> readable and comprehensible, and in fact I had to read your explicit
> assignments twice to be sure I hadn't missed something. But I accept that
> if you aren't used to list comps, they might look a little odd.
A matter of taste certainly!