On Wed, Jun 13, 2007 at 09:37:35AM +1000, Malcolm Tredinnick wrote: > On Tue, 2007-06-12 at 06:16 -0700, Brian Harring wrote: > > Not yet advocating it (mainly since digging it out would be ugly), but > > if you take a look at the bits above, having the option to disable > > verification on read *would* have a nice kick in the pants for ORM > > object instantiation when the admin has decided the data is guranteed > > to be the correct types. > > I have a blog post I'm still collecting the data for (making pretty > graphs, mostly), but it seems that the extreme cases you can actually > make instantiation much faster by just writing an __init__ method on the > Model sub-class that does just the right thing -- customised for the > model fields -- since it's only an attribute populator when you get > right down to it. One can even generate this code automatically. Again, > not something to worry about for the 90% case, but for people wanting to > create 10^6 objects, it's worth the ten minutes to code it up by hand. > That'll appear on the community aggregator when I post it.
Sounds semi fragile since presumably it will totally bypasses the default Model.__init__ (which later on may grow important instance initialization bits). Personally, I'm more interested in speeding up django then bypassing chunks of it for speed- realize it's not always possible, but that's where my interests lie (upshot of it is that the common cases get a bit faster while the extremes become usable). That said, others may be less stubborn and it may be useful to them :) > > > Given that upstream pydispatcher isn't really being maintained, I don't > > > think we should be too hesitant to tweak it for our needs. > > > > Don't spose it could just be thrown out? The code really *is* ugly :) > > Agree with the second part (although I'd be less hyperbolic, if I saw it > from a colleague, we'd be having discussions). Humour, man, humour ;) 'Ugly' isn't hyperbole I'm afraid however. Terms usage isn't meant to say anything about the author, merely that this code while working, needs some heavy cleanup, something a bit more elegant/maintainable. Internals are pretty obscure, and no one seems to have firm expectations out of the code- for example, should the order of connect calls reflect the order of dispatches when a send comes in? Yet to find an answer to that one, both from django devs/users expectations, and searching the remains of upstream. Part of the confusion about the code comes down to the age of the code- it originally aimed for py2.2 (since then requiring 2.3.3 due to python bugs). Few examples, sets came around in 2.3, so the order of dispatch may not be desired to be constant, may just be an implementation quirk. Same goes for the misc dicts floating in dispatcher; are they implemented that way for a reason, instead of using weakref.Weak*Dictionary? The author of pydispatch as far as I know also implemented weakref.Weak*Dictionary (they've got it in their vcs at least)- assuming that's correct, either the author skipped updating pydispatch for Weak*Dictionary (either due to time/interest, or the updating being tricky), or there was an undocumented reason it wasn't used- basically have to assume the latter and try to root about for an undocumented reason, since weakref collections can be fairly tricky. Either way, I'm still playing locally, but I strongly suspect I'll wind up chucking the main core of dispatch.dispatcher and folding it into per signal handling; may not pan out, but at this point it seems the logical next step for where I'm at patch wise. > Keeping the API similar > to what it is (or at least, "routine" to port -- possible to do with a > reg-exp, say) would be worthwhile, since there is a lot of code in the > wild using the signal infrastructure. Don't have any intention of chucking the api at this point; will make more sense when the patch is posted, but basically I'm shifting the logic into individual signals instances- making them smarter. So, for (unimplemented, but soon) simple signals, following example- instead of dispatcher.send(signal=signals.request_started) would be signals.request_started.send() Reasoning is two fold- 1) locks down the data thats passed to receivers, can figure out whats for that signal just via pydoc, 2) shifts control of actually dispatching into the signal, which can be made aware at the time of regirestration of whether or not anything is actually listening. Expected by product of that shift is that the set of listeners for a signal be calculated when a listener is added, instead of doing a lookup each send invocation. Nice aspect of this is that dispatcher.send api still can exist, just wind up delegating to the signal if it's new style, if not, fallback to the existing connections machinery. Assuming this all goes sanely, it may be possible to flat out drop the existing internals- basically if an old style signal is used, should be possible to generate a new style signal that holds the misc receivers already, and just map the old style to new (WeakKeyDictionary specifically) on the fly for the dispatcher.* api. ~harring
pgpTpV2SXiv5k.pgp
Description: PGP signature
