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

Groups > comp.lang.python > #11007

Re: Restricted attribute writing

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

I think you might use a tuple instead of a list for OrderElement, that would
make much easier your code:

class
OrderElement(tuple):

    def __new__(cls, x, y):
        if not isinstance(x, int) or not isinstance(y, int):
            raise TypeError("Order element must receives two
integers")

        return tuple.__new__(cls, (x, y))


class Order(list):
    def __setitem__(self, item):
        assert isinstance(item, OrderElement)
        super(Order, self).__setitem__(item)


I didn't check your module condition since it isn't quite clear to me, but
you could add a second condition two Order class.

2011/8/7 Steven D'Aprano <steve+comp.lang.python@pearwood.info>

> Roy Smith wrote:
>
> > In article <mailman.2010.1312731312.1164.python-list@python.org>,
> >  John O'Hagan <research@johnohagan.com> wrote:
> >
> >> I'm looking for good ways to ensure that attributes are only writable
> >> such that they retain the characteristics the class requires.
> >
> > Sounds like you're trying to do
> > http://en.wikipedia.org/wiki/Design_by_contract.  Which is not a bad
> > thing.  But, I think a more pythonic way to implement this would be to
> > verify behaviors, not types.
> >
> > I would start by writing a assert_invarient() method which validates the
> > object.  I'm guessing all you really need is that you can index [0] and
> > [1] and get ints, so test for that.  Something like:
> >
> > def assert_invarient(self):
> >    try:
> >       assert isinstance(data[0], int)
> >       assert isinstance(data[1], int)
> >    except:
> >       raise ValueError
>
> Don't do that. assert is for testing program logic, not verifying data. The
> problem with assert is that the user can turn all assertions off, simply by
> launching Python with the -O switch. Your verification code then becomes:
>
> def assert_invarient(self):
>    try:
>         pass
>    except:
>        raise ValueError
>
> which is useless.
>
> When should you use an assertion? If you've ever written code like this:
>
> if condition:
>    do_something()
> else:
>    # This should never happen. But you know what they say: code that
>    # can't happen, does!
>    raise RuntimeError('condition unexpectedly false')
>
>
> that's a prime candidate for turning into an assertion:
>
>
> assert condition, 'condition unexpectedly false'
> do_something()
>
>
>
> --
> Steven
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Restricted attribute writing John O'Hagan <research@johnohagan.com> - 2011-08-08 01:35 +1000
  Re: Restricted attribute writing Roy Smith <roy@panix.com> - 2011-08-07 12:07 -0400
    Re: Restricted attribute writing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-08 02:31 +1000
      Re: Restricted attribute writing Rafael Durán Castañeda <rafadurancastaneda@gmail.com> - 2011-08-07 18:53 +0200
      Re: Restricted attribute writing Rafael Durán Castañeda <rafadurancastaneda@gmail.com> - 2011-08-07 18:56 +0200
  Re: Restricted attribute writing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-08 03:07 +1000
    Re: Restricted attribute writing Chris Angelico <rosuav@gmail.com> - 2011-08-07 19:21 +0100
    Re: Restricted attribute writing John O'Hagan <research@johnohagan.com> - 2011-08-08 14:59 +1000

csiph-web