> Seems like the docs should cover that (or even `help()`) -- and if not, then
> the parameter names could be better.
It should, and normally does as do the parameters, but the best documentation
should be the code itself, right? So the idea here would be to make it harder
to not know the order
On Mon, Oct 18, 2021 at 6:15 PM Matt del Valle wrote:
> I think what's being discussed in this thread is variations on the fluent
> interface design pattern (https://en.wikipedia.org/wiki/Fluent_interface).
>
> with Schedule(...) as schedule:
>
> schedule.every(3).months.and_(7).days.and_(12
On Mon, Oct 18, 2021 at 2:13 PM Matt del Valle wrote:
>
> 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 run
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 gma
On 10/18/21 3:20 AM, Mathew Elman wrote:
> I don't know if this has been suggested before, or if this is outlandishly
impossible
> (though I would be surprised if it was), so apologies in advance if so.
>
> I have on occasion come across a situation where I use/write a signature like
this:
>
>
On 10/18/21 6:29 AM, Mathew Elman wrote:
>> What you are describing is very, very dissimilar to currying. It's simply
multi-argument
> functions with a different call syntax.
>
> It is almost identical to currying, the only differences are:
> 1. the intermediate return being an object with an at
On 10/18/21 6:23 AM, Mathew Elman wrote:
> When learning python, and even sometimes now, I have had to look at the implementation of a function in order to
recall which order arguments should go.
Seems like the docs should cover that (or even `help()`) -- and if not, then
the parameter names
> Reminds me of some testing/assertion frameworks. I'm not a fan, but
> some people like it.
>
> expect(thing).to.be.numeric()
That rings a bell with test a javascript test framework, something like enzyme?
___
Python-ideas mailing list -- python-ideas@
On Tue, Oct 19, 2021 at 3:34 AM Ricky Teachey 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)
> I think that a programming language needs to be different enough from a
> natural language to remind you that it's a programming language and that
> the computer isn't that smart. The computer will do as you say, not as
> you mean.
I agree entirely, that's why I am not suggesting putting spac
Yeah if you change the API to be a bit more powerful, you could build all
kinds of ideas on top of the basic kernel of idea...
Here's some others I was shooting around with a python-eque buddy of mine
this morning:
@curry_helper
def is_(x):
... # elsewhere
@is_.add_predicate
def a_number(x)
This is interesting, it's not as nice as native syntax support could have been
but a decorator like this is also pretty nice.
I think I would bikeshed this so the decorator was the full dot separated
signature, e.g.
@curry_helper('insert.into')
def insert(x: Any, y: list):
def y.append(x)
Not really, I'm not trying to suggest a fully English like language be incepted
into python, my main point here was that there are cases where the order of
arguments is important and being able to have actually positional arguments
would go a long way to improving knowing intuitively that order.
On 2021-10-18 15:58, Steven D'Aprano wrote:
On Mon, Oct 18, 2021 at 10:20:17AM -, Mathew Elman wrote:
despite a driving idea of python syntax being readability in
english, the function signature is distinctly not english.
Python's syntax was not really modelled on English, as far as I can
On 2021-10-18 11:20, Mathew Elman wrote:
I don't know if this has been suggested before, or if this is outlandishly
impossible (though I would be surprised if it was), so apologies in advance if
so.
I have on occasion come across a situation where I use/write a signature like
this:
def
On Mon, Oct 18, 2021 at 10:20:17AM -, Mathew Elman wrote:
> despite a driving idea of python syntax being readability in
> english, the function signature is distinctly not english.
Python's syntax was not really modelled on English, as far as I can
tell. It was (I think) modelled more on P
I kind of like this idea. I wrote this curry helper module as a proof of
concept of how to implement it in Python, today, without having to add
features:
https://gist.github.com/Ricyteach/b290849da903135a1ed5cce9b161b8c9
Using that, you can write code like this:
from typing import Any
@curry_he
> What you are describing is very, very dissimilar to currying. It's simply
> multi-argument functions with a different call syntax.
It is almost identical to currying, the only differences are:
1. the intermediate return being an object with an attribute (rather than a new
function) that you ca
Paul Moore wrote:
> On Mon, 18 Oct 2021 at 12:49, Mathew Elman mathew.el...@ocado.com wrote:
> > The point is that at the moment to set this sort of api up requires a lot
> > of work, defeating 50% of the value i.e. to define a new function with the
> > attribute access behaviour requires definin
On Mon, 18 Oct 2021 at 12:49, Mathew Elman wrote:
>
> The point is that at the moment to set this sort of api up requires a lot of
> work, defeating 50% of the value i.e. to define a new function with the
> attribute access behaviour requires defining each individual function to
> return a midd
What you are describing is very, very dissimilar to currying. It's simply
multi-argument functions with a different call syntax.
Moreover, this hypothetical syntax would make no sense at all for 99% of
the functions I write or call. There are a very small number of functions
where a conceivable be
> Still, I don't want Python to try to be Cobol.
I agree, I don't want Python to try and be Cobol, but that doesn't mean there
aren't things to learn from Cobol regarding this, if this indeed something
found there - I can't comment on that.
> I think the intellectual argument for "English synt
What you want was popular in Cobol. That language has generally lost favor
for current development, but lots of it is still around.
Still, I don't want Python to try to be Cobol. I think the intellectual
argument for "English syntax" failed, notwithstanding installed base.
On Mon, Oct 18, 2021, 3
The point is that at the moment to set this sort of api up requires a lot of
work, defeating 50% of the value i.e. to define a new function with the
attribute access behaviour requires defining each individual function to return
a middle step object that has the attribute of the next function, s
That is interesting but is missing the point of what I am really getting at, in
order to build a function of multiple args this way would require a lot of
these "operators" that would need to be interchangeable, so I don't think what
I am looking for is an operator.
The key point being having
On Mon, 18 Oct 2021 at 11:20, Mathew Elman wrote:
>
> I don't know if this has been suggested before, or if this is outlandishly
> impossible (though I would be surprised if it was), so apologies in advance
> if so.
>
> I have on occasion come across a situation where I use/write a signature lik
On Mon, Oct 18, 2021 at 9:22 PM Mathew Elman wrote:
>
> I don't know if this has been suggested before, or if this is outlandishly
> impossible (though I would be surprised if it was), so apologies in advance
> if so.
As stated, it basically is but the cool thing about crazy ideas
is, there
27 matches
Mail list logo
