Michael Bayer wrote:
I'm also curious about use of dict_ versus getting from cls in _as_declarative.
IIRC, at pycon, you changed it so that DeclarativeMeta passes the class's
__dict__ as dict_ and then made it so that only dict_ is consulted for
attributes.
I did that, I thought, because you requested that it work that way. I don't
remember why you wanted it like that.
Oh, I wanted dict_ to be not used, I believe your compromise was as to
pass cls.__dict__ as dict_ ;-)
However, _as_declarative intrinsically needs to futz with cls for things like
__mapper__, __table__ and __tablename__, which, iirc, was always retrieved from
cls, even before the declarative mixins stuff was done.
I'm wondering why _as_declarative doesn't just take a cls and it then get
everything from the cls itself?
*shrugs*.
...this was why I didn't want dict_ to be used...
I remember backwards compatability for some use that Grok makes of this, but it
should be a one-liner for them to change and 0.6 would seem like a good
boundary to do it...
we should probably spend 5 minutes looking at Grok to see if there's some
reason for this.
Meh, my take would be to let 'em know that it's changing in 0.6.
_as_declarative is an implementation detail as far as I can see, and
anyone using it directly should expect breakage and/or change at any
point, not even just at 0.x boundaries...
FWIW, I don't use Grok, so wouldn't have the first clue to look...
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
