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 "
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
>
>
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
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
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
>
>
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 =
36 matches
Mail list logo
