LangWart: Method congestion from mutate multiplicty
Rick Johnson
rantingrickjohnson at gmail.com
Sat Feb 9 22:54:11 EST 2013
On Friday, February 8, 2013 9:36:52 PM UTC-6, Steven D'Aprano wrote:
> Rick Johnson wrote:
>
> > The solution is simple. Do not offer the "copy-mutate" methods and force
> > all mutation to happen in-place:
> >
> > py> l = [1,2,3]
> > py> l.reverse
> > py> l
> > [3,2,1]
> >
> > If the user wants a "mutated copy" he should explicitly create a new
> > object and then apply the correct mutator method:
> >
> > py> a1 = [1,2,3]
> > py> a2 = list(a1).reverse()
>
> Oh wow, Rick has re-discovered programming in Python during the mid to late
> 1990s!
>
> [...snip: long-winded, rambling, and sarcastic response simply to convey
> that Python lists have had a "reversed" method for some time...]
Steven, i am quite aware of the Python list method "reversed" --which returns a copy of the current list object in reversed order--, my point is that these types of "copy-mutate" methods superfluously pollute the object namespace. Do you really want "method pairs" like these:
sort, sorted
reverse, reversed
Hell, why stop there:
append, appended
flatten, flattened
insert, inserted
map, mapped
filter, filtered
reduce, reduced
extend, extended
freeze, frozen
set, sat|setted
unique, uniqued
Is this really what you prefer? Where does the madness end Steven? At what point do you say enough is enough? And what happens if you fail to catch the infection early enough? Steven, this is a /real/ problem which has the potential to go viral!
My point was this: All mutate methods should mutate "in-place", if the programmer wishes to create a mutated copy of the object, then the programmer should /explicitly/ create a copy of the object and then apply the correct mutator method to the copy.
NO: reversed = lst.reversed() # Python
YES: reversed = list(lst).reverse() # Python
NO: reversed = a.reverse() # Ruby
YES: reversed = Array.new(a).reverse!() # Ruby
This is about consistency and keeping the number of methods from spiraling out of control because we feel the need to automate /every/ task for the programmer, when in actuality, we are doing more harm than good.
More information about the Python-list
mailing list