Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #86969 > unrolled thread

[Python 3.4] Rationale for readonly slice data attributes

Back to article view | Back to comp.lang.python

Contents

  [Python 3.4] Rationale for readonly slice data attributes Mario Figueiredo <marfig@gmail.com> - 2015-03-06 00:57 +0100
    Re: [Python 3.4] Rationale for readonly slice data attributes Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-05 23:36 -0700
      Re: [Python 3.4] Rationale for readonly slice data attributes Mario Figueiredo <marfig@gmail.com> - 2015-03-07 16:59 +0100

#86969 — [Python 3.4] Rationale for readonly slice data attributes

What is the rationale behind making the slice class data attributes
readonly?

I've built a __getitem__ method for a Map class that contains a list
of Cell instance objects. __getitem__ maps this list into a matrix::

    # get cell at cartesian coordinates 12, 4
    # will map to the 1048th position in the cells list
	mmap = Map()
    print(mmap[12, 4])

All is working well and it even supports slicing::

	# return all cells with x between 3 and 6 and y up until 4
	mmap = Map()
    [print(cell) for cell in mmap(3:6, :4)]

This last example is one case in which I missed the ability to change
the the `start` and `stop` attributes of the slice class in order for
the maping to occur that allows a 2-dimensions access to a 1-dimension
list.

It was solved by taking another turn, but it proved to me that the
slice data attributes are more useful if they are writable, and this
clashes tremendously with the principles of data encapsulation that
underline the requirements for a readonly property. In other words, if
it needs to be accessed, don't hide it. If it needs to be written,
don't lock it.

Now, normally I take these things for granted. Rules are rules and
their reasons are often fairly obvious. But in this case I'm at loss.
I can't find a reason for this class attributes to have been made into
readonly properties.

[toc] | [next] | [standalone]

#86989

On Thu, Mar 5, 2015 at 4:57 PM, Mario Figueiredo <marfig@gmail.com> wrote:
> What is the rationale behind making the slice class data attributes
> readonly?
>
> I've built a __getitem__ method for a Map class that contains a list
> of Cell instance objects. __getitem__ maps this list into a matrix::
>
>     # get cell at cartesian coordinates 12, 4
>     # will map to the 1048th position in the cells list
>         mmap = Map()
>     print(mmap[12, 4])
>
> All is working well and it even supports slicing::
>
>         # return all cells with x between 3 and 6 and y up until 4
>         mmap = Map()
>     [print(cell) for cell in mmap(3:6, :4)]
>
> This last example is one case in which I missed the ability to change
> the the `start` and `stop` attributes of the slice class in order for
> the maping to occur that allows a 2-dimensions access to a 1-dimension
> list.

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

> It was solved by taking another turn, but it proved to me that the
> slice data attributes are more useful if they are writable, and this
> clashes tremendously with the principles of data encapsulation that
> underline the requirements for a readonly property. In other words, if
> it needs to be accessed, don't hide it. If it needs to be written,
> don't lock it.
>
> Now, normally I take these things for granted. Rules are rules and
> their reasons are often fairly obvious. But in this case I'm at loss.
> I can't find a reason for this class attributes to have been made into
> readonly properties.

You also can't mutate bound methods, range objects, or ints. Do any of
those bother you?

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.

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?

Lastly, if you really want a mutable "slice", you can work around this
by using a 3-element list and construct a slice from it on demand.

[toc] | [prev] | [next] | [standalone]

#87097

On Thu, 5 Mar 2015 23:36:47 -0700, Ian Kelly <ian.g.kelly@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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web