Modifying the {} and [] tokens

Geoff Howland ghowland at lupineNO.SPAMgames.com
Sat Aug 23 07:29:28 EDT 2003


>>> So I can obviously override dict and it works when I specifically call
>>> dict(), but it does not work with the syntax sugar {}.
>>
>>That's because you created a new dict.  You didn't modify the
>>actual type {} uses in the intepreter.  {} is not simple syntactic sugar
>>for dict() in the local namespace.  BTW, if it were, then
>>
>>  dict = 8
>>  a = {3: 4}
>>
>>would fail.
>
>Right, so is there a way to change this?  I know the syntax I tried
>doesnt work and for obvious type reasons, since you wouldnt want to do
>this by accident.
>
>Perhaps something has to be registered in some Python
>variable/class/module-list I am not aware of that would make this
>happen?  I am ok with the consequences of potentially introducing
>oddities into my code from the Norm for this flexibility.

I've explored all of __builtins__ that I have been able to, and
replacing dict there does nothing either, so I'm beginning to think
that {}, [], etc are bound to types in the C code only and not
available at all through Python to be re-typed.

Is this correct?  Is there no way to change type on these expression
delimeters?

I would think that somewhere this is a Python accessable definitely of
what <type 'dict'> is that could be altered, so far I cant seem to
find any reference to it through the Python Language Reference, Python
in a Nutshell, or any google search.

Python in a Nutshell specifies that dict(d={}) is essentially d = {},
but I can't find a description of how this token/expression to type
binding happens.

It seems like it would be really handy to add features to all
containers equally though, especially since you should be able to get
new functionality from any code written even if it didn't know about
your new features because it could instantiate with the new type.

BTW, some of the other comments in my team have been for a desire of
more inclusive OO, such as [].len() instead of len([]), and this sort
of thing.  Having them builtin is obviously great and useful, but it
feels wrong to some people and I'm trying to work on making things
smoother instead of just forcing them to adapt (which they may not
choose to do).


-Geoff Howland
http://ludumdare.com/




More information about the Python-list mailing list