- Even in the absence of partial or currying, the decorator operator remains advantageous. The examples shown in the Application part of initial post did not utilize either partial or currying.
- Features akin to partial or currying can be implemented using decorators. For instance, decorating
smart_partial, as introduced in this post, allows for the integration of partial functionality into numerous functions. - Improvements can be made through adding a library. Just as
itertoolscollates utilities for iterables, andcontextlibgathers utilities related to the with-statement, adding a library that collects decorator-related utilities would make the decorator operator more convenient. - Built-in functions and standard libraries can progressively add features for the decorator operator. For instance, a feature corresponding to
smart_partialcould be fundamentally incorporated. - For these reasons, there is no immediate necessity for the implementation of partial or curring at the language level to coincide with the decorator operator. Similar to the way Python initially introduced TypeVar and later supplemented it with the type parameter syntax, Once the decorator operator is initially implemented, additional functionalities could be introduced as developers become more accustomed to it.
Note: The aforementioned smart_partial has the ability to transform a function into a partial function when a function has insufficient arguments. Therefore, it can be used with the decorator operator while maintaining compatibility.
# Applying smart_partial to map
map @= smart_partial
# Using the existing function style: possible
print(tuple(map(lambda x: x ** 2, range(10))))
# Using the decorator style: possible
10 @range @map(lambda x: x ** 2) @tuple @print
# output: (0, 1, 4, 9, 16, 25, 36, 49, 64, 81)