On 3 Feb., 10:55, Arnaud Delobelle <[EMAIL PROTECTED]> wrote: > On Feb 3, 9:43 am, Kay Schluehr <[EMAIL PROTECTED]> wrote: > > > > > On 3 Feb., 10:13, Arnaud Delobelle <[EMAIL PROTECTED]> wrote: > > > > On Feb 3, 5:09 am, Kay Schluehr <[EMAIL PROTECTED]> wrote: > > > > > As you know, there is no operator for function composition in Python. > > > > When you have two functions F and G and want to express the > > > > composition F o G you have to create a new closure > > > > > lambda *args, **kwd: F (G (*args, **kwd)) > > > > > or you write a composition in functional style > > > > > compose( F, G ) > > > > > None of these solutions is particular terse. > > > > > Proposal > > > > ------------- > > > > I want to propose overloading the logical __and__ operator i.e. '&' > > > > for functions s.t. F & G means "compose(F,G)". This suggestion is non- > > > > conflicting since & is not used as an operator in combination with > > > > function objects yet: given a function object F and an arbitrary > > > > object X the combination F & X raises a TypeError when evaluated. > > > > > Alternatives > > > > ----------------- > > > > One could use other unused operators like F << G or F * G to write > > > > terse function composition expressions. I' m not sure which one is > > > > best and would use the proposed & if no one presents arguments against > > > > it. > > > > What about other callable objects? > > > > -- > > > Arnaud > > > Supporting general callables would be very fine. I thing a callable > > ABC with two protocols named __call__ and __compose__ would be most > > adequate. I'm just not sure if Python 2.X requires a more ad hoc > > implementation for builtin callable types? On the level of user > > defined classes a bundling between __call__ and __compose__ shall > > remain optional ( unlike e.g. the dependency between __iter__ and > > __next__ for iterables ). > > This would conflict with the fact that the operators you suggest for > composition can already be overloaded for other purposes. > > -- > Arnaud
True. Extending a callable ABC by __add__ shall be sufficient and does not cause ambiguities, Just one tiny teardrop for __add__ not being very telling. Otherwise the intended semantics might be constrained to builtin function/method/... types and classes that derive from a callable ABCs. This is sufficient for covering the intended purpose of function composition and does not exclude close relatives ( methods, function-like objects ). How someone assigns semantics to a general __call__ on his own classes is up to him. -- http://mail.python.org/mailman/listinfo/python-list