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

[Adrien Ricocotam]

I honestly don’t understand what you don’t like the @ syntax.

My idea is using functions that takes on argument : an object of the type
of the vector. That’s actually how map works.

What I understood from your previous message is that there’s ambiguity when
using magic functions on whether it’s applied to each element of the vector
or the vector itself. That was the first thing I saw.

While reading your examples, I noticed that you were using «
my_vec.function() ». You just said that we will not code the « .function »
for any function. That’s the other problem I wanted to address with the @
notation.

Functions that could be used are then the same we can use in map. But I do
agree it’s not easy to have functions with parameters. That’s why I used
functools.partial

On Sun 3 Feb 2019 at 19:23, David Mertz <mertz at gnosis.cx> wrote:

> On Sun, Feb 3, 2019 at 3:54 AM Adrien Ricocotam <ricocotam at gmail.com>
> wrote:
>
>> I think all the issues you have right now would go of using another
>> operation. I proposed the @ notation that is clear and different from
>> everything else,
>>
> plus the operator is called "matmul" so it completely makes sense. The the
>> examples would be :
>>
>
>
>> >>> l = "Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec".split()
>> >>> v = Vector(l)
>> >>> len(v)
>> 12
>> >>> v @ len
>> <Vector of [3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3]>
>>
>
> I cannot really see how using the @ operator helps anything here.  If this
> were a language that isn't Python (or conceivably some future version of
> Python, but that doesn't feel likely or desirable to me), I could imagine @
> as an operator to vectorize any arbitrary sequence (or iterator).  But
> given that we've already made the sequence into a Vector, there's no need
> for extra syntax to say it should act in a vectorized way.
>
> Moreover, your syntax is awkward for methods with arguments.  How would I
> spell:
>
> v.replace('foo', 'bar')
>
>
> In the @ syntax? I actually made an error on my first pass where simply
> naming a method was calling it.  I thought about keeping it for a moment,
> but that really only allows zero argument calls.
>
> I think the principled thing to do here is add the minimal number of
> methods to Vector itself, and have everything else pass through as
> vectorized calls.  Most of that minimal number are "magic method":
> __len__(), __contains__(), __str__(), __repr__(), __iter__(),
> __reversed__().  I might have forgotten a couple.  All of those should not
> be called directly, normally, but act as magic for operators or built-in
> functions.
>
> I think I should then create regular methods of the same name that perform
> the vectorized version.  So we would have:
>
> len(v)   # -> 12
>
> v.len()  # -> <Vector of [3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3]>
>
> list(v)  # -> ["Jan", "Feb", "Mar", "Apr", "May", "Jul" ...]
> v.list() # -> <Vector of [["J", "a", "n"], ["F", "e", "b"] ... >
>
>
> I can't implement every single constructor that users might
> conceivably want, of course, but I can do it for the basic types in
> builtins and common standard library.  E.g. I might do:
>
> v.deque() # -> <Vector of [deque(["J", "a", "n"]), deque(["F", "e", "b"])
> ... >
>
>
> But I certainly won't manually add:
>
> v.custom_linked_list()  # From my_inhouse_module.py
>
>
> Hmm... maybe even I could look at names of maybe-constructors in the
> current namespace and try them.  That starts to feel too magic.  Falling
> back to this feels better:
>
> map(custom_linked_list, v)  # From my_inhouse_module.py
>
>
>
> --
> 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/cdc68c57/attachment-0001.html>