<div dir="ltr"><div>Many apologies if people got one or more encrypted versions of this.</div><div><br></div>On 2/7/19 12:13 AM, Steven D'Aprano wrote:<br><br>It wasn't a concrete proposal, just food for thought. Unfortunately the <br>thinking seems to have missed the point of the Julia syntax and run off <br>with the idea of a wrapper class.<br><br>I did not miss the point! I think adding new syntax à la Julia is a bad<br>idea—or at very least, not something we can experiment with today (and<br>wrote as much).<br><br>Therefore, something we CAN think about and experiment with today is a<br>wrapper class.  This approach is pretty much exactly the same thing I<br>tried in a discussion of PEP 505 a while back (None-aware operators).<br>In the same vein as that—where I happen to dislike PEP 505 pretty<br>strongly—one approach to simulate or avoid new syntax is precisely to<br>use a wrapper class.<br><br>As a footnote, I think my demonstration of PEP 505 got derailed by lots<br>of comments along the lines of "Your current toy library gets the<br>semantics of the proposed new syntax wrong in these edge cases."  Those<br>comments were true (and I think I didn't fix all the issues since my<br>interest faded with the active thread)... but none of them were<br>impossible to fix, just small errors I had made.<br><br>With my *very toy* stringpy.Vector class, I'm just experimenting with<br>usage ideas.  I have shown a number of uses that I think could be useful<br>to capture most or all of what folks want in "string vectorization."<br>Most of what I've but in this list is what the little module does<br>already, but some is just ideas for what it might do if I add the code<br>(or someone else makes a PR at <a href="https://github.com/DavidMertz/stringpy">https://github.com/DavidMertz/stringpy</a>).<br><br>One of the principles I had in mind in my demonstration is that I want<br>to wrap the original collection type (or keep it an iterator if it<br>started as one).  A number of other ideas here, whether for built-in<br>syntax or different behaviors of a wrapper, effectively always reduce<br>every sequence to a list under the hood.  This makes my approach less<br>intrusive to move things in and out of "vector mode."  For example:<br><br> <font face="monospace, monospace"> v1 = Vector(set_of_strings)<br>  set_of_strings = v1.lower().apply(my_str_fun)._it  # Get a set back<br>  v2 = Vector(list_of_strings)<br>  list_of_strings = v2.lower().apply(my_str_fun)._it # Get a list back<br>  v3 = Vector(deque_of_strings)<br>  deque_of_strings = v3.lower().apply(my_str_fun)._it # Get a deque back<br>  v4 = Vector(iter_of_strings)<br>  iter_of_strings = v4.lower().apply(my_str_fun)._it  # stays lazy!</font><br><br>So this is round-tripping through vector-land.<br><br>Small note: I use the attribute `._it` to store the "sequential thing."<br> That feels internal, so maybe some better way of spelling "get the<br>wrapped thing" would be desirable.<br><br>I've also lost track of whether anyone is proposing a "vector of strings'<br>as opposed to a vector of arbitrary objects.<br><br>Nothing I wrote is actually string-specific.  That is just the main use<br>case stated.  My `stringpy.Vector` might be misnamed in that it is happy<br>to contain any kind of items.  But we hope they are all items with the<br>particular methods we want to vectorize.  I showed an example where a<br>list might contain a custom string-like object that happens to have<br>methods like `.lower()` as an illustration.<br><br>Inasmuch as I want to handle iterator here, it is impossible to do any<br>type check upon creating a Vector.  For concrete<br>`collections.abc.Sequence` objects we could check, in principle.  But<br>I'd rather it be "we're all adults here" ... or at most provide some<br>`check_type_uniformity()` function or method that had to be called<br>explicitly.<br></div>