I think what's being discussed in this thread is variations on the fluent
interface design pattern (https://en.wikipedia.org/wiki/Fluent_interface).
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_addr...@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:
https://gfycat.com/thickbrowndorado (watch it in HD or it will be
pixellated)
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.
On Mon, Oct 18, 2021 at 5:39 PM Chris Angelico <ros...@gmail.com> wrote:
> On Tue, Oct 19, 2021 at 3:34 AM Ricky Teachey <ri...@teachey.org> wrote:
> > insert(x).into.seq(s).at(i)
> > insert(k, v).into.mapping(m)
> >
> > I would never use any of this in a serious application, but it's still
> fun.
>
> Reminds me of some testing/assertion frameworks. I'm not a fan, but
> some people like it.
>
> expect(thing).to.be.numeric()
>
> ChrisA
> _______________________________________________
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/YMDXSDRYD6PBAR6TBASYGVKW3LI4ME6U/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/NHJ25FTPFB3623O36BTUU2VRAIL47R7I/
Code of Conduct: http://python.org/psf/codeofconduct/
