On Thu, 5 Mar 2015 23:36:47 -0700, Ian Kelly <ian.g.ke...@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. -- https://mail.python.org/mailman/listinfo/python-list
