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)
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", "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:]
<Vector of ['Feb', 'Mar', 'Apr', 'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct',
'Nov', 'Dec']>
>>> my_slice = slice(1, None, None)
>>> indexing_operation = partial(operator.getitem(my_slice))
>>> v @ indexing_operation
<Vector of ['an', 'eb', 'ar', 'pr', 'ay', 'un', 'ul', 'ug', 'ep', 'ct',
'ov', 'ec']>
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 <me...@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/
>
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
