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

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

Classes

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

Contents

  Classes   Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-30 16:16 -0400
    Re: Classes sohcahtoa82@gmail.com - 2014-10-30 13:33 -0700
      Re: Classes Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-30 17:00 -0400
    Re: Classes Rob Gaddi <rgaddi@technologyhighland.invalid> - 2014-10-30 13:34 -0700
      Re: Classes Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-30 17:00 -0400
    Re: Classes Larry Hudson <orgnut@yahoo.com> - 2014-10-30 14:28 -0700
      Re: Classes Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-30 17:34 -0400
        Re: Classes sohcahtoa82@gmail.com - 2014-10-30 18:21 -0700
        Re: Classes alister <alister.nospam.ware@ntlworld.com> - 2014-10-31 09:59 +0000
          Re: Classes Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-31 10:07 -0400
    Re: Classes   "ast" <nomail@invalid.com> - 2014-10-31 10:05 +0100
      Re: Classes   "ast" <nomail@invalid.com> - 2014-10-31 10:18 +0100
        Re: Classes Chris Angelico <rosuav@gmail.com> - 2014-10-31 20:21 +1100
      Re: Classes   Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-31 10:05 -0400
        Re: Classes Ian Kelly <ian.g.kelly@gmail.com> - 2014-10-31 08:47 -0600
          Re: Classes Grant Edwards <invalid@invalid.invalid> - 2014-10-31 15:49 +0000
            Re: Classes Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-31 12:31 -0400
              Re: Classes Chris Angelico <rosuav@gmail.com> - 2014-11-01 03:37 +1100
                Re: Classes Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-31 12:47 -0400
                  Re: Classes Chris Angelico <rosuav@gmail.com> - 2014-11-01 04:02 +1100
                    Re: Classes Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-31 13:31 -0400
                      Re: Classes Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-10-31 12:39 -0500
                        Re: Classes Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-31 13:57 -0400
                      Re: Classes Rob Gaddi <rgaddi@technologyhighland.invalid> - 2014-10-31 10:40 -0700
                  Re: Classes Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-11-01 11:17 +1300
                    Re: Classes Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-01 12:06 +1100
                      Re: Classes Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-01 00:12 -0600
                      Re: Classes Chris Angelico <rosuav@gmail.com> - 2014-11-01 17:32 +1100
                      Re: Classes Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-11-03 00:32 +1300
              Re: Classes Dave Angel <davea@davea.name> - 2014-10-31 13:20 -0400
              Re: Classes Marko Rauhamaa <marko@pacujo.net> - 2014-10-31 19:35 +0200
              Re: Classes Grant Edwards <invalid@invalid.invalid> - 2014-10-31 17:40 +0000
              Re: Classes Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-10-31 18:26 -0400
                Re: Classes Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-01 12:09 +1100
        Re: Classes   Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-01 04:06 +1100
          Re: Classes   Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-31 13:18 -0400
            Re: Classes Rob Gaddi <rgaddi@technologyhighland.invalid> - 2014-10-31 10:43 -0700
              Re: Classes Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-31 14:18 -0400
                Re: Classes Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-31 14:42 -0400
                Re: Classes Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-10-31 18:57 -0400
                  Re: Classes Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-31 19:22 -0400
                    Re: Classes Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-31 19:32 -0400
                      Re: Classes Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-11-01 12:00 -0400
                        Re: Classes Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-11-01 12:42 -0400
                          Re: Classes Denis McMahon <denismfmcmahon@gmail.com> - 2014-11-02 09:50 +0000
                            Re: Classes Tim Delaney <timothy.c.delaney@gmail.com> - 2014-11-02 21:32 +1100
                              Re: Classes Denis McMahon <denismfmcmahon@gmail.com> - 2014-11-02 12:27 +0000
                                Re: Classes Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-11-02 11:31 -0500
                                  Re: Classes Denis McMahon <denismfmcmahon@gmail.com> - 2014-11-03 03:12 +0000
                                    Re: Classes Dan Sommers <dan@tombstonezero.net> - 2014-11-03 06:29 +0000
                                      Re: Classes Denis McMahon <denismfmcmahon@gmail.com> - 2014-11-04 01:10 +0000
                                        Re: Classes Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-11-04 18:30 +1300
                                    Re: Classes Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-11-03 08:50 -0500
                                    Re: Classes Chris Angelico <rosuav@gmail.com> - 2014-11-04 02:34 +1100
                                Re: Classes Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-03 07:47 -0700
                            Re: Classes Larry Hudson <orgnut@yahoo.com> - 2014-11-02 14:03 -0800
              Re: Classes Chris Angelico <rosuav@gmail.com> - 2014-11-01 07:51 +1100
                Re: Classes sohcahtoa82@gmail.com - 2014-10-31 14:24 -0700
                  Re: Classes Rob Gaddi <rgaddi@technologyhighland.invalid> - 2014-10-31 14:40 -0700
                    Re: Classes Chris Angelico <rosuav@gmail.com> - 2014-11-01 08:56 +1100
                  Re: Classes Chris Angelico <rosuav@gmail.com> - 2014-11-01 08:36 +1100
            Re: Classes Grant Edwards <invalid@invalid.invalid> - 2014-10-31 17:43 +0000
      Re: Classes Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-10-31 14:11 +0000
      Re: Classes   Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-31 12:49 -0400
        Re: Classes   "ast" <nomail@invalid.com> - 2014-10-31 19:31 +0100
          Re: Classes   Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-31 14:36 -0400
          Re: Classes Joel Goldstick <joel.goldstick@gmail.com> - 2014-10-31 14:41 -0400
            Re: Classes Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-31 14:56 -0400

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#80066

On Fri, 31 Oct 2014 18:57:31 -0400, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:

>On Fri, 31 Oct 2014 14:18:44 -0400, Seymore4Head
><Seymore4Head@Hotmail.invalid> declaimed the following:
>
>>On Fri, 31 Oct 2014 10:43:19 -0700, Rob Gaddi
>><rgaddi@technologyhighland.invalid> wrote:
>>
>>
>>>Define a Square class, subclassed from Rectangle.  Use getters/setters
>>>to enforce that the length and width must be equal.  Confirm that
>>>length and width remain locked, and that perimeter() and area() work
>>>correctly.
>>
>>class Rectangle:
>>    def __init__(self,length,width):
>>        self.length=length
>>        self.width=width
>>    def area(self):
>>        return self.length*self.width
>>    def perimeter(self):
>>        return 2*self.length+2*self.width
>>class Square(Rectangle):
>>    def set_side (self):
>>        if self.length!=self.width:
>>           
>	Where's the rest of that -- not to mention you called it "set_side" but
>never pass a side into it for use.
> 
>-=-=-=-=-=-=-=-
>
>class Rectangle(object):
>    def __init__(self, length, width=None):
>        self.length = length
>        if width is None:
>            self.width = length
>        else:
>            self.width = width
>    def area(self):
>        return self.length * self.width
>    def perimeter(self):
>        return 2 * (self.length + self.width)
>
Thanks for posting that.  I had given up on trying it.  I follow the
changes you made up this point.  I will have to think some more to get
the rest of this.
The way you provided a catch for not having a width, I don't
understand the purpose of a Square subclass.  Couldn't side just be
length?
BTW I am willing to forget any mention of getter/setter.  We can just
pretend that never happened.

>class Square(Rectangle):
>    def __init__(self, side):
>        self.side = side
>    def _getLength(self):
>        return self.side
>    def _getWidth(self):
>        return self.side
>    def _setLength(self, vlu):
>        self.side = vlu
>    def _setWidth(self, vlu):
>        self.side = vlu
>    length = property(_getLength, _setLength)
>    width = property(_getWidth, _setWidth)
>
>aRect = Rectangle(2, 4)
>print aRect.length, aRect.width, aRect.area(), aRect.perimeter()
>aRect.length = 9
>print aRect.length, aRect.width, aRect.area(), aRect.perimeter()
>
>
>aSqr = Square(3)
>print aSqr.side, aSqr.length, aSqr.width, aSqr.area(), aSqr.perimeter()
>aSqr.length = 4
>print aSqr.side, aSqr.length, aSqr.width, aSqr.area(), aSqr.perimeter()
>aSqr.width = 5
>print aSqr.side, aSqr.length, aSqr.width, aSqr.area(), aSqr.perimeter()
>aSqr.side = 7
>print aSqr.side, aSqr.length, aSqr.width, aSqr.area(), aSqr.perimeter()
>
>-=-=-=-=-=-=-=-=-
>Microsoft Windows [Version 6.1.7601]
>Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
>
>C:\Users\Wulfraed\Documents>cd "Python Progs"
>
>C:\Users\Wulfraed\Documents\Python Progs>property2.py
>2 4 8 12
>9 4 36 26
>3 3 3 9 12
>4 4 4 16 16
>5 5 5 25 20
>7 7 7 49 28
>
>C:\Users\Wulfraed\Documents\Python Progs>

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

#80067

On Fri, 31 Oct 2014 19:22:13 -0400, Seymore4Head
<Seymore4Head@Hotmail.invalid> wrote:

>On Fri, 31 Oct 2014 18:57:31 -0400, Dennis Lee Bieber
><wlfraed@ix.netcom.com> wrote:
>
>>On Fri, 31 Oct 2014 14:18:44 -0400, Seymore4Head
>><Seymore4Head@Hotmail.invalid> declaimed the following:
>>
>>>On Fri, 31 Oct 2014 10:43:19 -0700, Rob Gaddi
>>><rgaddi@technologyhighland.invalid> wrote:
>>>
>>>
>>>>Define a Square class, subclassed from Rectangle.  Use getters/setters
>>>>to enforce that the length and width must be equal.  Confirm that
>>>>length and width remain locked, and that perimeter() and area() work
>>>>correctly.
>>>
>>>class Rectangle:
>>>    def __init__(self,length,width):
>>>        self.length=length
>>>        self.width=width
>>>    def area(self):
>>>        return self.length*self.width
>>>    def perimeter(self):
>>>        return 2*self.length+2*self.width
>>>class Square(Rectangle):
>>>    def set_side (self):
>>>        if self.length!=self.width:
>>>           
>>	Where's the rest of that -- not to mention you called it "set_side" but
>>never pass a side into it for use.
>> 
>>-=-=-=-=-=-=-=-
>>
>>class Rectangle(object):
>>    def __init__(self, length, width=None):
>>        self.length = length
>>        if width is None:
>>            self.width = length
>>        else:
>>            self.width = width
>>    def area(self):
>>        return self.length * self.width
>>    def perimeter(self):
>>        return 2 * (self.length + self.width)
>>
>Thanks for posting that.  I had given up on trying it.  I follow the
>changes you made up this point.  I will have to think some more to get
>the rest of this.
>The way you provided a catch for not having a width, I don't
>understand the purpose of a Square subclass.  Couldn't side just be
>length?
>BTW I am willing to forget any mention of getter/setter.  We can just
>pretend that never happened.
>
I took your instruction and change it to this:
That answers my own question.
Thanks again

class Rectangle(object):
    def __init__(self, length, width=None):
        self.length = length
        if width is None:
            self.width = length
        else:
            self.width = width
    def area(self):
        return self.length * self.width
    def perimeter(self):
        return 2 * (self.length + self.width)

class Square(Rectangle):
    def area(self):
        return self.length * self.width
    def perimeter(self):
        return 2 * (self.length + self.width)    
    
a=Rectangle(3,5)
print (a.area())
print (a.perimeter())
b=Rectangle(5,7)
print (b.area())
print (b.perimeter())
c=Square(4)
print (c.area())
print (c.perimeter())

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

#80093

On Fri, 31 Oct 2014 19:32:13 -0400, Seymore4Head
<Seymore4Head@Hotmail.invalid> declaimed the following:

>
>class Rectangle(object):
>    def __init__(self, length, width=None):
>        self.length = length
>        if width is None:
>            self.width = length
>        else:
>            self.width = width
>    def area(self):
>        return self.length * self.width
>    def perimeter(self):
>        return 2 * (self.length + self.width)
>
>class Square(Rectangle):
>    def area(self):
>        return self.length * self.width
>    def perimeter(self):
>        return 2 * (self.length + self.width)    
>
	Why did you redefine area and perimeter? Those are supposed to be
inherited operations from Rectangle. You've duplicated what should not have
been changed, and removed everything that makes a Square a Square.

	The "assignment" was to create a Square class that enforces the
property of "squareness" (length = width, or a simple "side").

	What you created does not do that.
    
>a=Rectangle(3,5)
>print (a.area())
>print (a.perimeter())
>b=Rectangle(5,7)
>print (b.area())
>print (b.perimeter())
>c=Square(4)
>print (c.area())
>print (c.perimeter())

	You're tests ignore the case of /changing/ side/length/width...
Consider what happens if you execute

c.length = 5
c.width = 9

	Your "square" is now a rectangle... My example forces every change to a
"Square" to affect both dimensions equally -- no matter if you set .side,
.length, .width, the square will still be a square.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#80095

On Sat, 01 Nov 2014 12:00:46 -0400, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:

>On Fri, 31 Oct 2014 19:32:13 -0400, Seymore4Head
><Seymore4Head@Hotmail.invalid> declaimed the following:
>
>>
>>class Rectangle(object):
>>    def __init__(self, length, width=None):
>>        self.length = length
>>        if width is None:
>>            self.width = length
>>        else:
>>            self.width = width
>>    def area(self):
>>        return self.length * self.width
>>    def perimeter(self):
>>        return 2 * (self.length + self.width)
>>
>>class Square(Rectangle):
>>    def area(self):
>>        return self.length * self.width
>>    def perimeter(self):
>>        return 2 * (self.length + self.width)    
>>
>	Why did you redefine area and perimeter? Those are supposed to be
>inherited operations from Rectangle. You've duplicated what should not have
>been changed, and removed everything that makes a Square a Square.
>
>	The "assignment" was to create a Square class that enforces the
>property of "squareness" (length = width, or a simple "side").
>
>	What you created does not do that.
>    
>>a=Rectangle(3,5)
>>print (a.area())
>>print (a.perimeter())
>>b=Rectangle(5,7)
>>print (b.area())
>>print (b.perimeter())
>>c=Square(4)
>>print (c.area())
>>print (c.perimeter())
>
>	You're tests ignore the case of /changing/ side/length/width...
>Consider what happens if you execute
>
>c.length = 5
>c.width = 9
>
OK  Maybe I misunderstood the question.

My answer to you then is ......I don't know.  I will have to think
about it some more.

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

#80114

On Sat, 01 Nov 2014 12:42:10 -0400, Seymore4Head wrote:

> OK  Maybe I misunderstood the question.
> 
> My answer to you then is ......I don't know.  I will have to think about
> it some more.

The question (I thought) was to write a class for Square that inherited a 
class Rectangle but imposed on it the additional constraints of a square 
over a rectangle, namely that length == width.

To do this, you need to override the inherited methods to set length and 
width with new methods to set length and width as follows:

when setting length, also set width equal to length.
when setting width, also set length equal to width.

For bonus points, if your constructor accepts width and length parameters 
(from the Rectangle constructor) then detect if they are different and 
raise a suitable error.

from math import sqrt

class SquareGeometryError(Exception):
    """The parameters create an illegal geometry for a square"""
    pass

class Rectangle:

    def __init__(self,length,width):
        self.length=length 
        self.width=width

    def area(self):
        return self.length*self.width

    def perimeter(self):
        return 2*self.length+2*self.width

    def diagonal(self):
        return sqrt(self.length*self.length+self.width*self.width)

    def get_width(self):
        return self.width

    def get_length(self):
        return self.length

    def set_width(self, width):
        self.width = width

    def set_length(self, length):
        self.length = length

class Square(Rectangle):

    _def _init__(self, length, width):
        if not length == width:
            raise SquareGeometryError("Length must equal width")
        self.length = length # or width
        self.width = length # or width

    def set_width(self, width):
        self.length = width
        self.width = width

    def set_length(self, length):
        self.length = length
        self.width = length

Note that to make my square, I only need to over-ride those rectangle 
methods which allow the setting of length and width to enforce squareness 
upon the square. All the other methods of rectangle will work equally 
well for the square.

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#80115

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

On 2 November 2014 20:50, Denis McMahon <denismfmcmahon@gmail.com> wrote:

>
> The question (I thought) was to write a class for Square that inherited a
> class Rectangle but imposed on it the additional constraints of a square
> over a rectangle, namely that length == width.
>

I'm late to the party and this has already been partially addressed in the
thread, but it always annoys me. A square is as much a rhombus with 90
degree angles as it is a rectangle with equal length and width, and yet I
*never* see the former given as an option.

If course, that's probably because rectangles have a multitude of uses for
user interfaces, whilst other quadrilaterals are somewhat less useful.

Tim Delaney

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

#80117

On Sun, 02 Nov 2014 21:32:13 +1100, Tim Delaney wrote:

> On 2 November 2014 20:50, Denis McMahon <denismfmcmahon@gmail.com>
> wrote:
> 
>> The question (I thought) was to write a class for Square that inherited
>> a class Rectangle but imposed on it the additional constraints of a
>> square over a rectangle, namely that length == width.
>>
>>
> I'm late to the party and this has already been partially addressed in
> the thread, but it always annoys me. A square is as much a rhombus with
> 90 degree angles as it is a rectangle with equal length and width, and
> yet I *never* see the former given as an option.
> 
> If course, that's probably because rectangles have a multitude of uses
> for user interfaces, whilst other quadrilaterals are somewhat less
> useful.

And perhaps that also addresses the square - rectangle (or circle - 
ellipse) issue - square, rectangle and rhombus are all forms of 
quadrilateral, and perhaps should all inherit a base class Quadrilateral, 
rather than trying (and partially failing) to inherit each other.

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#80125

On Sun, 2 Nov 2014 12:27:06 +0000 (UTC), Denis McMahon
<denismfmcmahon@gmail.com> declaimed the following:

>On Sun, 02 Nov 2014 21:32:13 +1100, Tim Delaney wrote:
>
>> On 2 November 2014 20:50, Denis McMahon <denismfmcmahon@gmail.com>
>> wrote:
>> 
>>> The question (I thought) was to write a class for Square that inherited
>>> a class Rectangle but imposed on it the additional constraints of a
>>> square over a rectangle, namely that length == width.
>>>
>>>
>> I'm late to the party and this has already been partially addressed in
>> the thread, but it always annoys me. A square is as much a rhombus with
>> 90 degree angles as it is a rectangle with equal length and width, and
>> yet I *never* see the former given as an option.
>> 
>> If course, that's probably because rectangles have a multitude of uses
>> for user interfaces, whilst other quadrilaterals are somewhat less
>> useful.
>
>And perhaps that also addresses the square - rectangle (or circle - 
>ellipse) issue - square, rectangle and rhombus are all forms of 
>quadrilateral, and perhaps should all inherit a base class Quadrilateral, 
>rather than trying (and partially failing) to inherit each other.

	I'd class them as parallelograms -- as they differ from a trapezoid in
that opposite faces are parallel... Not to mention "arrow heads" where two
adjacent sides actually bend inwards.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#80148

On Sun, 02 Nov 2014 11:31:12 -0500, Dennis Lee Bieber wrote:

> On Sun, 2 Nov 2014 12:27:06 +0000 (UTC), Denis McMahon
> <denismfmcmahon@gmail.com> declaimed the following:
> 
>>On Sun, 02 Nov 2014 21:32:13 +1100, Tim Delaney wrote:

>>> If course, that's probably because rectangles have a multitude of uses
>>> for user interfaces, whilst other quadrilaterals are somewhat less
>>> useful.
>>
>>And perhaps that also addresses the square - rectangle (or circle -
>>ellipse) issue - square, rectangle and rhombus are all forms of
>>quadrilateral, and perhaps should all inherit a base class
>>Quadrilateral,
>>rather than trying (and partially failing) to inherit each other.
> 
> 	I'd class them as parallelograms -- as they differ from a 
trapezoid in
> that opposite faces are parallel... Not to mention "arrow heads" where
> two adjacent sides actually bend inwards.

So:

Quadrilateral
    Parallelogram
        Square
        Rectangle
        Rhombus
        Diamond (4 sides eq)
    Trapezoid
        Arrowhead

Is an arrowhead a trapezoid?

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#80149

On Mon, 03 Nov 2014 03:12:32 +0000, Denis McMahon wrote:

> Quadrilateral
>     Parallelogram
>         Square
>         Rectangle
>         Rhombus
>         Diamond (4 sides eq)
>     Trapezoid
>         Arrowhead

What's the difference between a Diamond and a Rhombus?

> Is an arrowhead a trapezoid?

No.

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

#80167

On Mon, 03 Nov 2014 06:29:39 +0000, Dan Sommers wrote:

> On Mon, 03 Nov 2014 03:12:32 +0000, Denis McMahon wrote:
> 
>> Quadrilateral
>>     Parallelogram
>>         Square Rectangle Rhombus Diamond (4 sides eq)
>>     Trapezoid
>>         Arrowhead
> 
> What's the difference between a Diamond and a Rhombus?

Oops, I was thinking a rhombus was a general parallelogram, my mistake.

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#80168

Denis McMahon wrote:
> On Mon, 03 Nov 2014 06:29:39 +0000, Dan Sommers wrote:
> 

>>What's the difference between a Diamond and a Rhombus?
> 
> Oops, I was thinking a rhombus was a general parallelogram, my mistake.

Some diamonds are neither rhombuses nor parallelograms:

http://minecraft.gamepedia.com/Diamond

More a sort of irregular hexagon...

-- 
Greg

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

#80153

On Mon, 3 Nov 2014 03:12:32 +0000 (UTC), Denis McMahon
<denismfmcmahon@gmail.com> declaimed the following:

>So:
>
>Quadrilateral
>    Parallelogram
>        Square
>        Rectangle
>        Rhombus
>        Diamond (4 sides eq)
>    Trapezoid
>        Arrowhead
>
>Is an arrowhead a trapezoid?

	I'd probably indent square under rectangle, and indent diamond where it
is -- both being restrictions on rectangle/rhombus

	But we may need another category, convex and concave; the arrowhead
would fall into the concave grouping.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#80159

On Tue, Nov 4, 2014 at 12:50 AM, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:
> On Mon, 3 Nov 2014 03:12:32 +0000 (UTC), Denis McMahon
> <denismfmcmahon@gmail.com> declaimed the following:
>
>>So:
>>
>>Quadrilateral
>>    Parallelogram
>>        Square
>>        Rectangle
>>        Rhombus
>>        Diamond (4 sides eq)
>>    Trapezoid
>>        Arrowhead
>>
>>Is an arrowhead a trapezoid?
>
>         I'd probably indent square under rectangle, and indent diamond where it
> is -- both being restrictions on rectangle/rhombus
>
>         But we may need another category, convex and concave; the arrowhead
> would fall into the concave grouping.

That's fine if you're creating a taxonomical hierarchy of immutables,
but neither works if you're creating a mutable class hierarchy that
follows LSP. The only way you can make any of this work (as someone
suggested earlier, I believe) is by having __new__ potentially return
a subclass, so if you ask Parallelogram to give you one with all sides
equal and all angles equal, it gives you back a Square. But since a
square is a special form of rhombus as well as a special form of
rectangle, you'd have to use multiple inheritance or an AST-style
subclass hook to verify. Of course, if you're going down that route,
you probably want to take this up a level and have a Shape class, and
have the subclass hook simply check if it's four-sided as well.

ChrisA

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

#80157

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

On Nov 2, 2014 5:31 AM, "Denis McMahon" <denismfmcmahon@gmail.com> wrote:
> And perhaps that also addresses the square - rectangle (or circle -
> ellipse) issue - square, rectangle and rhombus are all forms of
> quadrilateral, and perhaps should all inherit a base class Quadrilateral,
> rather than trying (and partially failing) to inherit each other.

No, it doesn't matter whether you have square inheriting from rectangle,
rhombus or quadrilateral. If the base class has mutator methods, you're
still going to have this problem when they allow the object to be mutated
in ways that violate the restrictions of the subclass.

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

#80141

On 11/02/2014 01:50 AM, Denis McMahon wrote:
[snip]
> from math import sqrt
>
> class SquareGeometryError(Exception):
>      """The parameters create an illegal geometry for a square"""
>      pass
>
> class Rectangle:
>
>      def __init__(self,length,width):
>          self.length=length
>          self.width=width
>
>      def area(self):
>          return self.length*self.width
>
>      def perimeter(self):
>          return 2*self.length+2*self.width
>
>      def diagonal(self):
>          return sqrt(self.length*self.length+self.width*self.width)
>
>      def get_width(self):
>          return self.width
>
>      def get_length(self):
>          return self.length
>
>      def set_width(self, width):
>          self.width = width
>
>      def set_length(self, length):
>          self.length = length
>
> class Square(Rectangle):
>
>      _def _init__(self, length, width):
>          if not length == width:
>              raise SquareGeometryError("Length must equal width")
>          self.length = length # or width
>          self.width = length # or width
>
>      def set_width(self, width):
>          self.length = width
>          self.width = width
>
>      def set_length(self, length):
>          self.length = length
>          self.width = length
>
> Note that to make my square, I only need to over-ride those rectangle
> methods which allow the setting of length and width to enforce squareness
> upon the square. All the other methods of rectangle will work equally
> well for the square.
>

Why do you want to instantiate a Square with two parameters?  You only need one -- side.  I 
agree that since you are inheriting from Rectangle you need to keep the length and width 
attributes to allow the get/set of length/width, so you do need to override the Rectangle set 
methods.  Consider this version:

#   ------ <code> ---------
class Square(Rectangle):
     def __init__(self, side):
         self.set_side(side)

     def get_side(self):
         return self.length     #  or width

     def set_side(self, side):
	self.length = self.width = side

     def set_width(self, width):
	self.set_side(width)

     def set_length(self, length):
	self.set_side(length)
#   ------ </code> --------

This also eliminates the need for your exception.  Of course, it still allows someone to 
directly change either the length or width -- but since "we are all consenting adults here", 
anyone who does this should know the consequences.   ;-)

      -=- Larry -=-

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

#80057

On Sat, Nov 1, 2014 at 4:43 AM, Rob Gaddi
<rgaddi@technologyhighland.invalid> wrote:
> Define a Square class, subclassed from Rectangle.  Use getters/setters
> to enforce that the length and width must be equal.  Confirm that
> length and width remain locked, and that perimeter() and area() work
> correctly.

Here we go again...

http://en.wikipedia.org/wiki/Circle-ellipse_problem

Square and Rectangle are just as "obviously" the other way around in
the hierarchy, and it's wrong whichever way you do it. Not a good
example.

ChrisA

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

#80058

On Friday, October 31, 2014 1:51:23 PM UTC-7, Chris Angelico wrote:
> On Sat, Nov 1, 2014 at 4:43 AM, Rob Gaddi
> <rgaddi@technologyhighland.invalid> wrote:
> > Define a Square class, subclassed from Rectangle.  Use getters/setters
> > to enforce that the length and width must be equal.  Confirm that
> > length and width remain locked, and that perimeter() and area() work
> > correctly.
> 
> Here we go again...
> 
> http://en.wikipedia.org/wiki/Circle-ellipse_problem
> 
> Square and Rectangle are just as "obviously" the other way around in
> the hierarchy, and it's wrong whichever way you do it. Not a good
> example.
> 
> ChrisA

I've never heard of the Circle-Ellipse problem, and my first instinct to Rob's post was to ask, why would you want to sub-class Rectangle into a Square class?  A square is just a special case of a Rectangle.  Attempting that kind of sub-classing would just cause problems.  The only thing you gain is a slight optimization in calculating perimeter by turning two multiplications and an addition into a single multiplication which really wouldn't have an effect on performance unless you were doing that calculation millions of times per second.

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

#80060

On Fri, 31 Oct 2014 14:24:11 -0700 (PDT)
sohcahtoa82@gmail.com wrote:

> On Friday, October 31, 2014 1:51:23 PM UTC-7, Chris Angelico wrote:
> > On Sat, Nov 1, 2014 at 4:43 AM, Rob Gaddi
> > <rgaddi@technologyhighland.invalid> wrote:
> > > Define a Square class, subclassed from Rectangle.  Use getters/setters
> > > to enforce that the length and width must be equal.  Confirm that
> > > length and width remain locked, and that perimeter() and area() work
> > > correctly.
> > 
> > Here we go again...
> > 
> > http://en.wikipedia.org/wiki/Circle-ellipse_problem
> > 
> > Square and Rectangle are just as "obviously" the other way around in
> > the hierarchy, and it's wrong whichever way you do it. Not a good
> > example.
> > 
> > ChrisA
> 
> I've never heard of the Circle-Ellipse problem, and my first instinct to Rob's post was to ask, why would you want to sub-class Rectangle into a Square class?  A square is just a special case of a Rectangle.  Attempting that kind of sub-classing would just cause problems.  The only thing you gain is a slight optimization in calculating perimeter by turning two multiplications and an addition into a single multiplication which really wouldn't have an effect on performance unless you were doing that calculation millions of times per second.

As a practical tool?  Entirely and completely useless, no doubt
about it.  But it's easily understood as an example, even if the reason
that a Square is a subclass of Rectangle is "because I said so".

For this specific exercise, a Square is a subclass of Rectangle because
the point of Rectangle is to demonstrate that extraneous get/set
functions are completely unnecessary in Python.  The point of
Square is to demonstrate that get/set functions can be useful in
certain circumstances where you need to implement non-trivial behaviors,
such as making the "width" property into an alias for the "length" true
data member.

As a learning tool for thinking about inheritance hierarchies it's kind
of rubbish.  But then again, most inheritance hierarchies are ambigious
at best, which is why "has a" is often a better choice than "is a".

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

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

#80062

On Sat, Nov 1, 2014 at 8:40 AM, Rob Gaddi
<rgaddi@technologyhighland.invalid> wrote:
> For this specific exercise, a Square is a subclass of Rectangle because
> the point of Rectangle is to demonstrate that extraneous get/set
> functions are completely unnecessary in Python.  The point of
> Square is to demonstrate that get/set functions can be useful in
> certain circumstances where you need to implement non-trivial behaviors,
> such as making the "width" property into an alias for the "length" true
> data member.

As the Wikipedia article explains, this has its own consequences. A
reasonable test suite for Rectangle would quite probably fail if given
a Square. Hence my belief that this makes for a less-than-ideal
example. But I can't think of *any* good example of @property for a
tutorial. ANY.

> As a learning tool for thinking about inheritance hierarchies it's kind
> of rubbish.  But then again, most inheritance hierarchies are ambigious
> at best, which is why "has a" is often a better choice than "is a".

Agreed. There certainly are times when "is a" is the right choice, but
there are a lot more times when "has a" is the better choice. Usually,
when I subclass, it's because I want to tweak the behaviour of an
existing type (for instance, subclass int and change its repr() to
return hex(self)), so it really truly is a <superclass>, in every way
except that one tiny change. Otherwise, new type with a member. Much
simpler. Much safer.

ChrisA

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web