@David Mertz
 I think I can't explain well my ideas ^^. I'll try to be really detailed so I'm not sure I'm actually saying what I'm thinking.

Let's consider the idea of that Vector class this way :
Vectors are list of a defined type (may be immutable ?) and adds sugar syntaxing for vectorized operations.

Based on this small and not complete enough definition, we should be able to apply any function to that vector.
I identify two ways functions are used with  vectors : it's either applied on the vector as an iterable/list, or on the elements of this vector.
Thus, we need to be have different notations for those two uses. To keep it coherent with  Python, if a functions is applied on the vector as an iterable,
the vector is given as a parameter :

>>> len(v)  # Number of elements in the Vector `v`

If we want to apply a function on each element of the list, we should then use another notations. So far, several have been proposed.
In the following example showing the different notations, we use the generic way so we can apply it to user-defined functions :

>>> # Compute the length of each element of the Vector `v`
>>> v.apply(len)
>>> v @ len

Another example with parameters
>>> # Replace all "a" by "b"
>>> v.apply(lambda s: s.replace("a", "b"))
>>> v @ (lambda s: s.replace("a", "b"))

My personal opinion is that the two notations feel good. One is standard, the other is not but is less verbose and it's a good point.

Now that I detailed everything in my brain and by mail, I guess we are just saying the same thing !

There's something I didn't mention on purpose, it's the use of : `v.lower()`
I think having special cases of how vectors works is not a good idea : it's confusing.
If we want the user to be able to use user-defined functions we need a notation. Having something different for some
of the functions feels weird to me. And obviously, if the user can't use its own functions, this whole thing is pretty useless.

Tell me if I got anything wrong.

Nb : I found a way to simplify my previous example using lambda instead of partial.

Le dim. 3 févr. 2019 à 21:34, David Mertz <mertz@gnosis.cx> a écrit :
On Sun, Feb 3, 2019 at 3:16 PM Ronald Oussoren <ronaldoussoren@mac.com> wrote:
The @ operator is meant for matrix multiplication (see PEP 465) and is already used for that in NumPy. IMHO just that is a good enough reason for not using @ as an elementwise application operator (ignoring if having an such an operator is a good idea in the first place).

Co-opting operators is pretty common in Python.  For example, the `.__div__()` operator spelled '/' is most often used for some kind of numeric division.  Some variations on that, for example vectorized in NumPy.  And different numeric types operate a bit differently.  The name of the magic method obvious suggests division.

And yet, in the standard library we have pathlib which we can use like this (from the module documentation):
>>> p = Path('/etc')
>>> q = p / 'init.d' / 'reboot'
That use is reasonable and iconic, even if it is nothing like division.

The `.__mod__()` operator spelled '%' means something very different in relation to a float or int object versus a string object.  I.e. modulo division versus string interpolation.

I've even seen documentation of some library that coopts `.__matmul__()` to do something with email addresses.  It's not a library I use, just something I once saw the documentation on, so I'm not certain of details.  But you can imagine that e.g. :

email = user @ domain

Could be helpful and reasonable (exact behavior and purpose could vary, but it's "something about email" iconically).

In other words, I'm not opposed to using the @ operator in my stringpy.Vector class out of purity about the meaning of operators.  I just am not convinced that it actually adds anything that is not easier without it.
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.