Before, reductions in lazy expressions always had to be eagerly evaluated, preventing to be saved persistently. Now, reductions can be preserved when using the LazyExpr constructor provided that expressions are passed as strings (providing a LazyExpr instance is not supported for persisting reductions, and probably will never be).
Also, when loading lazy expressions from disk, reductions are loaded lazily, and only computed during the LazyExpr.compute() stage.
Finally, a major API change; LazyExpr.eval() has been changed to LazyExpr.compute(). I was not happy with a method named the same than Python's eval(), and I think the new name is more representative of what it does. Hopefully, this will be the last major API change before 3.0.0.rc1.
Before, reductions in lazy expressions always had to be eagerly evaluated, preventing to be saved persistently. Now, reductions can be preserved when using the
LazyExpr
constructor provided that expressions are passed as strings (providing aLazyExpr
instance is not supported for persisting reductions, and probably will never be).Also, when loading lazy expressions from disk, reductions are loaded lazily, and only computed during the
LazyExpr.compute()
stage.Finally, a major API change;
LazyExpr.eval()
has been changed toLazyExpr.compute()
. I was not happy with a method named the same than Python'seval()
, and I think the new name is more representative of what it does. Hopefully, this will be the last major API change before3.0.0.rc1
.