[Python 3.4] Rationale for readonly slice data attributes

[Mario Figueiredo]

On Thu, 5 Mar 2015 23:36:47 -0700, Ian Kelly <ian.g.kelly at gmail.com>
wrote:

>
>I'm not following what it is that you want to accomplish in this
>example by modifying the slice object.

Yeah. That code doesn't show anything. It was just meant to illustrate
what I was doing, not how. But in retrospect it just made my post more
confusing to follow.

>
>Immutable types are often desirable because they're easier to reason
>about, especially when concurrency enters the picture. As an example,
>suppose I'm iterating over a view constructed by slicing some
>collection. What should happen if the slice is suddenly altered in
>mid-iteration? Because slice objects are immutable, this is a question
>that doesn't even need an answer.

But that doesn't break the consenting adults principle? I mean the
class slice is a typical API structure. May be inspected inside a
__getitem__ method override (note: I can provide a real-life example
of the need to inspect and act upon slide object instances, but I
suspect you know of it already). As an API structure I would expect it
to let me operate as I see fit. Including changing its state. The only
exception would be an actual and plausible requirement for data to
stay immutable.

>
>slice is about as light-weight a class as they come. If you need to
>modify a slice, is there any reason you can't just construct a new
>one?
>

It's what I did. Like I said it's not a big deal. Other solutions
abound. I am just curious at what actually makes it a requirement that
slice data members are made readonly. That is my question.

In OOP I'm not just going to code readonly properties because I can. I
will do it because I `must`. And I don't see why slice must have
readonly properties.

There's not many reasons why I actually need a readonly property.
Maintaining an object internal consistency might be one of those. But
slice is basically just a struct and it has no other features.