In funcoperators, because the dot operator is just syntaxic sugar for
functions getattr and setattr with a string,
a.hello.world
# can be implemented using infix
a -o- 'hello' -o- 'world'
# or using postfix
a |dot('hello') |dot('world')
# using
from funcoperators import postfix, infix
o = infix(getattr)
def dot(n):
return postfix(lambda x: getattr(x, n))
For methods, one could write :
a.upper().replace('x', 'y')
# can be implemented by
a |meth('upper') |meth('replace', 'x', 'y')
# using
def meth(x, *a, **b):
return postfix (lambda self: getattr(self, x)(*a, **b))
And one could do
upper = postfix(str.upper)
def replace(*a, **b):
return postfix(lambda self: self.replace(*a, **b))
# to be able to do :
a |upper |replace('a', 'b')
And of course you can create your own functions to have the behavior you
want.
robertvandeneynde.be
On Thu, 21 Feb 2019, 13:22 Steven D'Aprano, <[email protected]> wrote:
> Correcting myself twice now, that's not a good sign... :-)
>
> On Thu, Feb 21, 2019 at 12:55:00PM +1100, Steven D'Aprano wrote:
>
> > But there's a deeper problem with this entire concept, regardless of
> > syntax, one which to my knowledge nobody has mentioned yet: it simply
> > isn't compatible with the way operators work in Python at the moment.
> > More on this in another post (coming soon).
>
> On further thought, I would like to withdraw that claim.
>
> Actual operators like + - etc of course are implemented using dunder
> methods, but "pseudo-operators" like the dot aren't. If we had such a
> fluent method chain operator, it would be more like dot than ordinary
> operators.
>
>
>
> --
> Steven
> _______________________________________________
> Python-ideas mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
