Personally, I've found myself reaching for it several times in library code I've written where it makes sense. For example, I've written a set of gmail API bindings where composing a message is done like this:
gmail = Gmail(...)
gmail.draft.to("some_address@domain.com").subject("Some Subject").body.as_html("<title>markup goes here</title>").send()
For a more compelling use-case, I've written a fluent CRON scheduler similar to the schedule library (
https://pypi.org/project/schedule/), where all of these are examples of valid schedules:
with Schedule(...) as schedule:
schedule.every(3).months.and_(7).days.and_(12).hours.and_(30).minutes.do(some_func)
schedule.every.tuesday.at(6).do(some_func)
schedule.every.month.on_the(1).and_(7).at(23, 59).do(some_func)
schedule.every.year.in_.march.and_.august.and_.november.on.saturday.and_.sunday.at(12).and_(20, 30).starting(datetime.today()).ending(datetime(2022, 1, 1)).do(some_func)
The key design goal here for me was ease of reading and writing schedules. Obviously, this is far easier to read and understand than a cron string to anyone who isn't already intimately familiar with the cron format, but I also wrote it in such a way that as you write your schedule you only ever get valid autocompletions from your IDE for the particular node you are at (which was quite tricky to implement because you can often skip nodes altogether). Here is a demo:
Ricky's curry helper decorator is cool, but for me the drawback that makes it a dealbreaker is that it is too dynamic for IDE's to understand. I write a lot of library code and find myself routinely foregoing metaprogramming and runtime attribute/function/class generation in favor of statically declared code so that my consumers will receive assistance
from their editors.
I guess my thoughts on this thread are that design patterns are only design patterns until languages adopt them as first-class features. For example, no one would call subroutines a design pattern in modern languages, but in the days of goto-based programming, that's exactly what functions were. The addition of syntactic sugar changed them from a design-pattern to a core language construct.
So the real question is whether there is an appetite to formally adopt fluent programming as a first-class feature in python by providing supporting syntax to make library code like the above easier to write. From the answers so far that seems unlikely. Personally, I like the idea in theory but I wouldn't want the function call syntax to change. At most I'd just want to add new syntactic sugar to make such constructs easier *to write* (in the simple cases).
But I don't really have any suggestions off the top of my head as to what such a syntax might look like.