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.
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 <javascript:>> > 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). > --
