I'd also still be interested to see a real-world example of where this would be useful.
Anthony On Thursday, August 23, 2012 12:19:24 PM UTC-4, Jonathan Lundell wrote: > > On 23 Aug 2012, at 9:16 AM, Massimo Di Pierro > <[email protected]<javascript:>> > 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 <[email protected]> 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). >> > > > > > --
