[Python-ideas] Vectorization [was Re: Add list.join() please]

[Adrien Ricocotam]

@David Mertz <mertz at gnosis.cx>
 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 at gnosis.cx> a écrit :

> On Sun, Feb 3, 2019 at 3:16 PM Ronald Oussoren <ronaldoussoren at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20190203/66552a46/attachment.html>