David> I think it should do the former (otherwise something about
David> 'string' should be in the name), and as a consequence I think it
David> shouldn't have the default whitespace spacer.
Perhaps "joinstrings" would be an appropriate name (though it seems
gratuitously long) or join should call str() on non-string elements.
My thought here is that we have left in the string module a couple functions
that ought to be string object methods but aren't yet mostly for convenience
or time constraints, and one (join) that is 99.9% of the time used on lists
or tuples of strings. That leaves a very small handful of methods that
don't naturally fit somewhere else. You can, of course, complete the
picture and add a join method to string objects, which would be useful to
explode them into individual characters. That would complete the
join-as-a-sequence-method picture I think. If you don't somebody else (and
not me, cuz I'll know why already!) is bound to ask why capwords, join,
ljust, etc got left behind in the string module while all the other
functions got promotions to object methods.
Oh, one other thing I forgot. Split (join) and splitfields (joinfields)
used to be different. They've been the same for a long time now, long
enough that I no longer recall how they used to differ. In making the leap
from string module to string methods, I suggest dropping the long names
altogether. There's no particular compatibility reason to keep them and
they're not really any more descriptive than their shorter siblings. It's
not like you'll be preserving backward compatibility for anyone's code by
having them. However, if you release this code to the larger public, then
you'll be stuck with both in perpetuity.
Skip
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4