I think the actual proposal is having a new type of list (ie : vectors) that works like numpy but for any data.
Instead of a list where the user has to be sure all the data is the same type, vectors makes him-er sure it's full of the same data than can me processed using a particular function (as s-he would do with map).

I think the syntax proposed is not cool, it's kinda unique in python and doesn't feel pythonic to me. A thing I thought about but I'm not satisfy is using the new matrix-multiplication operator:

    my_string_vector @ str.lower

    def compute_grad(a_student):
        return "you bad"
    my_student_vector @ compute_grad

But it's a bit confusing to me.

Le ven. 1 févr. 2019 à 17:04, Kirill Balunov <kirillbalunov@gmail.com> a écrit :


пт, 1 февр. 2019 г. в 02:24, Steven D'Aprano <steve@pearwood.info>:
On Thu, Jan 31, 2019 at 09:51:20AM -0800, Chris Barker via Python-ideas wrote:

> I do a lot of numerical programming, and used to use MATLAB and now numpy a
> lot. So I am very used to "vectorization" -- i.e. having operations that
> work on a whole collection of items at once.
[...]
> You can imagine that for more complex expressions the "vectorized" approach
> can make for much clearer and easier to parse code. Also much faster, which
> is what is usually talked about, but I think the readability is the bigger
> deal.

Julia has special "dot" vectorize operator that looks like this:

     L .+ 1   # adds 1 to each item in L

     func.(L)   # calls f on each item in L

https://julialang.org/blog/2017/01/moredots

The beauty of this is that you can apply it to any function or operator
and the compiler will automatically vectorize it. The function doesn't
have to be written to specifically support vectorization.


IMO, the beauty of vector type is that it contains homogeneous data. Therefore, it allows you to ensure that the method is present for each element in the vector. The first given example is what numpy is all about and without some guarantee that L consists of homogeneous data it hardly make sense. The second one is just `map`. So I can't catch what you are proposing:

1. To make an operator form of `map`.
2. To pull numpy into stdlib.
3. Or something else, which is not obvious to me from the examples given.

With kind regards,
-gdg
 

> So what does this have to do with the topic at hand?
>
> I know that when I'm used to working with numpy and then need to do some
> string processing or some such, I find myself missing this "vectorization"
> -- if I want to do the same operation on a whole bunch of strings, why do I
> need to write a loop or comprehension or map? that is:
>
> [s.lower() for s in a_list_of_strings]
>
> rather than:
>
> a_list_of_strings.lower()

Using Julia syntax, that might become a_list_of_strings..lower(). If you
don't like the double dot, perhaps str.lower.(a_list_of_strings) would
be less ugly.



--
Steven
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/