IsNull and DropNA expressions

closes #697 
I think that this mostly comes down to how easy it is to implement these
things on various backends.  If backends have nonnull operations then
backing out this intent from a selection of an isnull will be annoying.  If
backends treat nonnull in the same way that they treat selections then we
don't have a problem with the single isnull operation.

On Sun, Dec 28, 2014 at 9:19 AM, Phillip Cloud <notifications@github.com>
wrote:

> In blaze/expr/null.py
> <https://github.com/ContinuumIO/blaze/pull/733#discussion-diff-22298990>:
>
> > +__all__ = ['IsNull', 'isnull', 'DropNA', 'dropna']
> > +
> > +
> > +class IsNull(ElemWise):
> > +    __slots__ = '_child',
> > +
> > +    @property
> > +    def schema(self):
> > +        return dshape('bool')
> > +
> > +
> > +def isnull(expr):
> > +    return IsNull(expr)
> > +
> > +
> > +class DropNA(Expr):
>
> Though I don't like having isnull() return bools and notnull() return the
> dshape of the child (sans Option), I think a single isnull() covers all
> cases. if someone wants all the values that aren't null they say
>
> t[~t.column.isnull()]
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/ContinuumIO/blaze/pull/733/files#r22298990>.
>