Carl Banks wrote:
> On Aug 16, 10:01 pm, Paul McGuire <[EMAIL PROTECTED]> wrote:
>> On Aug 16, 8:28 pm, Jonathan Gardner
>>
>>
>>
>> <[EMAIL PROTECTED]> wrote:
>>> On Aug 16, 3:35 pm, beginner <[EMAIL PROTECTED]> wrote:
>>>> In perl it is just one line: $a=$b->{"A"} ||={}.
>>> a = b.setdefault('A', {})
>>> This combines all two actions together:
>>> - Sets b['A'] to {} if it is not already defined
>>> - Assigns b['A'] to a
>>> More info on dict methods here:
>>> http://docs.python.org/lib/typesmapping.html
>> No, this has already been proposed and discarded. The OP does NOT
>> want this, because it always generates an empty {} whether it is
>> needed or not. Not really a big hardship, but if the default value
>> were some expensive-to-construct container class, then you would be
>> creating one every time you wanted to reference a value, on the chance
>> that the key did not exist.
>>
>> Carl Banks' post using defaultdict is the correct solution. The
>> raison d'etre for defaultdict, and the reason that it is the solution
>> to the OP's question, is that instead of creating a just-in-case
>> default value every time, the defaultdict itself is constructed with a
>> factory method of some kind (in practice, it appears that this factory
>> method is usually the list or dict class constructor). If a reference
>> to the defaultdict gives a not-yet-existing key, then the factory
>> method is called to construct the new value, that value is stored in
>> the dict with the given key, and the value is passed back to the
>> caller. No instances are created unless they are truly required for
>> initializing an entry for a never-before-seen key.
>
>
> When I made my response, it occurred to me that Python could be
> improved (maybe) if one could overload dict.get() to use a factory,
> like so:
>
> b = {}
> a = b.get(k,factory=dict)
> a['A'] = 1
>
> That's a slight improvement (maybe) over defaultdict since it would
> still allow the same dict to have the membership check in other
> places. I'm not so sure overloading get to let it modify the dict is
> a good idea, though.
>
> Actually, it'd probably be fairly uncontroversial to add a factory
> keyword to dict.setdefault(). At least insofar as setdefault is
> uncontroversial.
>
Well it's uncontroversial enough to have made it into the distribution,
which represents a tacit admission by Guido that the .get() method alone
didn't implement his full vision.
The python-dev thread that discussed the feature before implementation
(as so often is the case) exercised many of the possible design paths,
and would be a useful read. [Damn, now I have to
well-known-search-engine it]. Aah, right - I'd forgotten how long it
took to get it right. This would be a suitable starting-point - it's the
beginning of the /third/ round of discussion:
http://mail.python.org/pipermail/python-dev/2006-February/061485.html
Many alternatives were discussed, and my memory at this distance is that
Guido had good reasons for choosing the exact API he did for defaultdict.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------
--
http://mail.python.org/mailman/listinfo/python-list
