a clean way to define dictionary

[Michele Simionato]

Alexander Schmolck <a.schmolck at gmx.net> wrote in message news:<yfsof0t7gwp.fsf at black132.ex.ac.uk>...
> mis6 at pitt.edu (Michele Simionato) writes:
> I wanted to measure the slowdown due to "pure" 
> > subclassing, i.e. without doing anything to __getattr__ and __setattr__.
> 
> Do you maybe mean __getitem__/__setitem__? I'm not sure why you are interested
> in the "pure" subclassing overhead, this doesn't seem a particularly
> meaningful quantity in the context of comparing it to the price to pay for no
> built-in dict(foo='bar') sugar.
<snip>
> > Of course, if you override __getattr__, there is an issue, but the
> > issue would be the same with Python 2.2. 
> > I am curious to test the difference between Python 2.2 and 2.3; 
> > I will look at the instance creation time too, but this is less
> > important than the access time, since typically I create a dictionary 
> > only once.
> 
> Indeed (which is why having to write your own syntactic sugar one-liner
> wouldn't even be a performance problem).
> 
> 'as

Sorry for the typo, of course I meant __setitem__/__getitem__. 
I am saying that a workaround for the change of the constructor signature 
is to subclass dict and to override the constructor. There is 
not a big penalty and you seems to agree (your last sentence). 
Overriding __getitem__ gives a big penalty, that's true, but this has 
nothing to do with the change of the constructor in Python 2.3, right ?
I do not understand where the source of the confusion is (if any).


                       Michele