Monday, September 04, 2006

» No builtin flatten in python... +

One view of why there is no built-in flatten in python is that "there are several open semantic questions which are not intuitively answered". But that seems like a cop-out. So what if there are some academic questions about what exactly a flatten method should do? The basic fact of the matter is that people want a method to be able to flatten a multi-dimensional list into a single dimension. Philosophical questions aside, there should be a built-in method to do this. Special cases should be treated as special; let the implementors in those cases create a custom flatten method that will do what they want; edge-cases should never dictate the behavior of the core language. Bottom line is that a flatten method is used often enough to warrent inclusion as a built-in method, even if it doesn't frost the cheerios of every single person who might ever use it.


Anonymous Steven D'Aprano said...

I've been programming with Python for about 14 years, and I've never needed a flatten function. I have frequently *thought* I needed one, but on further thought I have always ended up following the Zen: Flat is better than nested.

The problem with flatten is that it is not the case that there is one obvious behaviour to solve 90% of the use-cases, leaving 10% of the tricky cases for custom implementations. It's more like three or four somewhat obvious behaviours covering 50% of the use-cases, and a multitude of other alternatives.

E.g. do you treat strings as iterables to be flattened, or as atoms to be left alone? How about tuples? Tuples frequently are used as records, not sequences (e.g. coordinates). NamedTuple? Dicts are iterable too, should they be flattened? Do you want the dict keys, values or items?

These are not "academic questions", but get to the heart of the matter: any decision as to what should be treated as composite and what is an atom is application specific.

So what should the Python standard library do?

- implement flatten1, flatten2, flatten3, ... builtins

- implement just one flatten, and leave 90% of users confused and angry that it's "broken and useless"

- implement one flatten with a hideously ugly and complicated API to cover all the "obvious" cases, and people still won't use it because it's too hard and confusing to use

- say "bugger it" and just let people implement it themselves, since it is pretty trivial to roll your own.

Flattening nested iterables is a deceptively simple design problem, not a coding problem.
June 18, 2012 at 9:52 PM


Post a Comment

Links to this post:

Create a Link

<< Home