Re: Extending classes __init__behavior for newbies

Discussion in 'Python' started by James Mills, Feb 13, 2011.

  1. James Mills

    James Mills Guest

    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 using the super type ?

    cheers
    James

    --
    -- James Mills
    --
    -- "Problems are solved by method"
    James Mills, Feb 13, 2011
    #1
    1. Advertising

  2. James Mills

    rantingrick Guest

    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 ?


    well for starters...

    * confusion and clarity
    * liberal and conservative
    * excess and moderation

    .... just to name a few.
    rantingrick, Feb 13, 2011
    #2
    1. Advertising

  3. 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 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 no harm in using super().

    If you have multiple inheritance, then you *must* use super(), otherwise
    your method will not correctly call all the superclasses that it needs to.



    --
    Steven
    Steven D'Aprano, Feb 13, 2011
    #3
  4. James Mills

    rantingrick Guest

    On Feb 13, 5:01 pm, Steven D'Aprano <steve
    > 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 no harm in using super().


    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.

    > If you have multiple inheritance, then you *must* use super(), otherwise
    > your method will not correctly call all the superclasses that it needs to..


    True! You must you super in this case or in any case where you DO NOT
    know the identifier of the base class. However the point is: NEVER USE
    SUPER UNLESS YOU ABSOLUTELY HAVE NO OTHER OPTION!
    rantingrick, Feb 13, 2011
    #4
  5. James Mills

    rantingrick Guest

    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
    > > short memories.

    >
    > Of course you are entitled to have your own opinion and own coding
    > style. You are also allowed to disregard the opinion of experienced
    > Python developers, who really know what they are talking about. But
    > please DO NOT teach new Python users wrong coding! I assume Benjamin
    > will follow the right lead here.


    And which "lead" is the correct lead to follow? And more importantly
    WHY? You failed to offer any substance to your comments. They left
    myself (and many others) wanting.

    > 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.


    Again WHAT IS the correct way? We've heard your opinion now let's hear
    some fact based arguments.

    > Otherwise your future self is going to hate your current self for
    > introducing potential buggy code.


    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 single char.
    rantingrick, Feb 14, 2011
    #5
  6. 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, sprite):
    ...

    and
    class FasterVisibleShip(faster_ship, sprite):
    ...


    But because neither ship nor faster_ship call their super class
    correctly,
    this won't work.

    To turn this into something concrete, consider the following code:

    class mixin(object):
    """
    The key benefit of this mixin is that it tracks instances created
    and
    also allows subclasses to have inheritable default values.
    """
    objects = []
    def __init__(self, **kwargs):
    super(mixin, self).__init__()
    self.__dict__.update(**kwargs)
    self.objects.append(self)

    Using that code, I can create my ship model as a mixin:

    class ship(mixin):
    x = 0
    y = 0
    step = 1
    angle = 0
    name = ""
    def update(self):
    self.x = self.x + math.cos(math.radians(self.angle)) *
    self.step
    self.y = self.y + math.sin(math.radians(self.angle)) *
    self.step

    As well as the faster ship:

    class fastership(ship):
    speed = 1
    def update(self):
    self.x = self.x + math.cos(math.radians(self.angle)) *
    self.step * self.speed
    self.y = self.y + math.sin(math.radians(self.angle)) *
    self.step * self.speed

    I can then create a sprite mixin:

    class sprite(mixin):
    x = 0
    y = 0
    image = "sprite.png"
    display = None
    def __init__(self, **kwargs):
    super(sprite, self).__init__(**kwargs)
    self._image = pygame.image.load(self.image)
    print "Image Loaded", self.__class__

    def render(self,surface):
    # assume surface is something like a pygame surface
    surface.blit(self._image, (self.x, self.y))

    And also for debug purposes a debug mixin:
    import time
    class debug(mixin):
    debug_file = "debug.log"
    debug_handle = None
    def __init__(self, **kwargs):
    print "Creation arguments", self.__class__, kwargs
    super(debug, self).__init__(**kwargs)

    @classmethod
    def dump_state(klass,self):
    if klass.debug_handle is None:
    klass.debug_handle = open(self.debug_file, "w")
    klass.debug_handle.write(str(time.time()) + ":" +
    str(klass) + ":" + str(self.__dict__)+"\n\n")
    klass.debug_handle.flush()

    Using these we can create visible ships which can also send debug
    information to a file when they're pinged:
    class VisibleShip(ship, sprite, debug):
    x = 300
    y = 300
    image = "ship.png"

    class FasterVisibleShip(fastership, sprite, debug):
    x = 400
    y = 400
    image = "fastship.png"

    And use them like this:

    import pygame
    pygame.init()

    display = pygame.display.set_mode((800, 600), 0)

    ship_one = VisibleShip(step=1)
    ship_two = FasterVisibleShip(angle = 60)

    t = time.time()
    while time.time()-t <1 :
    display.fill((0,0,0))
    for sprite in mixin.objects:
    sprite.render(display)
    sprite.dump_state(sprite)
    sprite.update()
    pygame.display.flip()
    time.sleep(0.05)

    Now, you could do this the other way I mentioned by by using kwargs,
    and super in this way
    you can get the various classes to play nicely with each other, which
    means you can have
    clearer code.

    After all, our ship / fastership have now become focussed on the code
    you want them to model - not
    on faff with superclasses:

    class ship(mixin):
    x = 0
    y = 0
    step = 1
    angle = 0
    name = ""
    def update(self):
    self.x = self.x + math.cos(math.radians(self.angle)) *
    self.step
    self.y = self.y + math.sin(math.radians(self.angle)) *
    self.step

    class fastership(ship):
    speed = 1
    def update(self):
    self.x = self.x + math.cos(math.radians(self.angle)) *
    self.step * self.speed
    self.y = self.y + math.sin(math.radians(self.angle)) *
    self.step * self.speed

    But not only that they play nicely with debug code and also display
    code, and you get
    defaults you can inherit at the same time too. If you wrote ship /
    fastership with an
    explicit init and didn't do the super() call - eg like this:

    class ship(object):
    def __init__(self,x=0,y=0,step=1,angle=0, name=''):
    self.x = x
    self.y = y
    self.step = step
    self.angle = angle
    self.name = name
    def update(self):
    self.x = self.x + math.cos(math.radians(self.angle)) *
    self.step
    self.y = self.y + math.sin(math.radians(self.angle)) *
    self.step

    class fastership(ship):
    def __init__(self,speed=1):
    ship.__init__(self,x=0,y=0,step=1,angle=0, name='')
    self.speed = speed
    def update(self):
    self.x = self.x + math.cos(math.radians(self.angle)) *
    self.step * self.speed
    self.y = self.y + math.sin(math.radians(self.angle)) *
    self.step * self.speed

    and mixed in like this:

    class VisibleShip(ship, sprite):
    image = "ship.png"

    class FasterVisibleShip(fastership, sprite):
    image = "fastship.png"

    Then the code breaks - simply because you're doing this:
    ship.__init__(self,x=0,y=0,step=1,angle=0, name='')

    rather than:
    super(ship,self).__init__()

    and
    super(fastership,self).__init__()

    At the end of the day, both approaches *work* but to differing levels
    and
    differing levels of flexibility & maintainability.

    From the perspective of fragility though this approach is far more
    fragile:
    ship.__init__(self,x=0,y=0,step=1,angle=0, name='')

    </tuppenceworth>

    For convenience I'm copying below my .sig the code I mention above,
    for you
    to make your own mind up which you find more maintainable. (Consider
    extending
    sprite handling, or the complexity of the ship model)



    Michael.
    --
    http://www.kamaelia.org/Home , http://twitter.com/kamaelian

    #!/usr/bin/python

    class mixin(object):
    """
    The key benefit of this mixin is that it tracks instances created
    and
    also allows subclasses to have inheritable default values.
    """
    objects = []
    def __init__(self, **kwargs):
    super(mixin, self).__init__()
    self.__dict__.update(**kwargs)
    self.objects.append(self)

    import math
    class ship(mixin):
    x = 0
    y = 0
    step = 1
    angle = 0
    name = ""
    def update(self):
    self.x = self.x + math.cos(math.radians(self.angle)) *
    self.step
    self.y = self.y + math.sin(math.radians(self.angle)) *
    self.step

    class fastership(ship):
    speed = 1
    def update(self):
    self.x = self.x + math.cos(math.radians(self.angle)) *
    self.step * self.speed
    self.y = self.y + math.sin(math.radians(self.angle)) *
    self.step * self.speed

    class sprite(mixin):
    x = 0
    y = 0
    image = "sprite.png"
    display = None
    def __init__(self, **kwargs):
    super(sprite, self).__init__(**kwargs)
    self._image = pygame.image.load(self.image)
    print "Image Loaded", self.__class__

    def render(self,surface):
    # assume surface is something like a pygame surface
    surface.blit(self._image, (self.x, self.y))

    import time
    class debug(mixin):
    "Not perfect at all IMO"
    debug_file = "debug.log"
    debug_handle = None
    def __init__(self, **kwargs):
    print "Creation arguments", self.__class__, kwargs
    super(debug, self).__init__(**kwargs)

    @classmethod
    def dump_state(klass,self):
    if klass.debug_handle is None:
    klass.debug_handle = open(self.debug_file, "w")
    klass.debug_handle.write(str(time.time()) + ":" + str(klass) +
    ":" + str(self.__dict__)+"\n\n")
    klass.debug_handle.flush()

    class VisibleShip(ship, sprite, debug):
    x = 300
    y = 300
    image = "ship.png"

    class FasterVisibleShip(fastership, sprite, debug):
    x = 400
    y = 400
    image = "fastship.png"

    import pygame
    pygame.init()

    display = pygame.display.set_mode((800, 600), 0)

    ship_one = VisibleShip(step=1)
    ship_two = FasterVisibleShip(angle = 60)

    t = time.time()
    while time.time()-t <1 :
    display.fill((0,0,0))
    for sprite in mixin.objects:
    sprite.render(display)
    sprite.dump_state(sprite)
    sprite.update()
    pygame.display.flip()
    time.sleep(0.05)
    Michael Sparks, Feb 14, 2011
    #6
  7. James Mills

    rantingrick Guest

    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'd like to use like
    > this:


    [snip: miles of code not formatted for 79 chars!]

    That was a nice long winded example of how to break code by using it
    in an improper manner. You could have just called the base with one
    too many arguments and achieved the same. However the developer would
    be suffering from either; severe memory loss and/or lack of reading
    comprehension if he tried to use -a- his class interface in a manner
    that it was not originally intended. I could likewise use a hammer to
    drive screws and then rant and rave later how the hammer is
    insufficient. Surely my methods could not be a fault, surely? ;-)
    rantingrick, Feb 14, 2011
    #7
  8. 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.

    >
    > > For example, I could write a display mixin that I'd like to use like
    > > this:

    >
    > [snip: miles of code not formatted for 79 chars!]


    Core code recopied into a pastebin instead, if that's your only
    problem.
    * http://pastebin.com/nuaafqSE

    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.

    > That was a nice long winded example of how to break code by using it
    > in an improper manner.


    No, it was a thought out example of how writing code slightly
    differently from how you do now can result in something more
    practical, reusable, extendable, and maintainable. I was hoping to
    educate you as to why one approach *might* be considered better than
    another.

    Deriding is as you do completely misses the point, sadly.


    Michael.
    Michael Sparks, Feb 14, 2011
    #8
  9. 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 problem.
    > >
    > > For example, I could write a display mixin that I'd like to use like
    > > this:

    >
    > [snip: miles of code not formatted for 79 chars!]
    >
    > That was a nice long winded example of how to break code by using it
    > in an improper manner. You could have just called the base with one
    > too many arguments and achieved the same. However the developer would
    > be suffering from either; severe memory loss and/or lack of reading
    > comprehension if he tried to use -a- his class interface in a manner
    > that it was not originally intended. I could likewise use a hammer to
    > drive screws and then rant and rave later how the hammer is
    > insufficient. Surely my methods could not be a fault, surely? ;-)

    That's nowhere near a mile.
    Westley Martínez, Feb 14, 2011
    #9
  10. James Mills

    rantingrick Guest

    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 of being "brittle" yet you had to go to
    extraordinarily lengths to break my "fragile" code. Not even
    considering that my "habit" of hard coding the base is perfectly legal
    and accepted in Python code. And did you read the link Ian Kelly's
    provided?

    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 the gun at your foot and then pull
    the trigger because you could blow your pinky toe off"... no, i would
    expect them to have enough sense not to do such a stupid thing.
    However, if they *did* happen to blow their pinky toe off i really
    would not get too upset about it. After all, i've always believed that
    stupidity should be painful.

    > No, it was a thought out example of how writing code slightly
    > differently from how you do now can result in something more
    > practical, reusable, extendable, and maintainable.


    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 involved in a coding project should be
    spent in the design and testing phases and NOT actually writing code.
    If you spend more time writing code you are not being professional,
    you are being sloppy -- and it WILL catch up to you.
    rantingrick, Feb 14, 2011
    #10
  11. James Mills

    James Mills Guest

    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 the gun at your foot and then pull
    > the trigger because you could blow your pinky toe off"... no, i would
    > expect them to have enough sense not to do such a stupid thing.
    > However, if they *did* happen to blow their pinky toe off i really
    > would not get too upset about it. After all, i've always believed that
    > stupidity should be painful.


    This reminds me of "good engineering practise" where you
    let the error occur where it lay.

    Example:

    >>> def f(a):

    .... return a + 1
    ....
    >>> f(1)

    2
    >>> def g(*args):

    .... if len(args) == 1:
    .... return args[0] + 1
    .... else:
    .... raise Exception("Invalid arguments")
    ....
    >>> g(1)

    2
    >>> g()

    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "<stdin>", line 5, in g
    Exception: Invalid arguments
    >>> g(1, 2)

    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "<stdin>", line 5, in g
    Exception: Invalid arguments
    >>> f()

    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    TypeError: f() takes exactly 1 argument (0 given)
    >>> f(1, 2)

    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    TypeError: f() takes exactly 1 argument (2 given)
    >>>


    In that sense, you "trust" that the programmer using
    your API(s) has read "documentation" and/or "source code"
    and "understands" how to "correctly" use the API(s).

    If the programmer doesn't use the API(s) "correctly"
    f(...) will blow up in his/her face. g(...) will blow up as well
    but tries to guard against the expected TypeError you
    would expect if you called f(...) incorrectly.

    cheers
    James

    --
    -- James Mills
    --
    -- "Problems are solved by method"
    James Mills, Feb 14, 2011
    #11
  12. James Mills

    James Mills Guest

    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 involved in a coding project should be
    > spent in the design and testing phases and NOT actually writing code.
    > If you spend more time writing code you are not being professional,
    > you are being sloppy -- and it WILL catch up to you.


    I actually agree with this. :)

    --JamesMills

    --
    -- James Mills
    --
    -- "Problems are solved by method"
    James Mills, Feb 14, 2011
    #12
  13. James Mills

    alex23 Guest

    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 clairvoyant.
    > > However the vast amount of time involved in a coding project should be
    > > spent in the design and testing phases and NOT actually writing code.
    > > If you spend more time writing code you are not being professional,
    > > you are being sloppy -- and it WILL catch up to you.

    >
    > I actually agree with this. :)


    The problem is that it's not a philosophy which the ranting one
    practices, it's a bludgeon he uses to dump crap on other people for
    disagreeing with him.

    The offensive aspect of it is the implication that the rest of us are
    dumb assholes who don't already know this.
    alex23, Feb 15, 2011
    #13
  14. James Mills

    rantingrick Guest

    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 could argue quite *successfully* that i have been designing
    the rebirth (and fostering the forward thinking evolution!) of the
    entire Python community and some very important aspects of the
    language for the last couple of years. I have risen through the ranks
    from a mere scribe to a truly Pythonic visionary. However, some of my
    fellow "engineers" refuse to move from the design phase into the
    production phase due to "silly squabbling" and "petty posturing". We
    can do many great things if we can put our egos aside and join
    together in a common goal.

    [Anecdote]
    I always find it interesting how once a person joins an online group
    as a "helper" they cannot ask questions anymore. It's like an
    unwritten law you dare not break because if you do your "peers" will
    see you as weak and they will pounce on you, discredit you, and then
    excommunicate you! Any sign of weakness and your out. However if you
    show force and brow beat those who dare challenge you then fear will
    elevate you through the ranks. This should not be the case. No one
    person knows everything. Not even the great Guido van Rossum himself
    could have engineered something like Python alone. Sure, Python is
    *his* brainchild (and a very beautiful one!) however, he would have
    made many mistakes and/or left out many good designs if he did not
    have the help of a strong community.

    [Back on track]
    I would like to see this group drop the egos and start really working
    together. Stop being afraid of how you appear to others and be
    yourself. Some folks will be good in one area and other folks in
    another. Only together can we conquer all problem domains.

    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!
    rantingrick, Feb 15, 2011
    #14
  15. 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 that it's not a philosophy which the ranting one
    > > practices,

    >
    > Actually I could argue quite *successfully* that i have been designing
    > the rebirth (and fostering the forward thinking evolution!) of the
    > entire Python community and some very important aspects of the
    > language for the last couple of years. I have risen through the ranks
    > from a mere scribe to a truly Pythonic visionary. However, some of my
    > fellow "engineers" refuse to move from the design phase into the
    > production phase due to "silly squabbling" and "petty posturing". We
    > can do many great things if we can put our egos aside and join
    > together in a common goal.
    >
    > [Anecdote]
    > I always find it interesting how once a person joins an online group
    > as a "helper" they cannot ask questions anymore. It's like an
    > unwritten law you dare not break because if you do your "peers" will
    > see you as weak and they will pounce on you, discredit you, and then
    > excommunicate you! Any sign of weakness and your out. However if you
    > show force and brow beat those who dare challenge you then fear will
    > elevate you through the ranks. This should not be the case. No one
    > person knows everything. Not even the great Guido van Rossum himself
    > could have engineered something like Python alone. Sure, Python is
    > *his* brainchild (and a very beautiful one!) however, he would have
    > made many mistakes and/or left out many good designs if he did not
    > have the help of a strong community.
    >
    > [Back on track]
    > I would like to see this group drop the egos and start really working
    > together. Stop being afraid of how you appear to others and be
    > yourself. Some folks will be good in one area and other folks in
    > another. Only together can we conquer all problem domains.
    >
    > 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 DER FUHRER!
    Westley Martínez, Feb 15, 2011
    #15
  16. James Mills

    alex23 Guest

    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 past: arrogance, empty rhetoric and
    endless trolling.

    BTW, do you see the contradiction in the following two statements?

    > We can do many great things if we can put our egos aside and join
    > together in a common goal.


    > I have risen through the ranks
    > from a mere scribe to a truly Pythonic visionary.


    How's that ego-aside process working out for you?

    One last time: no one will respect you until you act in a manner that
    warrants it. Huge textual screeds aren't anything to be proud of; I
    have written markov chainers that produce more convincing rants than
    you. The _only_ thing that matters here is the code you produce.
    alex23, Feb 15, 2011
    #16
  17. 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 everyone must be clairvoyant.
    >> However the vast amount of time involved in a coding project should be
    >> spent in the design and testing phases and NOT actually writing code.
    >> If you spend more time writing code you are not being professional, you
    >> are being sloppy -- and it WILL catch up to you.

    >
    > I actually agree with this. :)



    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 testing *as you are writing*. The two need to
    go in parallel.

    I don't follow full-blown test driven development where you write the
    test before you write the code, but still, the time to find out your
    infrastructure is fundamentally broken is *before* you have finished it,
    not three months later when you have built the entire app on top of it.



    --
    Steven
    Steven D'Aprano, Feb 15, 2011
    #17
  18. On Tue, 2011-02-15 at 08:36 +0000, 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 comrades in
    > >> arms. This is the future i bring to c.l.py!

    > > HEIL DER FUHRER!

    >
    > Godwin was right. You lose.
    >
    > --
    > Duncan Booth http://kupuguy.blogspot.com

    Who's more trollish? The troll, or the troll who follows him?
    Westley Martínez, Feb 15, 2011
    #18
  19. James Mills

    James Mills Guest

    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 testing *as you are writing*. The two need to
    > go in parallel.
    >
    > I don't follow full-blown test driven development where you write the
    > test before you write the code, but still, the time to find out your
    > infrastructure is fundamentally broken is *before* you have finished it,
    > not three months later when you have built the entire app on top of it.


    Perhaps I should have clarified. I agreed only with the
    fact that if you spend more time in "careful" design
    you might spend less time fixing "defects".

    Agreed, test-driven development tends to lend itself
    to higher quality code.

    cheers
    James

    --
    -- James Mills
    --
    -- "Problems are solved by method"
    James Mills, Feb 15, 2011
    #19
  20. James Mills

    rantingrick Guest

    On Feb 14, 9:44 pm, Steven D'Aprano <steve
    > 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 afterthought.
    > >> Of course i am not suggesting that everyone must be clairvoyant.
    > >> However the vast amount of time involved in a coding project should be
    > >> spent in the design and testing phases and NOT actually writing code.
    > >> If you spend more time writing code you are not being professional, you
    > >> are being sloppy -- and it WILL catch up to you.

    >
    > > I actually agree with this. :)

    >
    > 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 testing *as you are writing*. The two need to
    > go in parallel.


    My statement made no such mention of "separate phases" or how each
    phase should be ordered. Here, l'll paraphrase for the folks who's
    attention span cannot last for a full paragraph. *ahem*... "You should
    spend more time designing and testing code than writing it"... I hope
    that was clear enough for you.

    # In Code form.
    if (dev.design_time + dev.test_time) < dev.write_time:
    print('Good Job Skippy!')
    else:
    raise ScriptKiddieError
    rantingrick, Feb 15, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. PATRICE

    newbies and quartus

    PATRICE, Jun 14, 2004, in forum: VHDL
    Replies:
    2
    Views:
    570
    Ken Smith
    Jun 15, 2004
  2. Rob Richardson

    Other newsgroups for newbies?

    Rob Richardson, Mar 16, 2006, in forum: ASP .Net
    Replies:
    3
    Views:
    317
    Juan T. Llibre
    Mar 16, 2006
  3. Joona I Palaste

    Question about newbies and interfaces

    Joona I Palaste, Nov 30, 2003, in forum: Java
    Replies:
    2
    Views:
    333
    Chris Uppal
    Nov 30, 2003
  4. Alf P. Steinbach

    How we recognize newbies as newbies

    Alf P. Steinbach, Aug 13, 2007, in forum: C++
    Replies:
    31
    Views:
    1,078
    Diego Martins
    Aug 21, 2007
  5. James Mills
    Replies:
    4
    Views:
    223
    rantingrick
    Feb 13, 2011
Loading...

Share This Page