a clean way to define dictionary

[Chermside, Michael]

Skip Montanaro wrote:

> 
>     >> In 2.3, you can express this as dict(foo=1, bar='sean') without a
>     >> need to define a function for the purpose.
> 
>     Alexander> Yuck! This seems like a really bad idea to me. This
>     Alexander> effectively makes it impossible to specify any options
>     (such Alexander> as initial size, default value etc.)
> 
> I don't see that the behavior of dict() affects your ability to define the
> behavior of a subclass.

Alex Martelli replies:
> To play devil's advocate -- it does so by Liskov substitution principle
> (if all keywords must be passed untouched to built-in dict to emulate
> its behavior, you can't steal some of them to control your subclass's,
> within the constraint of being able to drop your subclass in lieu of
> dict into an existing piece of code without breaking it).

Please help me understand this. I thought LSP said essentially that
INSTANCES of the subclass should be drop-in replacements for INSTANCES
of the superclass. But the constructor is really not a property of
INSTANCES... it's clearly a property of the class itself. So... am I
missing something here?

-- Michael Chermside

PS: I do agree that it's mildly annoying for subclassing dict, and that
it's mildly useful for brevity & clarity in declaring some dicts, and
that if anyone actually OBJECTS (which I don't) that python-dev is the
place to speak up pretty-darn-quick.

----- mandated disclaimer below -----


This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.