Prev: ANN: Wing IDE 3.2.5 Released
Next: Initial RSON prototype parser in subversion
From: Paul Rubin on 5 Mar 2010 21:53
Pete Emerson <pemerson(a)gmail.com> writes:
> I found out that adding a two dimensional element without defining
> first dimension existing doesn't work:
>
>>>> data = {}
>>>> data['one']['two'] = 'three'

You can use a tuple as a subscript if you want:

data = {}
data['one','two'] = 'three'
From: Steven D'Aprano on 5 Mar 2010 23:24
On Fri, 05 Mar 2010 17:22:14 -0800, Pete Emerson wrote:

> Why isn't the behavior of collections.defaultdict the default for a
> dict?

Why would it be?

If you look up a key in a dict:

addressbook['Barney Rubble']

and you don't actually have Barney's address, should Python guess and
make something up?

In general, looking up a missing key is an error, and errors should never
pass silently unless explicitly silenced.

And for those cases where missing keys are not errors, you're spoiled for
choice:

dict.get
dict.setdefault
collections.defaultdict

try:
dict[key]
except KeyError:
do something else

Or even:

if key in dict:
dict[key]
else:
do something else




--
Steven
From: Pete Emerson on 6 Mar 2010 00:36
On Mar 5, 8:24 pm, Steven D'Aprano <st...(a)REMOVE-THIS-
cybersource.com.au> wrote:
> On Fri, 05 Mar 2010 17:22:14 -0800, Pete Emerson wrote:
> > Why isn't the behavior of collections.defaultdict the default for a
> > dict?
>
> Why would it be?
>
> If you look up a key in a dict:
>
> addressbook['Barney Rubble']
>
> and you don't actually have Barney's address, should Python guess and
> make something up?
>
> In general, looking up a missing key is an error, and errors should never
> pass silently unless explicitly silenced.
>
> And for those cases where missing keys are not errors, you're spoiled for
> choice:
>
> dict.get
> dict.setdefault
> collections.defaultdict
>
> try:
>     dict[key]
> except KeyError:
>     do something else
>
> Or even:
>
> if key in dict:
>     dict[key]
> else:
>     do something else
>
> --
> Steven

My frame of reference for the past 10 < N < 15 years has been doing
this sort of assignment in perl:

$hash{key1}{key2} = value

I definitely agree that looking up a missing key should give an error.
The lazy perl programmer in me just wants to make an assignment to a
missing second key without defining the first key first. I'm not
saying it's right, I'm saying that it's something I'm trying to
unlearn, as I'm being convinced that it's the "best way" to do it in
python.

I'll take a look at dict.get and dict.setdefault, thank you for those.

I'm learning, and you're all very helpful, and I appreciate it!

Pete
From: Pete Emerson on 6 Mar 2010 00:42
On Mar 5, 6:26 pm, MRAB <pyt...(a)mrabarnett.plus.com> wrote:
> Pete Emerson wrote:
> > I've been wrestling with dicts. I hope at the very least what I
> > discovered helps someone else out, but I'm interested in hearing from
> > more learned python users.
>
> > I found out that adding a two dimensional element without defining
> > first dimension existing doesn't work:
>
> >>>> data = {}
> >>>> data['one']['two'] = 'three'
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in <module>
> > KeyError: 'one'
> >>>> data['one'] = {}
> >>>> data['one']['two'] = 'three'
> >>>> print data
> > {'one': {'two': 'three'}}
>
> > And through some research, I discovered collections.defaultdict (new
> > in Python 2.5, FWIW):
>
> >>>> import collections
> >>>> data = collections.defaultdict(dict)
> >>>> data['one']['two'] = 'three'
> >>>> print data
> > defaultdict(<type 'dict'>, {'one': {'two': 'three'}})
>
> > Why isn't the behavior of collections.defaultdict the default for a
> > dict?
> > Am I just revelling in my bad perl habits by not wanting to declare a
> > previous level first?
> > Is this sort of "more rigid" way of doing things common throughout
> > python, and is it best that I not fight it, but embrace it?
>
> > Your thoughts and comments are very much appreciated. I think my brain
> > already knows some of the answers, but my heart ... well, perl and I
> > go way back. Loving python so far, though.
>
> Someone once wrote about a case where he was porting a frontend from
> Perl to Python. It called a backend and parsed the result. Sometimes
> converting one of the fields to a number would raise a ValueError
> because it would contain "ERR" instead of a number, which Perl, of
> course, would silently convert to 0!
>
> Python is all about refusing to guess, and complaining if there's an
> error. :-)

Perl is quite an amazing language, but it also definitely allows for
sloppy habits and poor coding behaviors, particularly for someone such
as me whose perl is completely self taught. I think that's why this
time around with python I'm trying to learn my prior experience and
seek help in areas where I suspect there is improvement to be made.
I'm really liking the rigid flexibility I'm experiencing with python
so far.

I'm thinking it's time for me to get a python reference or two, just
to kill a few trees. If anyone has any strong feelings about what
belongs in a "beginner but already learning quickly" library, please
toss them my way. I'll grep around the 'net for opinions on it, too.

Pete
From: Bruno Desthuilliers on 6 Mar 2010 10:04
Pete Emerson a �crit :
(snip)
> I'm really liking the rigid flexibility I'm experiencing with python
> so far.

"rigid flexibility" !-)

+1 QOTW - and welcome on board BTW.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: ANN: Wing IDE 3.2.5 Released
Next: Initial RSON prototype parser in subversion