[Python-ideas] textFromMap(seq , map=None , sep='' , ldelim='', rdelim='')

[spir]

On Wed, 27 Oct 2010 03:09:23 +1100
Steven D'Aprano <steve at pearwood.info> wrote:

> Boris Borcic wrote:
> 
> > And let's then propagate that notion, to a *coherent* definition of 
> > split that makes it as well a method on the separator.
> 
> Let's not.
> 
> Splitting is not something that you on the separator, it's something you 
> do on the source string. I'm sure you wouldn't expect this:
> 
> ":".find("key:value")
> => 3
> 
> Nor should we expect this:
> 
> ":".split("key:value")
> => ["key", "value"]
> 
> 
> You perform a search *on* the source string, not the target substring. 
> Likewise you split the source string, not the separator.

I completely share this view.
Also, when one needs to split on multiple seps, repetitive seps, or even more complex separation schemes, it makes even less sense to see split applying on the sep, instead of on the string. Even less when splitting should remove empty parts generated by seps at both end or repeted seps. Note that it's precisely what split() without sep does:

>>> s = " some \t little   words  "
>>> s.split()
['some', 'little', 'words']
>>> s.split(' ')
['', 'some', '', 'little', '', '', 'words', '', '']

Finally, in any of such cases, join is _not_ a reverse function for split. split in the general case is not reversable because there is loss of information. It is possible only with a pattern limited to a single sep, no (implicit) repetition, and keeping empty parts at ends. Very fine that python's split semantics is so defined, one cannot think at split as reversible in general (*). 

Denis

(*) Similar rule: one cannot rewrite original code from an AST: there is loss of information. One can only write code in a standard form that has same semantics (hopefully).
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com