Implement missing Expr methods

In https://github.com/narwhals-dev/narwhals-daft/blob/main/narwhals_daft/expr.py there's a list of what's not_implemented for Daft

Any help moving forwards with these would be greatly appreciated 🙏

Task is:

Follow the setup instructions on the README
Implement some method
You can run the tests for that method with run_test.py. E.g.: python run_tests.py -k is_unique to run the is_unique tests
Run python update_run_tests.py when you're done, and hopefully the list in run_tests.py will shorten itself!

Feel free to ask for help if anything trips you up

I will be looking at implementing functions in the string namespace in the next few days

thanks! i'd suggesting with just adding a single one (say, len_chars?) and marking all the others as not_implemented for now

had a look at remaining functions & I'm going to attempt to implement mode tomorrow. 🤞

update: closed this PR for the time being as I couldn't quite figure out how not to use something which triggers a computation; come to think of it, this would be a good topic for the study group :)

In the meantime, I've added a request for additional descriptive statistics with daft in their existing discussion on having more aggregations: Eventual-Inc/Daft#485

@ym-pett

@ym-pett I will be happy if you want to take some of the string methods, just check this PR first #64. Also, I will try to work on slice tomorrow

@raisadz

thanks @raisadz, I'd like to try .to_titlecase().

Oh no it's one of those that don't exist in daft, I will try, can't guarantee 😅

that one might be doable by following the same workaround we do in narwhals for sql / pyspark / duckdb

yes, using analogy I've got something that works outside of Narwhals on a toy df but I'm struggling to incorporate it into "Narwhals language". I will try some more and may well ask questions in a draft PR. Thanks Marco!

I will take a look at str.replace_all next

I was thinking of looking at the contains method in expr_str next.

update on contains method:

I've been investigating it for a couple of days now and get why the tests are failing with the native daft which doesn't have a way to pass a regex. On top of that, I can see in the tests that some of the backends are specified; at least in tests/expr_and_series/list/contains_test I see "dask", "modin", "cudf", "pyarrow", "pandas" and in the tests/expr_and_series/str/contains_test I see "cudf" specified but that might be to not run with/fail with that backend.

Am I right in thinking even if I find a way of detecting that the user wants to use a regex, the tests themselves might need to be adapted to daft, which we don't want to do?
I feel like sql / pyspark / duckdb modules are quite similar to daft, how far does it make sense to take what's implemented there as guidance? If something isn't implemented, is it fair to assume that there are some major technical hurdles, or is is it more likely to be coincidence and just hasn't been done yet?
I'm thinking of looking for something else to implement, unless if you think it's worth pushing on with the contains method?

Thanks for any advice you might have :)

i haven't taken a close look at contains yet, but there's probably quite a few dt methods that should be feasible

If something isn't implemented, is it fair to assume that there are some major technical hurdles, or is is it more likely to be coincidence and just hasn't been done yet?

yeah probably a good assumption

thanks Marco! I'll have a look & drop which method I'll take here.

@ym-pett

update on contains method:

I've been investigating it for a couple of days now and get why the tests are failing with the native daft which doesn't have a way to pass a regex. On top of that, I can see in the tests that some of the backends are specified; at least in tests/expr_and_series/list/contains_test I see "dask", "modin", "cudf", "pyarrow", "pandas" and in the tests/expr_and_series/str/contains_test I see "cudf" specified but that might be to not run with/fail with that backend.

Am I right in thinking even if I find a way of detecting that the user wants to use a regex, the tests themselves might need to be adapted to daft, which we don't want to do?

I feel like sql / pyspark / duckdb modules are quite similar to daft, how far does it make sense to take what's implemented there as guidance? If something isn't implemented, is it fair to assume that there are some major technical hurdles, or is is it more likely to be coincidence and just hasn't been done yet?

I'm thinking of looking for something else to implement, unless if you think it's worth pushing on with the contains method?

Thanks for any advice you might have :)

When I had a quick look at contains before I also noticed that they only accept strings rather than regex. Other string methods that are left might need several workarounds. @ym-pett I agree with Marco that you can take a look at some other non-implemented namespaces as there might be a few Daft functions that can work out-of-the-box. I haven't looked at them yet

@raisadz

ok cool, thanks @raisadz ! I've started looking at to_datetime but I've not investigated how it works in daft compared to nw, will let you know how I get on.

@raisadz

thanks @raisadz! Ignore my earlier (deleted) comment - someone has already done it :)

Thanks!

Btw we agreed a scheduled run to auto update the submodule but accidentally broke the typing check in doing so, for now id suggest ignoring it (or adding a couple of not_implemented to fix it?)

@MarcoGorelli

Hi @MarcoGorelli , didn't see your message in time, but did the not_implemented thing :)

Can I check I understand: the scheduled auto-update means it'll be done automatically at a fixed time in the week & we can ignore doing the updates from now on?

Thanks!

Yeah it should happen automatically each Thursday, a PR should get auto-created and we just need to merge. Hopefully, we'll see next week 😆

very cool!

@raisadz

I'm looking around for things I can do easily, in the meantime thought I should also ask if there is there anything you'd like done but haven't got time for @raisadz or @MarcoGorelli?

(I don't quite see what work would be involved in the other issues apart from #79, which I think is done for the moment :))

thanks! i think

    "test_filter_windows",
    "test_filter_windows_over",

might be doable if you fancy it? feel free to ping if it's not clear how

great thanks!! In the meantime I've started on trying contains for the list_expression, but if I hit a wall I'll probably quickly switch over to those 😅

@MarcoGorelli

yep, hit that wall, going to switch over to "test_filter_windows" :)

@MarcoGorelli, if you have time, could you tell me what's needed here: I can see that for narwhals_daft dataframe.filter is already implemented and the test already exists in the narwhals submodule, is it a refactor you had in mind?

update: fresh eyes, I think I now get it, filter in the expr modules is meant, will try that now. Sorry just couldn't see it last night.

It may be embarrassing to say that I was barking up completely the wrong tree with the draft PR I tried, but I found it super useful to learn more about why expr.filter can't work with lazy-only backends and I now understand more about how nw does it for the other backends.

I should be able to figure out what "test_filter_windows" needs now.

😄 sorry about that - yeah this one's about allowing for things like df.filter(nw.col('price') = nw.col('price').min()), so you'll need to define DataFrame._filter, i think if you take a look at the sql or duckdb code in narwhals it should provide a good starting point

haha no worries at all it was so good for me to get lost, feel like I learned a lot!!

@MarcoGorelli

@MarcoGorelli on draft PR #118, is the CI just generally failing or is there something I can do on my end?

hey - i think if you fetch and merge upstream/main it might resolve itself? it looks like a network issue

PRs #137, #139, #140, #141, #142, #143, #144, #145 implement 15 new expressions, with roughly ~44 previously failing tests now green (hopefully 🤞, at least locally they are 😅 ).

Hinges on merging #138 first though. Left all new PRs on draft mode because of this.

Navigation Menu

Repository navigation

Implement missing `Expr` methods #35

9 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Implement missing Expr methods #35

Description

Activity

raisadz commented on Nov 13, 2025

MarcoGorelli commented on Nov 13, 2025

ym-pett commented on Nov 13, 2025

raisadz commented on Nov 18, 2025

ym-pett commented on Nov 19, 2025

MarcoGorelli commented on Nov 19, 2025

ym-pett commented on Nov 19, 2025

raisadz commented on Nov 19, 2025

ym-pett commented on Nov 20, 2025

ym-pett commented on Nov 25, 2025

MarcoGorelli commented on Nov 25, 2025

ym-pett commented on Nov 25, 2025

raisadz commented on Nov 25, 2025

ym-pett commented on Nov 25, 2025

9 remaining items

ym-pett commented on Jan 16, 2026

MarcoGorelli commented on Jan 16, 2026

ym-pett commented on Jan 16, 2026

MarcoGorelli commented on Jan 16, 2026

ym-pett commented on Jan 16, 2026

ym-pett commented on Feb 2, 2026

MarcoGorelli commented on Feb 2, 2026

ym-pett commented on Feb 2, 2026

ym-pett commented on Feb 2, 2026

ym-pett commented on Feb 9, 2026

MarcoGorelli commented on Feb 9, 2026

ym-pett commented on Feb 9, 2026

ym-pett commented on Feb 9, 2026

MarcoGorelli commented on Feb 19, 2026

jonasdedden commented on Sep 4, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Implement missing `Expr` methods #35