Re: Extending classes __init__behavior for newbies

On Tue, 2011-02-15 at 14:16 -0800, rantingrick wrote: > On Feb 14, 9:44 pm, Steven D'Aprano +comp.lang.pyt...@pearwood.info> wrote: > > On Tue, 15 Feb 2011 09:47:54 +1000, James Mills wrote: > > > On Tue, Feb 15, 2011 at 9:32 AM, rantingrick > > > wrote: > > >> Those who write code bases should "

Re: Extending classes __init__behavior for newbies

On Feb 15, 4:16 pm, rantingrick wrote: > # In Code form. > if (dev.design_time + dev.test_time) < dev.write_time: >     print('Good Job Skippy!') > else: >     raise ScriptKiddieError Oops, you see what i mean!!! :-) if (dev.design_time + dev.test_time) > dev.write_time:     print('Good Job Sk

Re: Extending classes __init__behavior for newbies

On Feb 14, 9:44 pm, Steven D'Aprano wrote: > On Tue, 15 Feb 2011 09:47:54 +1000, James Mills wrote: > > On Tue, Feb 15, 2011 at 9:32 AM, rantingrick > > wrote: > >> Those who write code bases should "design-in" practicality, re- > >> usability, and extendability as a forethought and NOT an aftert

Re: Extending classes __init__behavior for newbies

On Tue, Feb 15, 2011 at 1:44 PM, Steven D'Aprano wrote: > I don't. If you (generic you) have separate "write the code" and "test > the code" phases, your project is in trouble. You can probably get away > with it if it's a tiny throw-away script, but for anything more > substantial, you should be

Re: Extending classes __init__behavior for newbies

On Tue, 2011-02-15 at 08:36 +, Duncan Booth wrote: > Westley Martínez wrote: > > >> In the end i promise they will respect you more for your honesty. And > >> it will not be a respect forged from fear, no, it will be something > >> greater! A respect forged from collaboration. A respect of co

Re: Extending classes __init__behavior for newbies

Westley Martínez wrote: >> In the end i promise they will respect you more for your honesty. And >> it will not be a respect forged from fear, no, it will be something >> greater! A respect forged from collaboration. A respect of comrades in >> arms. This is the future i bring to c.l.py! > HEIL D

Re: Extending classes __init__behavior for newbies

On Tue, 15 Feb 2011 09:47:54 +1000, James Mills wrote: > On Tue, Feb 15, 2011 at 9:32 AM, rantingrick > wrote: >> Those who write code bases should "design-in" practicality, re- >> usability, and extendability as a forethought and NOT an afterthought. >> Of course i am not suggesting that everyon

Re: Extending classes __init__behavior for newbies

rantingrick wrote: > A respect forged from collaboration. A respect of comrades in > arms. This is the future i bring to c.l.py! Really? I see no collaboration, respect nor camaraderie in anything you've posted to date. So I'm confident the future you bring will be pretty much the same as the pas

Re: Extending classes __init__behavior for newbies

On Mon, 2011-02-14 at 16:53 -0800, rantingrick wrote: > On Feb 14, 6:06 pm, alex23 wrote: > > On Feb 15, 9:47 am, James Mills wrote: > > > > > On Tue, Feb 15, 2011 at 9:32 AM, rantingrick > > > wrote: > ... > [snip: eloquent speech!] > ... > > > I actually agree with this. :) > > The problem is

Re: Extending classes __init__behavior for newbies

On Feb 14, 6:06 pm, alex23 wrote: > On Feb 15, 9:47 am, James Mills wrote: > > > On Tue, Feb 15, 2011 at 9:32 AM, rantingrick wrote: ... [snip: eloquent speech!] ... > > I actually agree with this. :) > The problem is that it's not a philosophy which the ranting one > practices, Actually I coul

Re: Extending classes __init__behavior for newbies

On Feb 15, 9:47 am, James Mills wrote: > On Tue, Feb 15, 2011 at 9:32 AM, rantingrick wrote: > > Those who write code bases should "design-in" practicality, re- > > usability, and extendability as a forethought and NOT an afterthought. > > Of course i am not suggesting that everyone must be clair

Re: Extending classes __init__behavior for newbies

On Tue, Feb 15, 2011 at 9:32 AM, rantingrick wrote: > Those who write code bases should "design-in" practicality, re- > usability, and extendability as a forethought and NOT an afterthought. > Of course i am not suggesting that everyone must be clairvoyant. > However the vast amount of time involv

Re: Extending classes __init__behavior for newbies

On Tue, Feb 15, 2011 at 9:32 AM, rantingrick wrote: > In any event, normally i would expect people to use a bit of common > sense when wielding an interface ESPECIALLY when they wrote it! Like > for instance... If i gave someone a loaded gun i would not bother > telling that person "Hey, don't aim

Re: Extending classes __init__behavior for newbies

On Feb 14, 1:45 pm, Michael Sparks wrote: > I hardly call 87 lines of code "miles of code" though myself.  I call > it a relatively trivial example aimed at showing the benefit of using > super() in your code rather than hard coding brittle fragility into > your code. You accuse my coding habits

Re: Extending classes __init__behavior for newbies

On Mon, 2011-02-14 at 11:15 -0800, rantingrick wrote: > On Feb 14, 11:55 am, Michael Sparks wrote: > > It can be broken if someone tries to use the class as is - that is > > treating the class as a model - to drive a display of the ship. If > > it was written using super() then that wouldn't be a

Re: Extending classes __init__behavior for newbies

On Feb 14, 7:15 pm, rantingrick wrote: > On Feb 14, 11:55 am, Michael Sparks wrote: > > > It can be broken if someone tries to use the class as is - that is > > treating the class as a model - to drive a display of the ship. If > > it was written using super() then that wouldn't be a problem. > >

Re: Extending classes __init__behavior for newbies

On Feb 14, 11:55 am, Michael Sparks wrote: > It can be broken if someone tries to use the class as is - that is > treating the class as a model - to drive a display of the ship. If > it was written using super() then that wouldn't be a problem. > > For example, I could write a display mixin that I

Re: Extending classes __init__behavior for newbies

It can be broken if someone tries to use the class as is - that is treating the class as a model - to drive a display of the ship. If it was written using super() then that wouldn't be a problem. For example, I could write a display mixin that I'd like to use like this: class VisibleShip(ship, sp

Re: Extending classes __init__behavior for newbies

On Sun, Feb 13, 2011 at 9:39 PM, Christian Heimes wrote: > If you have a short memory then you should definitely use one way -- the > correct way for all cases -- to call the parent's class init method. > Otherwise your future self is going to hate your current self for > introducing potential bug

Re: Extending classes __init__behavior for newbies

> > > Where is the buggy code? Show me how Ship.__init__() can break. Anyone > can argue, few can offer facts. If you bring an argument that > Ship.__init__() can break if someone changes the code then that IS NOT > an valid argument. ANY code can be broken with the addition or > subtraction of a s

Re: Extending classes __init__behavior for newbies

On Feb 13, 10:39 pm, Christian Heimes wrote: > Am 14.02.2011 00:12, schrieb rantingrick: > > > False! There IS harm in using super when super not needed. The > > difference is readability! And don't downplay that aspect. You > > yourself have said this in the past. It seems *some* of us have very

Re: Extending classes __init__behavior for newbies

Am 14.02.2011 00:12, schrieb rantingrick: > False! There IS harm in using super when super not needed. The > difference is readability! And don't downplay that aspect. You > yourself have said this in the past. It seems *some* of us have very > short memories. Of course you are entitled to have yo

Re: Extending classes __init__behavior for newbies

Ben Finney writes: > However, using ‘__super__’ properly is very problematic. By which I meant the ‘super’ built-in. Sorry for any resulting confusion. -- \ “Pinky, are you pondering what I'm pondering?” “Uh, I think so, | `\ Brain, but balancing a family and a career ... ooh, it's

Re: Extending classes __init__behavior for newbies

On Feb 13, 5:11 pm, James Mills wrote: > On Mon, Feb 14, 2011 at 8:39 AM, rantingrick wrote: > > Did everyone miss the fact that this inheritance is unnecessary? > > Considering the Ship class has an attribute "speed" that will be > > affected (either directly or indirectly) by simply modifying i

Re: Extending classes __init__behavior for newbies

James Mills writes: > On Mon, Feb 14, 2011 at 8:21 AM, MRAB wrote: > > I would've done it this way: > > > > class FasterShip(Ship): > >    def __init__(self, speed=0, **kwargs): > >        Ship.__init__(self, **kwargs) > >        self.speed = speed > > What's the difference between calling the b

Re: Extending classes __init__behavior for newbies

On Feb 13, 5:01 pm, Steven D'Aprano wrote: > On Mon, 14 Feb 2011 08:27:10 +1000, James Mills wrote: > > What's the difference between calling the base class's constructor > > directly and using the super type ? > > If you have *only* single inheritance, then there is no practical > difference and

Re: Extending classes __init__behavior for newbies

On Mon, Feb 14, 2011 at 8:39 AM, rantingrick wrote: > Did everyone miss the fact that this inheritance is unnecessary? > Considering the Ship class has an attribute "speed" that will be > affected (either directly or indirectly) by simply modifying it? The attribute "speed" was not a member of th

Re: Extending classes __init__behavior for newbies

On Mon, 14 Feb 2011 08:27:10 +1000, James Mills wrote: > On Mon, Feb 14, 2011 at 8:21 AM, MRAB > wrote: >> I would've done it this way: >> >> class FasterShip(Ship): >>    def __init__(self, speed=0, **kwargs): >>        Ship.__init__(self, **kwargs) >>        self.speed = speed > > What's the d

Re: Extending classes __init__behavior for newbies

On Feb 13, 2011 5:37 PM, "James Mills" wrote: > > On Mon, Feb 14, 2011 at 8:21 AM, MRAB wrote: > > I would've done it this way: > > > > class FasterShip(Ship): > >def __init__(self, speed=0, **kwargs): > >Ship.__init__(self, **kwargs) > >self.speed = speed > > What's the diffe

Re: Extending classes __init__behavior for newbies

On Feb 13, 4:00 pm, James Mills wrote: > class FasterShip(Ship): > >     def __init__(self, l=0,b=0,t=0,name='', speed=0): >         super(FasterShip, self).__init__(l, b, t, name) > >         self.speed = speed Did everyone miss the fact that this inheritance is unnecessary? Considering the Shi

Re: Extending classes __init__behavior for newbies

On Feb 13, 4:27 pm, James Mills wrote: > > class FasterShip(Ship): > >    def __init__(self, speed=0, **kwargs): > >        Ship.__init__(self, **kwargs) > >        self.speed = speed > > What's the difference between calling the base > class's constructor directly and using the super type ? wel

Re: Extending classes __init__behavior for newbies

On Feb 13, 4:21 pm, MRAB wrote: > I would've done it this way: > > class FasterShip(Ship): >      def __init__(self, speed=0, **kwargs): >          Ship.__init__(self, **kwargs) >          self.speed = speed Well it seem MRAB and i actually agree on *one* thing. Well, when they said... "great mi

Re: Extending classes __init__behavior for newbies

On Feb 13, 4:00 pm, James Mills wrote: [snip] > When you subclass a base class (ship in your example) you need > to call it's parent (or super) methods. This includes the constructor > (__init__). > > The standard way of doing this in Python is: > > class FasterShip(Ship): > >     def __init__(s

Re: Extending classes __init__behavior for newbies

On Mon, Feb 14, 2011 at 8:21 AM, MRAB wrote: > I would've done it this way: > > class FasterShip(Ship): >    def __init__(self, speed=0, **kwargs): >        Ship.__init__(self, **kwargs) >        self.speed = speed What's the difference between calling the base class's constructor directly and us

Re: Extending classes __init__behavior for newbies

On 13/02/2011 22:00, James Mills wrote: On Mon, Feb 14, 2011 at 7:17 AM, Benjamin J. Racine wrote: I don't quite understand the interplay of the two different __init__ methods when trying to extend a class. Below is my hack attempt at doing so... class ship(object): def __init__(self,l=0

Re: Extending classes __init__behavior for newbies

On Mon, Feb 14, 2011 at 7:17 AM, Benjamin J. Racine wrote: > I don't quite understand the interplay of the two different __init__ methods > when trying to extend a class.  Below is my hack attempt at doing so... > class ship(object): >     def __init__(self,l=0,b=0,t=0,name=''): >       self.l =

Extending classes __init__behavior for newbies

I don't quite understand the interplay of the two different __init__ methods when trying to extend a class. Below is my hack attempt at doing so... class ship(object): def __init__(self,l=0,b=0,t=0,name=''): self.l = l self.b = b self.t = t self.name