Consistency in Python

[Paul Boddie]

Paul McGuire wrote:
>
> There's nothing wrong with returning self from a mutator.  This was a common
> idiom in Smalltalk (the syntax for this was "^self", which was probably the
> most common statement in any Smalltalk program), and permitted the chaining
> of property mutators into a single line, each invoking a mutator and
> returning self, which was then used to invoke the next mutator, etc.

Various Java APIs encourage this kind of behaviour, too, or at least
encouraged it in earlier times. However, as I wrote, there is some kind
of understanding that undoubtedly results from a policy decision in the
design of Python's built-in types that saves the programmer from having
to question the nature of a return value in such a way.

[...]

> But with mutators that return self, a client could write any of these:
>
> bx = Box().length(100).width(50).height(20)
> bx = Box().width(50).height(20).length(100)
> bx = Box().width(50).length(100).height(20)
> ...etc...
>
> and the results are the same.

This is very convenient, and I've often thought about doing such things
in my own APIs, but there can sometimes be subtle problems introduced
into programs when you decide to change the nature of such a mutator,
or if you have another type/class whose mutators are of a different
nature, such that the width method produces a new Box object (which is
quite similar to what the questioner seemed to have in mind) instead of
mutating (or failing to mutate) the existing object.

Indeed, it may be important to know whether you're creating new objects
or not, and without metadata the most convenient way to communicate
this is quite probably to define a rigid interface (after all, why
should width or append return an object?) which cannot be implemented
on immutable things.

Paul