Nice that you implemented it !

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

>>> list(v)

["Jan", "Feb", "Mar", "Apr", "May", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"]

>>> v @ list

<Vector of [["J", "a", "n"], ["F", "e", "b"], ["M", "a", "r"], ["A", "p", "r"], ["M", "a", "y"], ...]

We still have some issues : how to we treat operators like v[1:].

I suggest using the same syntax : if we don't use @ the operation is done on the vector and not on its elements. Therefore,

v[1:] will remove "Jan" from the vector whereas v @ operator.getitem(slice

>>> from functools import partial

>>> import operator

>>> v[1:]

>>> my_slice = slice(1, None, None)

>>> indexing_operation = partial(operator.getitem(my_slice))

>>> v @ indexing_operation

That little example shows the need of configuring functions so they only accept on argument.

It's actually not a new problem since map have the same "issue".

A vector of one element should still be a vector, as a list/tuple/dict of one element is a list/tuple/dict, imo.

I suggested Vector objects to inherit from lists, and therefore be iterables. It would be handy to iterator over

its elements and simple loops, maps, etc, should still be available to them. It might be clearer to use "old" notations

for some operations.

About the `Vector("A Super String")`, if we want it to be a vector of one element, we should use `Vector(["A Super String"])`,

as we would do in any other function using an iterable as input.

Side Note :

Honestly, I don't think it's the good thread to debate whether we should use ["in", "un", "an", "non"] - homogeneous or heterogeneous.

As long as it's clear, does it matter ?

Le dim. 3 févr. 2019 à 04:19, David Mertz <mertz@gnosis.cx> a écrit :

I think it should follow the pre-existing behaviour of list, set, tuple,
etc.

>>> Vector("hello")
<Vector of ['h', 'e', 'l', 'l', 'o']>

I try to keep the underlying datatype of the wrapped collection as much as possible. Casting a string to a list changes that.

>>> Vector(d)
<Vector of ['Monday', 'Tuesday', 'Wednesday']>
>>> Vector(tuple(d))
<Vector of ('Monday', 'Tuesday', 'Wednesday')>
>>> Vector(set(d))
<Vector of {'Wednesday', 'Monday', 'Tuesday'}>
>>> from collections import deque
>>> Vector(deque(d))
<Vector of deque(['Monday', 'Tuesday', 'Wednesday'])>

Strings are already a Collection, there is not firm need cast them to a list to live inside a Vector. I like the idea of maintaining the original type if someone wants it back later (possibly after transformations of the values).

Why is it pointless for a vector, but not for a list?

I guess it really isn't. I was thinking of just .upper() and .lower() where upper/lower-casing each individual letter is the same as doing so to the whole string. But for .replace() or .count() or .title() or .swapcase() the meaning is very different if it is letter-at-a-time.

I guess a string gets unstringified pretty quickly no matter what though. E.g. this seems like right behavior once we transform something:

>>> vstr = Vector('Monday')
>>> vstr
<Vector of 'Monday'>
>>> vstr.upper()
<Vector of "['M', 'O', 'N', 'D', 'A', 'Y']">

I dunno... I suppose I *could* do `self._it = "".join(self._it)` whenever I do a transform on a string to keep the underlying iterable as a string. But the point of a Vector really is sequences of strings not sequences of characters.

--
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.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/