[Python-Dev] Iterable String Redux (aka String ABC)

[Raymond Hettinger]

[Armin Ronacher]
> Basically *the* problematic situation with iterable strings is something like
> a `flatten` function that flattens out every iterable object except of strings.

Stated more generally: The problematic situation is that flatten() 
implementations typically need some way to decide what kinds
of objects are atomic.   Different apps draw the line in different places
(chars, words, paragraphs, blobs, files, directories, xml elements with
attributes, xml bodies, csv records, csv fields, etc.).


> A problem comes up as soon as user defined strings (such as UserString) is
> passed to the function.  In my opinion a good solution would be a "String"
> ABC one could test against.

Conceptually, this is a fine idea, but three things bug me.

First, there is a mismatch between the significance of the problem
being addressed versus the weight of the solution.  The tiny
"problem" is a sense that the simplest version of a flatten recipe
isn't perfectly general. The "solution" is to introduce yet another
ABC, require adherence to the huge string API and require that
everything that purports to be a string register itself.  IMO, that is
trying to kill a mosquito with a cannon.

Second, this seems like the wrong solution to the problem
as it places the responsibility in the wrong place and thereby
hardwires its notion of what kind of objects should be split.
A flatten() implementation doesn't really care about whether
an input is a string which supports all the string-like methods
such as capitalize().   Wouldn't it be better to write your 
version of flatten() with a registration function so that a user 
could specify which objects are atomic?  Otherwise, you
will have to continually re-edit your flatten() code as you
run across other non-stringlike objects that also need to
be treated as atomic.

Third, I thought ABCs were introduced as an optional feature
to support large apps that needed both polymorphic object 
flexibility and rigorous API matching.  Now, it seems that 
even the tiniest recipe is going to expose its internals and insist
on objects being registered as one of several supported
abstract types.  I suppose this is better than insisting on one
of several concrete types, but it still smells like an anti-pattern.


Raymond