LangWart: Method congestion from mutate multiplicty
Rick Johnson
rantingrickjohnson at gmail.com
Mon Feb 11 07:53:07 EST 2013
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.
More information about the Python-list
mailing list