LangWart: Method congestion from mutate multiplicty

[Steven D'Aprano]

Mark Janssen wrote:

> On Sat, Feb 9, 2013 at 8:20 PM, Chris Angelico <rosuav at gmail.com> wrote:
>> On Sun, Feb 10, 2013 at 2:54 PM, Rick Johnson
>> <rantingrickjohnson at gmail.com> wrote:
>>> 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.
>>
>> I agree. And we can go further and declare that there is only one data
>> [sarcasm]
> 
> I have to agree with Rick, I think requiring the user to explicitly
> create a new object, which is already a good and widely-used practice,

Perhaps so, but consider how you creates new objects in Python. Very rarely
do you do so with an explicit call to the constructor. For example:

n = 5  # Yes.
# or
n = int("5")  # No.

alist = some_list[1:]  # Yes.
# or
alist = list()
alist.extend(some_list[1:])  # No.

items = sorted(other_things + [1])  # Yes.
# or
items = other_things[:]
items.append(1)
items.sort()  # Hell no.


There are many functions or methods that create new objects, apart from the
constructor. A call like:

    blist = sorted(alist)

is no less explicitly creating a new list than:

    blist = list(alist)


> should be the Only One Way to Do It.

Pardon me, but you've been listening to too many Perl developers. "Only One
Way To Do It" is not, and never has been, the motto of Python. You may be
thinking of the line from the Zen of Python:

py> import this
[...]
There should be one-- and preferably only one --obvious way to do it.


The emphasis is on the *obvious*, not the "only". There is an enormous
difference between prohibiting a second way to solve problems ("Only One
Way") and recommending that there should be an Obvious Way.


> Guessing method names is far 
> suboptimal to this simple, easy idiom.  As for the point Chris was
> making as to making all types one, I actually agree there too,

Oh dear. Chris was being sarcastic. I thought that, even if the sarcasm
wasn't obvious, his "Ook. Ook!" at the end should have given it away:

http://www.dangermouse.net/esoteric/ook.html


> it's 
> just that in order to do that, python would need a unified object
> model and it doesn't have one yet.


I'm not sure what you mean by "unified object model", but I'm pretty sure
that Python has one. Everything is an object, with a single[1] hierarchy of
classes.



[1] Python 3 only. In Python 2, you have types, and you have old-style
classes, and they are separate.

-- 
Steven