Francesco Bruzzesi

Tried the simplest change: ```diff def dask_lazy_p2_constructor(obj: Data) -> NativeDask: # pragma: no cover import dask.dataframe as dd + import pandas as pd - return cast("NativeDask", dd.from_dict(obj, npartitions=2)) + pd_frame...

Thanks for the feature request. I would argue this should be achieved via `DataFrame.clear(n=0)` (see https://github.com/narwhals-dev/narwhals/issues/2890) (or by adding support for `Schema.to_frame`).

I am happy to move forward with the PR, I am about to push the support for lazy backends. We will need to think what to do regarding pandas non-nullable...

> > I bet it's problematic and causes friction all over the place. > > Well you'd be right about that 😂 This is the story of Narwhals in a...

Thanks @MarcoGorelli - addressed the deprecated methods in https://github.com/narwhals-dev/narwhals/pull/3285/commits/2823ebee644098c9200f1658888c522803240825 While doing so, I noticed that we don't have a mention for `LazyFrame.tail` in the [main vs stable.v1 differences](https://narwhals-dev.github.io/narwhals/backcompat/#main-vs-stablev1-differences) section. ---...

Thanks for the perspective @dangotbanned Let me add a general comment that kind of addresses all the points below: I treated this as a one off effort, definitely I didn't...

Thanks @dangotbanned, we agree on everything you said in the last two comments. If I focus on: > What I want to see is an effort to minimize the burden...

> To anticipate that the input may change, the input is moved into an intermediate representation _first_, and then I transformed that _more stable_ version into some output(s). > This...

> I'll try to take another look at the **visual** part of the PR today. > > Being able to filter the backend-axis the table ([#2858 (comment)](https://github.com/narwhals-dev/narwhals/issues/2858#issuecomment-3104851456)) was something that...

> we ok to ship this? I was quite happy with the rework. My take again is: I rather merge it with a solution which is not perfect but renders...