On 23 Aug 2012, at 9:16 AM, Massimo Di Pierro <massimo.dipie...@gmail.com> wrote: > Isn't that what my code does? > > In the example I used a lambda instead of a function but the implementation > should be exactly what you say. Perhaps I misunderstood.
Or maybe I did. I'll have a chance to look at it more closely later. Let's label it experimental for now. > > BTW. Auth is now fully lazy, when DAL(lazy_tables=True), and therefore should > be faster. Needs testing and benchmarking. > > massimo > > > On Thursday, 23 August 2012 10:45:42 UTC-5, Jonathan Lundell wrote: > On 23 Aug 2012, at 8:39 AM, Anthony <abas...@gmail.com> wrote: >> Couple of things (including questions). >> >> 1. attributes defined in the Field() spec are lazy already, right? >> >> I guess not so much "lazy", but for the most part all that happens is they >> get added as attributes to the Field's self. There is a little logic in the >> constructor, though. I suppose we don't really need to make them much more >> lazy, but then I'm wondering about the use case for on_define. >> >> In the above example, the attributes could just as well be defined there; my >> intent was for attributes that required more logic, where attributes are >> being set conditionally and it's clumsy to construct different Field() calls >> to do it. >> >> OK, sounds reasonable. Do you have an example? >> > > More later (I'm off to a meeting). > > Looking at the new code, I see that Massimo and I had different ideas about > the definition of on_define. I think they both have merit, and I need to > consider the implications. Briefly, the new code patches up the table > definition, which will be used as usual in a lazy fashion. > > My version defined a function to be called when the table was actually > created (later, lazily). > > --
