On Sunday, February 10, 2013 6:36:20 PM UTC-6, Steven D'Aprano wrote: > Rick Johnson wrote: > > On Sunday, February 10, 2013 5:29:54 AM UTC-6, Steven D'Aprano wrote: > >> Rick wrote: > > [...] > > Steven, the definition of flatten (as relates to sequences) is very, VERY > > simple: > > > > Return a new sequence that is the result of reducing > > a nested sequence of sequences into a single depth > > sequence. > > Very, VERY simple until you actually implement this function, and discover > that it does too much e.g.
I would implement it as a method of sequence types, but i digress! > flatten([None, 23, [1, 2, 3], Point(x=2, y=3), ["spam", "ham"]]) > => [None, 23, 1, 2, 3, 2, 3, 's', 'p', 'a', 'm', 'h', 'a', 'm'] > > So people who have *actually programmed*, instead of just talking about > programming, have discovered that in practice you need to treat some > sequences as primitives that don't get expanded. Which primitive(s) should NOT have been expanded in your opinion? The "Point" object? I agree, that's why MY implementation would call seq.flatten() on all sub-sequences THEREBY allowing each subtype to define it's own flatten behavior. Of course the default behavior of the SequenceBase#flatten would be to flatten everything. However, ImmutableSequence Types would not flatten. In your example ["spam", "ham"] would not be expanded to ['s', 'p', 'a', 'm', 'h', 'a', 'm']. psst: strings and tuples are immutable! I'm not convinced that flattening immutable types is a good idea anyway, because heck, they're designed to be immutable! I suppose if we are not flattening "in-place" it really would not matter though. Creating a new immutable object that is the result of reordering an existing immutable object's values is not mutation. -- http://mail.python.org/mailman/listinfo/python-list