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 firstname.lastname@example.org wrote:
On Sun, Feb 3, 2019 at 3:54 AM Adrien Ricocotam email@example.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)
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:
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.