On 4/18/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 4/18/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > PS: if this change to the class statement were to happen, the crowd
> > discussing the 'make' PEP (which I don't like but don't have the power
> > to stop being discussed) should take
Steven Bethard wrote:
> Could someone put out some use-cases where it would be really helpful
> to be able to specify a different dict type for the class dict?
In SQLObject and FormEncode, you can do something like:
class Registration(formencode.Schema):
fname = String(not_empty=True)
Guido van Rossum wrote:
>>The suggested order would be by key creation so that reassigning
>>a key after manipulation would maintain the original order as in
>>the Thing.b case above.
>
>
> Unfortunately I don't think you can implement this without
> significantly slowing things down. This belief
On 4/18/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> PS: if this change to the class statement were to happen, the crowd
> discussing the 'make' PEP (which I don't like but don't have the power
> to stop being discussed) should take notice.
If you pronounce it dead, I can make sure the discus
On 4/18/06, Jack Diederich <[EMAIL PROTECTED]> wrote:
> I mentioned then and would like to resurrect now the idea of making
> a dict-alike that has two extra properties:
>
> 1: the keys can only be str or unicode (py3k: just unicode)
This seems useful -- although the current dict type is already
In an old thread ("dictionary tuning", 2003[1]) Raymond H laid out the
typical use cases of dicts and found there were many subclasses of
"typical" and speeding one up hurt the others. The results are in
dist/Object/dictnotes.txt A couple of the particular use cases have
since been satisfied by
