If couse one can also do

class A():
    def __init__(self,n): self,n=n
    f(self,row): return row.x.id+1+self.n
    g(self,row,a=1): return row.x.id+a+self.n
    h(self,row,a=1,b=2): return row.x.id+a+b+self.n
a=A(7)

db.define_table('x',....)
db.x.f = Field.Virtual(a.f)
db.x.g = Field.Lazy(a.g)
db.x.h = Field.Lazy(a.h)

for row in db(db.x).select():  print row.f, row.g(), row.h()

would this address some of Carlos' needs?


On Aug 20, 7:56 am, Massimo Di Pierro <massimo.dipie...@gmail.com>
wrote:
> How about we just do this:
>
> db.define_table('x',Field('number','integer'))
> if db(db.x).isempty(): [db.x.insert(number=i) for i in range(10)]
>
> db.x.normal_shift = Field.Virtual(lambda row: row.x.number+1)
> db.x.lazy_shift = Field.Lazy(lambda row, delta=3: row.x.number+delta)
>
> for row in db(db.x).select():
>     print row.number, row.normal_shift, row.lazy_shift(8)
>
> It is in trunk already, not as a replacement but as an alternative.
> Pros:
> - simpler syntax
> Cons:
> - we can only attach virtual fields to a table not to a join (even if
> each table in the joins will have virtual fields)
> - they will not appear in crud.read and table forms unless passed
> explicitly. (*)
>
> (*) In principle this can be changed as one can envision adding
> Field.Virtual in the model and giving them attributes like a label,
> comment, etc. But that would require major refactoring.
>
> On Aug 20, 7:04 am, Massimo Di Pierro <massimo.dipie...@gmail.com>
> wrote:
>
>
>
>
>
>
>
> > OK try:
>
> > db=DAL()
> > db.define_table('x',Field('number','integer'))
> > if db(db.x).isempty(): [db.x.insert(number=i) for i in range(10)]
>
> > from gluon.dal import lazy_virtualfield
>
> > class MyVirtualFields(object):
> >     # normal virtual
> > field
> >     def normal_shift(self): return self.x.number+1
> >     # lazy virtual field (because of
> > @staticmethod)
> >     @lazy_virtualfield
> >     def lazy_shift(self,row,delta=4): return row.x.number+delta
>
> > db.x.virtualfields.append(MyVirtualFields())
>
> > for row in db(db.x).select():
> >     print row.number, row.normal_shift, row.lazy_shift(8)
>
> > It is better? We have one new API and one import. I do not like so
> > much the try of adding a __lazy__ attribute to the function because,
> > in the future the function may be a class with a __call__ method and
> > te decorator would mess up class attributes....  perhaps we should
> > this dicusssion and tests on web2py-delevelopers
>
> > Massimo
>
> > On Aug 20, 6:46 am, Massimo Di Pierro <massimo.dipie...@gmail.com>
> > wrote:
>
> > > Yes but if we use lazy we have to define and import it from somewhere.
> > > There is another reason. Using staticmethod we can also do
>
> > > class A(): pass
> > > a=A()
>
> > > a.f=lambda(instance,row,*a,**b): return 'lazy value'
> > > a.g=lambda(instance,row,*a,**b): return 'lazy value'
> > > a.h=lambda(instance,row,*a,**b): return 'lazy value'
>
> > > db.table.virtualfields.append(a)
>
> > > Lat me give it a try anyway...
>
> > > On Aug 20, 5:51 am, Bruno Rocha <rochacbr...@gmail.com> wrote:
>
> > > > why static_method is used to define this?  not better to have some @lazy
> > > > decorator?

Reply via email to