sorry, i havent been following. two++ dicts ?! this is getting out
of hand. if we have to have any dicts at all, it would be just one
dict. and also, it should be proxied through a property so that if
you dont access it, its never even created. we have this on
ConnectionFairy right now and its called "properties". I'd vote for
some extremely neutral word like "attr", and we put it on Table/
Column/ConnectionFairy, and we're done. i think the total usage for
these dicts is very low....if we are concerned about extensions
colliding with user data in these dicts, then we'd also be concerned
about extensions colliding with other extensions, and mutliple dicts
arent helping in that case anyway. keys can be placed as tuples
(such as ('myext', 'somekey')) if namespace collisions are a concern,
but that kind of thing has to be done by conventions regardless.
On Nov 1, 2007, at 10:40 AM, Rick Morrison wrote:
> That sounds reasonable to me; my knee-jerk thought was that we
> might need to worry about memory usage, but these references are
> only on low-count instances like tables, columns, sessions and
> mappers, not ORM object instances.
>
>
>
> On 10/31/07, Paul Johnston <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Ah sure, so it's to be a namespace for namespaces, a shared dict()
> parking lot. Got it.
>
> How about having two dicts? One is purely for user data, libraries
> and such never touch it. I suggest "userdata".
>
> The other is for use in extensions and stuff, say "extdata".
>
> Paul
>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
