LangWart: Method congestion from mutate multiplicty

[Steven D'Aprano]

Rick Johnson wrote:

> 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--, 

And you have missed my point, which is that reversed(), and sorted(), were
not added to the language on a whim, but because they were requested, over
and over and over again. People who actually programmed using Python before
reversed() and sorted() were added missed them, and consequently kept
reimplementing them.

You want to go back to the Bad Old Days when everyone was reimplementing the
same few functions over and over again. I say, boo sucks to that.


> 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

Yes.


> Hell, why stop there:
> 
>  append, appended

"appended" is called list addition.

newlist = oldlist + [item_to_append]


>  flatten, flattened

flatten is another often requested, hard to implement correctly, function.
The only reason that Python doesn't have a flatten is that nobody can agree
on precisely what it should do.

Like map, filter, reduce, etc. flatten is not sensibly implemented as a
mutator method, but as a function.


>  insert, inserted

"inserted" is called addition, together with list slicing when needed.

newlist = [item_to_insert] + oldlist
newlist = oldlist[0:5] + [item_to_insert] + oldlist[5:]


>  map, mapped
>  filter, filtered
>  reduce, reduced

Those are nonsense. None of those are in-place mutator methods. Especially
reduce, which reduces a list to a single item. You might as well have
suggested "len, "lened".


>  extend, extended

Again, "extended" is spelled list addition.

Are you sure you've actually programmed in Python before? You seem awfully
ignorant of language features.


[...]
> My point was this: All mutate methods should mutate "in-place",

Well duh. All mutator methods do mutate in-place, otherwise they wouldn't be
mutator methods.


> 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.

Been there, done that, it sucks. That's about a dozen steps backwards to a
worse time in Python development.



-- 
Steven