FAQ
Working on parser for my language, I see that all classes (Token,
Production, Statement, ...) have one thing in common. They all
maintain start and stop positions in the source text. So it seems
logical to have them all inherit from a base class that defines those,
but this doesn't work:

import tok

class code:
def __init__( self, start, stop ):
startLoc = start
stopLoc = stop

class token(code):
pass

x = token( tok.Loc(0, 0), tok.Loc(3, 4) )

print x.startLoc.repr(), x.stopLoc.repr()

AttributeError: token instance has no attribute 'startLoc'

1) Is my design thinking good, or hopelessly unPythonic?

2) If it's good, how do you access base class data attributes? (The
doc is rich in method access info, impoverished when it comes to other
attributes.)

Search Discussions

  • Jeroen Ruigrok van der Werven at Jan 5, 2008 at 10:37 am

    -On [20080105 11:36], MartinRinehart at gmail.com (MartinRinehart at gmail.com) wrote:
    class code:
    def __init__( self, start, stop ):
    startLoc = start
    stopLoc = stop
    Shouldn't this be:

    self.startLoc = start
    self.stopLoc = stop

    ?

    --
    Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
    ????? ?????? ??? ?? ??????
    http://www.in-nomine.org/ | http://www.rangaku.org/
    Open your Heart and push the limits...
  • Paul Hankin at Jan 5, 2008 at 10:37 am

    On Jan 5, 10:31?am, MartinRineh... at gmail.com wrote:
    ...
    class code:
    ? ? def __init__( self, start, stop ):
    ? ? ? ? startLoc = start
    ? ? ? ? stopLoc = stop
    ...
    You've forgotten the explicit self.
    def __init__( self, start, stop ):
    self.startLoc = start
    self.stopLoc = stop

    --
    Paul Hankin
  • MartinRinehart at Jan 5, 2008 at 10:40 am

    Jeroen Ruigrok van der Werven wrote:
    Shouldn't this be:

    self.startLoc = start
    self.stopLoc = stop
    Thanks! Of course it should. Old Java habits die slowly.
  • Bjoern Schliessmann at Jan 5, 2008 at 10:53 am

    MartinRinehart at gmail.com wrote:
    Jeroen Ruigrok van der Werven wrote:
    self.startLoc = start
    self.stopLoc = stop
    Thanks! Of course it should. Old Java habits die slowly.
    That's not really a Java habit. In Java and C++, personally I like
    to write

    this.startLoc = start
    this.stopLoc = stop

    It makes much clearer what a field and what a "normal" variable is
    in those languages.

    Regards,


    Bj?rn

    --
    BOFH excuse #294:

    PCMCIA slave driver
  • Dan Bishop at Jan 6, 2008 at 11:59 pm

    On Jan 5, 4:53 am, Bjoern Schliessmann <usenet- mail-0306.20.chr0n... at spamgourmet.com> wrote:
    MartinRineh... at gmail.com wrote:
    Jeroen Ruigrok van der Werven wrote:
    self.startLoc = start
    self.stopLoc = stop
    Thanks! Of course it should. Old Java habits die slowly.
    That's not really a Java habit. In Java and C++, personally I like
    to write

    this.startLoc = start
    this.stopLoc = stop

    It makes much clearer what a field and what a "normal" variable is
    in those languages.
    My employer has us use the "m_" convention.

    I wonder why Bjarne made "this->" optional in the first place.
  • Neil Cerutti at Jan 7, 2008 at 12:22 am

    On Jan 6, 2008 6:59 PM, Dan Bishop wrote:
    My employer has us use the "m_" convention.

    I wonder why Bjarne made "this->" optional in the first place.
    --
    http://mail.python.org/mailman/listinfo/python-list
    I think implicit this-> is somewhat more defensible. If 'this' were not a
    pointer, perhaps C++ wouldn't have chosen impliciticity..

    --
    Neil Cerutti
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.python.org/pipermail/python-list/attachments/20080106/d9054a1f/attachment.htm
  • Lie at Jan 5, 2008 at 6:12 pm

    On Jan 5, 5:40?pm, MartinRineh... at gmail.com wrote:
    Jeroen Ruigrok van der Werven wrote:
    Shouldn't this be:
    self.startLoc = start
    self.stopLoc = stop
    Thanks! Of course it should. Old Java habits die slowly.
    No, seriously it isn't Java habits only, most other languages wouldn't
    need explicit calling of class name.
  • Bruno Desthuilliers at Jan 6, 2008 at 7:46 pm

    Lie a ?crit :
    On Jan 5, 5:40 pm, MartinRineh... at gmail.com wrote:

    Jeroen Ruigrok van der Werven wrote:

    Shouldn't this be:
    self.startLoc = start
    self.stopLoc = stop
    Thanks! Of course it should. Old Java habits die slowly.

    No, seriously it isn't Java habits only, most other languages wouldn't
    need explicit calling of class name.
    Where is the "explicit calling of class name" exactly ?
  • Lie at Jan 14, 2008 at 6:15 pm

    On Jan 7, 2:46?am, Bruno Desthuilliers wrote:
    Lie a ?crit :
    On Jan 5, 5:40 pm, MartinRineh... at gmail.com wrote:

    Jeroen Ruigrok van der Werven wrote:
    Shouldn't this be:
    self.startLoc = start
    self.stopLoc = stop
    Thanks! Of course it should. Old Java habits die slowly.
    No, seriously it isn't Java habits only, most other languages wouldn't
    need explicit calling of class name.
    Where is the "explicit calling of class name" exactly ?
    Perhaps I was a bit tired when writing that (I wouldn't understand
    what I wrote if I were you)... what I meant is most other languages
    doesn't usually enforce us to explicitly state the containing class
    name, which in python is generally called "self". Most other languages
    1) automatically assign the containing class' object in a keyword
    (Java: this, VB: Me) behind the screen, and 2) automatically searches
    variable name in both the local variable table and the containing
    class variable table (so to refer to a class variable named var from a
    method inside the class, we only need to write var, not self.var as in
    python). In VB, Me is extremely rarely used, in Python, self is all
    over the place. Well, there is positive and negative to both sides,
    convenience in VB, and flexibility in Python.

    Compare the following codes:
    VB.NET:
    Public Class A
    Dim var
    Public Function aFunction()
    return var

    Python:
    class A:
    def aFunction(self):
    return self.var
  • Bruno Desthuilliers at Jan 15, 2008 at 2:00 pm

    Lie a ?crit :
    On Jan 7, 2:46 am, Bruno Desthuilliers
    wrote:
    Lie a ?crit :
    On Jan 5, 5:40 pm, MartinRineh... at gmail.com wrote:
    Jeroen Ruigrok van der Werven wrote:
    Shouldn't this be:
    self.startLoc = start
    self.stopLoc = stop
    Thanks! Of course it should. Old Java habits die slowly.
    No, seriously it isn't Java habits only, most other languages wouldn't
    need explicit calling of class name.
    Where is the "explicit calling of class name" exactly ?
    Perhaps I was a bit tired when writing that (I wouldn't understand
    what I wrote if I were you)... what I meant is most other languages
    doesn't usually enforce us to explicitly state the containing class
    name, which in python is generally called "self".
    'self' (or whatever you name it) is not the "containing class name",
    it's the first argument of the function - which usually happens to be
    the current instance when the function is used as a method.
    Most other languages
    1) automatically assign the containing class' object
    s/containing class' object/current instance/
    in a keyword
    (Java: this, VB: Me) behind the screen,
    That's not very far from what a Python method object does -
    automatically assign the current instance to something. The difference
    is that Python uses functions to implement methods (instead of having
    two distinct contructs), so the only reliable way to "inject" the
    reference to the current instance is to pass it as an argument to the
    function (instead of making it pop from pure air).

    There are some benefits to this solution. One of them is the ability to
    dynamically assign functions as methods. So if you do have some
    function taking an object as first argument, you can easily turn it into
    a method.
    and 2) automatically searches
    variable name in both the local variable table and the containing
    class variable table (so to refer to a class variable named var from a
    method inside the class, we only need to write var, not self.var as in
    python).
    This - as you know - cannot work well with Python's scoping rules and
    dynamicity. Anyway, implicit object reference is definitively a
    BadThing(tm) wrt/ readbility, specially with multiparadigm languages
    (like Python or C++). Why do you think soooo many C++ shops impose the
    m_something naming scheme ?

    Anyway, I actually know 3 languages (4 if C# works the same) that has
    this implicit 'this' (or whatever the name) 'feature', and at least 5
    that don't. So I'm not sure that the "most other languages" qualifier
    really applies to point 2 !-)
    In VB, Me is extremely rarely used,
    I used to systematically use it - like I've always systematically used
    'this' in C++ and Java.
    in Python, self is all
    over the place. Well, there is positive and negative to both sides,
    convenience in VB, and flexibility in Python.
    As far as I'm concerned, there's *no* positive point in implicit object
    reference, and there has never been (and before some paranoid nutcase
    around accuse me of overzealous biggotry : I already held this very same
    opinion years before I discovered Python).
    Compare the following codes:
    VB.NET:
    Public Class A
    Dim var
    Public Function aFunction()
    return var
    Add three levels of inheritence and a couple globals and you'll find out
    that readability count !-)

    In any non-trivial piece of C++ code, and unless the author either used
    the explicit 'this' reference or the 'm_xxx' naming convention, you'll
    have hard time figuring out where a given name comes from when browsing
    a function's code.
  • Lie at Jan 16, 2008 at 12:38 pm

    On Jan 15, 9:00?pm, Bruno Desthuilliers <bruno. 42.desthuilli... at wtf.websiteburo.oops.com> wrote:
    Lie a ?crit :


    On Jan 7, 2:46 am, Bruno Desthuilliers
    wrote:
    Lie a ?crit :
    On Jan 5, 5:40 pm, MartinRineh... at gmail.com wrote:
    Jeroen Ruigrok van der Werven wrote:
    Shouldn't this be:
    self.startLoc = start
    self.stopLoc = stop
    Thanks! Of course it should. Old Java habits die slowly.
    No, seriously it isn't Java habits only, most other languages wouldn't
    need explicit calling of class name.
    Where is the "explicit calling of class name" exactly ?
    Perhaps I was a bit tired when writing that (I wouldn't understand
    what I wrote if I were you)... what I meant is most other languages
    doesn't usually enforce us to explicitly state the containing class
    name, which in python is generally called "self".
    'self' (or whatever you name it) is not the "containing class name",
    Current instance is what I meant, thanks for pointing out the
    incorrect term I used.
    it's the first argument of the function - which usually happens to be
    the current instance when the function is used as a method.
    And that's the point, self (or anything you name it) is almost always
    the current instance and that makes it functionally the same as Me and
    this in VB and Java.
    Most other languages
    1) automatically assign the containing class' object
    s/containing class' object/current instance/
    in a keyword
    (Java: this, VB: Me) behind the screen,
    That's not very far from what a Python method object does -
    automatically assign the current instance to something. The difference
    is that Python uses functions to implement methods (instead of having
    two distinct contructs), so the only reliable way to "inject" the
    reference to the current instance is to pass it as an argument to the
    function (instead of making it pop from pure air).
    It isn't very far, but Python makes it obvious about the assignment
    (not behind the screen).
    There are some benefits to this solution. One of them is the ability to
    ? dynamically assign functions as methods. So if you do have some
    function taking an object as first argument, you can easily turn it into
    a method.
    Indeed, many languages doesn't allow dynamic assignment of function
    which makes having an automatic assignment of current instance to Me/
    this possible and with minimal harm.
    and 2) automatically searches
    variable name in both the local variable table and the containing
    class variable table ?(so to refer to a class variable named var from a
    method inside the class, we only need to write var, not self.var as in
    python).
    This - as you know - cannot work well with Python's scoping rules and
    dynamicity. Anyway, implicit object reference is definitively a
    BadThing(tm) wrt/ readbility, specially with multiparadigm languages
    (like Python or C++). Why do you think soooo many C++ shops impose the
    m_something naming scheme ?
    Implicit object reference for the containing class has little harm, if
    a class is so complex that there are more than 10 class-level
    variable, then it is obvious that that class needs to be fragmented to
    smaller classes. Remembering less than 10 variable and avoiding naming
    collision among just 10 variable is not hard (and 10 is really too
    many, most classes should only use 2-4 variables), especially if you
    have a good IDE that employs Intellisense-like technology (IDLE has
    it). And it is always a Bad Thing(tm) to use the same name for two
    variable in the class and in function (which is the main and only
    source of possible ambiguity) in ANY language, even in Python.
    Anyway, I actually know 3 languages (4 if C# works the same) that has
    this implicit 'this' (or whatever the name) 'feature', and at least 5
    that don't. So I'm not sure that the "most other languages" qualifier
    really applies to point 2 !-)
    What's this 5 languages? Are they a mainstream, high-level languages
    or lesser known, low-level languages? C-family, Java, and Basic are
    the Big Three of high-level programming language.
    In VB, Me is extremely rarely used,
    I used to systematically use it - like I've always systematically used
    'this' in C++ ?and Java.
    And that is what reduces readability. A proficient VB/C/Java
    programmer would frown upon the extra, unneeded garbage as they
    thought it was clear already that the variable refers to a class-level
    variable. It is a different story if, like Python, the use of self is
    enforced by the language, the self wouldn't be viewed as extra
    unnecessary garbage.
    in Python, self is all
    over the place. Well, there is positive and negative to both sides,
    convenience in VB, and flexibility in Python.
    As far as I'm concerned, there's *no* positive point in implicit object
    reference, and there has never been (and before some paranoid nutcase
    around accuse me of overzealous biggotry : I already held this very same
    opinion years before I discovered Python).
    There is one major positive point: convenience and shorter code.
    (isn't that two?)
    As I've pointed out, there is little harm in class-level variable's
    implicit reference.
    Compare the following codes:
    VB.NET:
    Public Class A
    ? ? Dim var
    ? ? Public Function aFunction()
    ? ? ? ? return var
    Add three levels of inheritence and a couple globals and you'll find out
    that readability count !-)
    It's the mental model that have to be adapted here, if the current
    class is inheriting from another class, you've got to think it as
    names from parent class as it is a native names, so you don't actually
    need to know where the variable comes from since knowing where it
    comes from is breaking the encapsulation (which, in Python is very
    weakly implemented, which favors flexibility in many cases[1]).

    [1] In Python, it is impossible to create a completely private
    variable, which is the reason why the mental model of these other
    languages doesn't fit Python.
    In any non-trivial piece of C++ code, and unless the author either used
    the explicit 'this' reference or the 'm_xxx' naming convention, you'll
    have hard time figuring out where a given name comes from when browsing
    a function's code.
    If you're used to the implicit naming scheme it's easy to know where a
    variable came from, if not the current scope, it's the class' scope
    and searching two short variable tables (SHORT! Creating complex
    classes is for stupid programmers[2]) at the same time isn't an
    expensive operation for human-being, especially if memoization is
    implemented.

    [2] I used to create an extremely complex classes when I was still
    green in programming, and that hits me back many times. Small, simple
    class is A Good Thing(tm). Class should use less than 10 variables,
    although the recommended number is 2-3 variables. Function names
    should be as little as possible, the use of overloading and overriding
    should be maximized.

    As a final note:
    I don't think implicit class reference is superior to explicit class
    reference, neither do I think explicit class reference is superior to
    implicit class reference. I think both have their own +s and -s. I
    only pointed out that implicit do have its benefits, depending on the
    language used (obviously Python wouldn't benefit from using implicit
    behavior, due to it being extremely dynamic).
  • Bjoern Schliessmann at Jan 16, 2008 at 2:23 pm

    Lie wrote:
    42.desthuilli... at wtf.websiteburo.oops.com> wrote:
    I used to systematically use it - like I've always systematically
    used 'this' in C++ ?and Java.
    And that is what reduces readability.
    IMHO not, IOPHO not. This is the nth time (n >> 1) this discussion
    comes up here. If I have learned one thing from those very lengthy
    discussions, it's that Python's "self" handling is not going to
    change.
    A proficient VB/C/Java programmer would frown upon the extra,
    unneeded garbage as they thought it was clear already that the
    variable refers to a class-level variable.
    C programmers surely have no opinion concerning C because it has no
    native classes.

    Personally, I've seen many C++ programs with complex class designs
    where it definitely helps to consistently use "this->". I cannot
    remember all local (and global) variables in bigger methods.
    There is one major positive point: convenience and shorter code.
    (isn't that two?)
    Shorter code is not per se positive, neither is it convenient. If it
    was, everyone would use perl.

    Regards,


    Bj?rn

    --
    BOFH excuse #109:

    The electricity substation in the car park blew up.
  • Bruno Desthuilliers at Jan 16, 2008 at 3:10 pm

    Lie a ?crit :
    On Jan 15, 9:00 pm, Bruno Desthuilliers <bruno.
    42.desthuilli... at wtf.websiteburo.oops.com> wrote:
    Lie a ?crit :


    On Jan 7, 2:46 am, Bruno Desthuilliers
    wrote:
    Lie a ?crit :
    (snip)
    No, seriously it isn't Java habits only, most other languages wouldn't
    need explicit calling of class name.
    Where is the "explicit calling of class name" exactly ?
    Perhaps I was a bit tired when writing that (I wouldn't understand
    what I wrote if I were you)... what I meant is most other languages
    doesn't usually enforce us to explicitly state the containing class
    name, which in python is generally called "self".
    'self' (or whatever you name it) is not the "containing class name",
    Current instance is what I meant, thanks for pointing out the
    incorrect term I used.
    it's the first argument of the function - which usually happens to be
    the current instance when the function is used as a method.
    And that's the point, self (or anything you name it) is almost always
    the current instance
    # this is a plain function. In this function,
    # 'obj' can be whatever that happens to have a (numeric)
    # 'stuff' attribute
    def func(obj, arg):
    return (obj.stuff + arg) / 2.0

    # this is a class with an instance attribute 'stuff'
    class Foo(object):
    def __init__(self, bar):
    self.stuff = bar + 42


    # this is another (mostly unrelated) class
    # with a class attribute 'stuff'
    class Bar(object):
    stuff = 42


    # this is a dummy container class:
    class Dummy(object): pass


    # now let's play:
    import new

    d = Dummy()
    d.stuff = 84
    print func(d, 1)

    d.baaz = new.instancemethod(func, d, type(d))
    print d.baaz(2)

    f = Foo(33)
    print func(f, 3)
    Foo.baaz = func
    f.baaz(4)

    print func(Bar, 5)
    Bar.baaz = classmethod(func)
    Bar.baaz(6)

    and that makes it functionally the same as Me and
    this in VB and Java.
    Depends on the context, cf above !-)

    Most other languages
    1) automatically assign the containing class' object
    s/containing class' object/current instance/
    in a keyword
    (Java: this, VB: Me) behind the screen,
    That's not very far from what a Python method object does -
    automatically assign the current instance to something. The difference
    is that Python uses functions to implement methods (instead of having
    two distinct contructs), so the only reliable way to "inject" the
    reference to the current instance is to pass it as an argument to the
    function (instead of making it pop from pure air).
    It isn't very far, but Python makes it obvious about the assignment
    (not behind the screen).
    Exactly. And given both the simplicity of the solution and what it let
    you do, that's a *very* GoodThing(tm) IMHO.

    (snip)
    and 2) automatically searches
    variable name in both the local variable table and the containing
    class variable table (so to refer to a class variable named var from a
    method inside the class, we only need to write var, not self.var as in
    python).
    This - as you know - cannot work well with Python's scoping rules and
    dynamicity. Anyway, implicit object reference is definitively a
    BadThing(tm) wrt/ readbility, specially with multiparadigm languages
    (like Python or C++). Why do you think soooo many C++ shops impose the
    m_something naming scheme ?
    Implicit object reference for the containing class has little harm, if
    a class is so complex that there are more than 10 class-level
    variable, then it is obvious that that class needs to be fragmented to
    smaller classes.
    Not necessarily. There are general rules (like 'keep your classes small
    and focused', which I wholefully agree with), there are guidelines (like
    'more than 10 member variables might smell like refactoring), and
    there's real life, where one very often faces classes that have much
    more than 10 member variables and still are as small and focused as
    possible.
    Remembering less than 10 variable and avoiding naming
    collision among just 10 variable is not hard (and 10 is really too
    many, most classes should only use 2-4 variables),
    I really doubt you'll be able to write any working non-trivial software
    trying to strictly follow this rule.
    especially if you
    have a good IDE that employs Intellisense-like technology (IDLE has
    it).
    IDLE is certainly not a "good IDE" in my book.
    And it is always a Bad Thing(tm) to use the same name for two
    variable in the class and in function (which is the main and only
    source of possible ambiguity) in ANY language, even in Python.
    Ho, yes.... Like, this would be bad ?

    class Person(object):
    def __init__(self, firstname, lastname, birthdate, gender):
    self.firstname = firstname
    self.lastname = lastname
    self.birthdate = birthdate
    self.gender = gender


    C'mon, be serious. It's often hard enough to come with sensible names,
    why would one have to find synonyms too ? Try to come with something
    more readable than the above, and let us know. Seriously, this braindead
    rule about "not using the same name for an attribute and a local var"
    obviously comes from languages where the "this" ref is optional, and
    FWIW it's obviously the wrong solution to a real problem (the good
    solution being, of course, to use the fully qualified name for
    attributes so there's no possible ambiguity).
    Anyway, I actually know 3 languages (4 if C# works the same) that has
    this implicit 'this' (or whatever the name) 'feature', and at least 5
    that don't. So I'm not sure that the "most other languages" qualifier
    really applies to point 2 !-)
    What's this 5 languages?
    Smalltalk, Python, PHP, javascript, Ruby. I don't remember how Scheme,
    CLOS and OCaml handle the case.
    Are they a mainstream, high-level languages
    or lesser known, low-level languages? C-family, Java, and Basic are
    the Big Three of high-level programming language.
    None of C, C++, Java nor Basic qualify as "hi-level". C is the lowest
    possible level above assembly, C++ is often refered to as an "object
    oriented assembler", Java is way too static, crippled, verbose an
    unexpressive to qualify as "hi-level" (even if it suffers from some
    problems usually associated with higher level languages). I won't even
    comment on basic (is that really a language at all ?).
    In VB, Me is extremely rarely used,
    I used to systematically use it - like I've always systematically used
    'this' in C++ and Java.
    And that is what reduces readability. A proficient VB/C/Java
    programmer

    There are quite a few proficient C/C++/Java programmers here. As far as
    I'm concerned, I would not pretend being one - I just have a good enough
    knowledge of C, Java and (alas) VB to be able to get up to speed in a
    reasonnable time frame.

    As a side note, the problem just doesn't exists in C, which has
    absolutely no support for OO.
    would frown upon the extra, unneeded garbage as they
    thought it was clear already that the variable refers to a class-level
    variable.
    In C++, the canonical way to make this "clear" is to use the m_name
    convention. There must be some reason C++ programmers feel a need for
    this "extra, unneeded garbage" ?-)
    It is a different story if, like Python, the use of self is
    enforced by the language, the self wouldn't be viewed as extra
    unnecessary garbage.
    in Python, self is all
    over the place. Well, there is positive and negative to both sides,
    convenience in VB, and flexibility in Python.
    As far as I'm concerned, there's *no* positive point in implicit object
    reference, and there has never been (and before some paranoid nutcase
    around accuse me of overzealous biggotry : I already held this very same
    opinion years before I discovered Python).
    There is one major positive point: convenience and shorter code.
    (isn't that two?)
    These are not rated as "positive" in my book. That's perhaps why Python
    is so far MFL ?
    As I've pointed out, there is little harm in class-level variable's
    implicit reference.
    Have some working experience on any non-trivial C++ project ?
    Compare the following codes:
    VB.NET:
    Public Class A
    Dim var
    Public Function aFunction()
    return var
    Add three levels of inheritence and a couple globals and you'll find out
    that readability count !-)
    It's the mental model that have to be adapted here, if the current
    class is inheriting from another class, you've got to think it as
    names from parent class as it is a native names, so you don't actually
    need to know where the variable comes from
    In C++ (and VB IIRC), it might as well be a global So sorry but yes, I
    have to know where it comes from.
    since knowing where it
    comes from is breaking the encapsulation
    Nope, it's knowing what you're doing and how the piece of software at
    hand is working. And FWIW, while data hiding is one possible mean of
    encapsulation, it's by no way a synonym for encapsulation.
    (which, in Python is very
    weakly implemented, which favors flexibility in many cases[1]).

    [1] In Python, it is impossible to create a completely private
    variable, which is the reason why the mental model of these other
    languages doesn't fit Python.
    Never heard about the infamous '#define private public' hack in C++ ?
    And don't worry, there are also ways to get at so called 'private' vars
    in Java.
    In any non-trivial piece of C++ code, and unless the author either used
    the explicit 'this' reference or the 'm_xxx' naming convention, you'll
    have hard time figuring out where a given name comes from when browsing
    a function's code.
    If you're used to the implicit naming scheme it's easy to know where a
    variable came from, if not the current scope, it's the class' scope
    You forgot the global scope.

    (snip)
    As a final note:
    I don't think implicit class reference is superior to explicit class
    reference, neither do I think explicit class reference is superior to
    implicit class reference. I think both have their own +s and -s. I
    only pointed out that implicit do have its benefits,
    "benefit" here is a judgement call. It happens that neither I nor
    probably most of the people here share your judgement on this. Time for
    you to "import this" I'd say.
    depending on the
    language used (obviously Python wouldn't benefit from using implicit
    behavior, due to it being extremely dynamic).
    Not only. This is also (and almost firstly as far as I'm concerned) a
    matter of readability.

    Anyway: this-dead-horse-been-beaten-to-hell-and-back... So if you
    *really* want to have the last word, I'll leave it to you !-)
  • Lie at Jan 20, 2008 at 10:37 pm

    On Jan 16, 9:23 pm, Bjoern Schliessmann <usenet- mail-0306.20.chr0n... at spamgourmet.com> wrote:
    Lie wrote:
    42.desthuilli... at wtf.websiteburo.oops.com> wrote:
    I used to systematically use it - like I've always systematically
    used 'this' in C++ and Java.
    And that is what reduces readability.
    IMHO not, IOPHO not. This is the nth time (n >> 1) this discussion
    comes up here. If I have learned one thing from those very lengthy
    discussions, it's that Python's "self" handling is not going to
    change.
    And ah... yes, I don't wish it go away either. In VB, excessive Me
    reduces readability, but in Python it doesn't.
    A proficient VB/C/Java programmer would frown upon the extra,
    unneeded garbage as they thought it was clear already that the
    variable refers to a class-level variable.
    C programmers surely have no opinion concerning C because it has no
    native classes.
    C-family, ok? Please stop taking my words to its letters.
    Personally, I've seen many C++ programs with complex class designs
    where it definitely helps to consistently use "this->". I cannot
    remember all local (and global) variables in bigger methods.
    In that case, you have the _option_ to do it.
    There is one major positive point: convenience and shorter code.
    (isn't that two?)
    Shorter code is not per se positive, neither is it convenient. If it
    was, everyone would use perl.
    Not always, but sometimes it do help not to be obliged to use the
    class name especially in short, simple programs (as opposed to big
    projects that requires hundreds of thousands of lines of code) that is
    changed frequently (being in heavy development). A good real-life
    example for this would be for new learner of programming or the
    language, they would write a lot of ten liners that is changed a LOT
    of times due to their (yet) incomplete understanding of the concepts.
    it's the first argument of the function - which usually happens to be
    the current instance when the function is used as a method.
    And that's the point, self (or anything you name it) is almost always
    the current instance
    # this is a plain function. In this function,
    # 'obj' can be whatever that happens to have a (numeric)
    # 'stuff' attribute
    def func(obj, arg):
    ? ?return (obj.stuff + arg) / 2.0

    # this is a class with an instance attribute 'stuff'
    class Foo(object):
    ? ? def __init__(self, bar):
    ? ? ? self.stuff = bar + 42

    # this is another (mostly unrelated) class
    # with a class attribute 'stuff'
    class Bar(object):
    ? ?stuff = 42

    # this is a dummy container class:
    class Dummy(object): pass

    # now let's play:
    import new

    d = Dummy()
    d.stuff = 84
    print func(d, 1)

    d.baaz = new.instancemethod(func, d, type(d))
    print d.baaz(2)

    f = Foo(33)
    print func(f, 3)
    Foo.baaz = func
    f.baaz(4)

    print func(Bar, 5)
    Bar.baaz = classmethod(func)
    Bar.baaz(6)
    ?and that makes it functionally the same as Me and
    this in VB and Java.
    Depends on the context, cf above !-)
    Please again, stop taking letters to the words, I don't meant them to
    be exactly the same, rather the same would meant that they generally
    can be considered equal, exceptions exists of course. And btw, I don't
    understand what you meant by your example, they seemed to be a
    completely OK program for me, even though it's a bit confusing to
    follow[2].

    [2] btw, the reason it's a bit confusing to follow is one of my
    points: It is a Bad Thing(tm) to use the same name for different
    variables even in a language like Python that enforce explicit naming
    of classes
    Most other languages
    1) automatically assign the containing class' object
    s/containing class' object/current instance/
    in a keyword
    (Java: this, VB: Me) behind the screen,
    That's not very far from what a Python method object does -
    automatically assign the current instance to something. The difference
    is that Python uses functions to implement methods (instead of having
    two distinct contructs), so the only reliable way to "inject" the
    reference to the current instance is to pass it as an argument to the
    function (instead of making it pop from pure air).
    It isn't very far, but Python makes it obvious about the assignment
    (not behind the screen).
    Exactly. And given both the simplicity of the solution and what it let
    you do, that's a *very* GoodThing(tm) IMHO.
    I agree, it's a Good Thing but it doesn't make the point less pointy,
    the difference between Me/this and self is just the explicit
    assignment. Other things that is possible because of the explicit
    assignment is just a "coincidence" of design choice.
    and 2) automatically searches
    variable name in both the local variable table and the containing
    class variable table ?(so to refer to a class variable named var from a
    method inside the class, we only need to write var, not self.var as in
    python).
    This - as you know - cannot work well with Python's scoping rules and
    dynamicity. Anyway, implicit object reference is definitively a
    BadThing(tm) wrt/ readbility, specially with multiparadigm languages
    (like Python or C++). Why do you think soooo many C++ shops impose the
    m_something naming scheme ?
    Implicit object reference for the containing class has little harm, if
    a class is so complex that there are more than 10 class-level
    variable, then it is obvious that that class needs to be fragmented to
    smaller classes.
    Not necessarily. There are general rules (like 'keep your classes small
    and focused', which I wholefully agree with), there are guidelines (like
    'more than 10 member variables might smell like refactoring), and
    there's real life, where one very often faces classes that have much
    more than 10 member variables and still are as small and focused as
    possible.
    I'd add "whenever possible" then.

    I don't consider 10 as a guideline, but rather as a large number I
    randomly picked for an example, because in most project 10 is A LOT
    for number of variables, and I'm sure that most well designed program
    would have less than 10 variables per class (except in cases where it
    is just impossible to fragment the class any further).
    Remembering less than 10 variable and avoiding naming
    collision among just 10 variable is not hard (and 10 is really too
    many, most classes should only use 2-4 variables),
    I really doubt you'll be able to write any working non-trivial software
    trying to strictly follow this rule.
    In what way have I said that the rule is strict? No rule is ever
    strict in my book, ALL rules are meant to be bend in exceptional cases
    and ALL exceptions are meant to be excepted themselves (applying the
    definition recursively).
    especially if you
    have a good IDE that employs Intellisense-like technology (IDLE has
    it).
    IDLE is certainly not a "good IDE" in my book.
    What you've just said actually enforce the sentence, even a bad IDE
    like IDLE have Intellisense-like feature :)
    I agree that IDLE isn't a good IDE, but it is an example that I could
    use since it is the only Python IDE I have ever used (although I'm
    interested to find another, the demand isn't that high ...yet... to
    _have_ to find another IDE)
    And it is always a Bad Thing(tm) to use the same name for two
    variable in the class and in function (which is the main and only
    source of possible ambiguity) in ANY language, even in Python.
    Ho, yes.... Like, this would be bad ?

    class Person(object):
    ? ?def __init__(self, firstname, lastname, birthdate, gender):
    ? ? ?self.firstname = firstname
    ? ? ?self.lastname = lastname
    ? ? ?self.birthdate = birthdate
    ? ? ?self.gender = gender

    C'mon, be serious. It's often hard enough to come with sensible names,
    why would one have to find synonyms too ? Try to come with something
    more readable than the above, and let us know. Seriously, this braindead
    rule about ?"not using the same name for an attribute and a local var"
    obviously comes from languages where the "this" ref is optional, and
    FWIW it's obviously the wrong solution to a real problem (the good
    solution being, of course, to use the fully qualified name for
    attributes so there's no possible ambiguity).
    The code fragment you've given way above (about the Foo, Bar, bazz,
    and func) also suffers from the bad habits of using the same name for
    different variables.

    And it's not a "braindead" rule (even though I used the word always,
    it still isn't a braindead always without exceptions)

    The example you've given IS the most readable form since the function
    is _simple_, consider a function that have complex codes, possibly
    calculations instead of simply assigning initial values I'm sure you'd
    slip up between the self.* variables and the * variables once or
    twice, possibly becoming the source of hard-to-find bugs. In other
    hand in a _complex_ function, if you thought of a new name, like
    initialfirstname, etc you'd know what is what and what is where
    immediately

    And in languages that doesn't enforce explicit naming of classes, when
    there is the two or more same names, the one with the smallest scope
    is picked, so in _simple_ functions, the trick of using full qualified
    names and overloaded local names is still possible and feasible. In
    complex functions, the trick fails even in Python, because even if
    Python and our full-concentration-brain is aware of the difference
    between self.* and *, our spreaded-concentration-brain that is
    scanning the code for the source of bugs might get stumbled on the
    confusing use of self.* and *.
    Anyway, I actually know 3 languages (4 if C# works the same) that has
    this implicit 'this' (or whatever the name) 'feature', and at least 5
    that don't. So I'm not sure that the "most other languages" qualifier
    really applies to point 2 !-)
    What's this 5 languages?
    Smalltalk, Python, PHP, javascript, Ruby. I don't remember how Scheme,
    CLOS and OCaml handle the case.
    Among all them, only Javascript is considerably mainstream.
    Javascript, being virtually the only web-based scripting language that
    is supported by most browsers.
    Are they a mainstream, high-level languages
    or lesser known, low-level languages? C-family, Java, and Basic are
    the Big Three of high-level programming language.
    None of C, C++, Java nor Basic qualify as "hi-level". C is the lowest
    possible level above assembly, C++ is often refered to as an "object
    oriented assembler", Java is way too static, crippled, verbose an
    unexpressive to qualify as "hi-level" (even if it suffers from some
    problems usually associated with higher level languages). I won't even
    comment on basic (is that really a language at all ?).
    Your criteria on being high-level is simply just odd. The rest of the
    world recognizes C-family, Java, and Basic as high-level languages. I
    agree C is a lower-level language compared to C++, C#, Basic, and
    Python, but standing by itself, it still qualifies as high-level
    language.

    If I have to say it, Python is actually lower level than Basic. While
    Java is just below Python and C and C++ is just below Java. Why do I
    consider Basic the highest-level? Because it is the cleanest to scan
    (no confusing symbols, i.e. no curly braces, no confusing use of
    parens (Python uses (), [], and {}, VB only use ()[3]), and that is
    also the reasons of some of its warts.

    In what way C++ resembles an assembler? Have you ever programmed in
    assembly? How hard is it to create a simple program in assembly? And
    how hard is it to create a complex program in C++ (which AFAIK is used
    by hundreds of mega projects including CPython)?

    And have you ever used Basic at all?
    Some programmers would instantly frown upon Basic, simply because they
    don't know that Basic is "just another language". Apart from a syntax
    that is very different from most languages (absence of curly braces,
    the minimal use of non-alphabet characters in the syntax, minimal use
    of short keywords, opting for keywords that is (hopefully)
    understandable to non VBers[4]), and apart from the quality of the
    implementation, the language itself isn't a bad language. Sure they
    may have some warts, but I dare to say "Python have no warts".

    [3] In fact the new VB.NET 2008 adds a syntax that uses curly braces
    to VB, but it's only for a syntax sugar, in Python, the difference
    between the different kind of parentheses is significant.
    [4] The only significant exception to, a (hopefully) understandable
    keyword names to non-VBers, is probably the most important keyword,
    "Dim" for variable declaration.
    In VB, Me is extremely rarely used,
    I used to systematically use it - like I've always systematically used
    'this' in C++ ?and Java.
    And that is what reduces readability. A proficient VB/C/Java
    programmer
    There are quite a few proficient C/C++/Java programmers here. As far as
    I'm concerned, I would not pretend being one - I just have a good enough
    knowledge of C, Java and (alas) VB to be able to get up to speed in a
    reasonnable time frame.

    As a side note, the problem just doesn't exists in C, which has
    absolutely no support for OO.
    When I said C, it might mean C and C-family, so please stop
    misunderstanding me.

    As a side note, the conversation we're just having is a real life
    example of using the name C when it means C-family, your mindset
    instantly protest that C doesn't have objects, while my mindset says
    "C" can't have meant C as a language since I don't state C++ and C#
    too while I should have, and knowing the fact that C in C-family
    doesn't have objects would make it clear that it is an exception.

    I'm not saying my mindset is better than yours (it have its positives
    and negatives), in fact I apologize for getting you confused.
    would frown upon the extra, unneeded garbage as they
    thought it was clear already that the variable refers to a class-level
    variable.
    In C++, the canonical way to make this "clear" is to use the m_name
    convention. There must be some reason C++ programmers feel a need for
    this "extra, unneeded garbage" ?-)
    In some cases, an extremely complex class that can't be fragmented any
    further, the m_ convention is surely useful, but in most cases you
    could skip them out. And the canonical way to make this "clear" is not
    the m_ convention, it's the name itself. A well-designed class would
    choose names that is recognizable instantly from the name itself, even
    without the pseudo-name appended to it (or prepended).

    btw you must have been memorizing names braindeadly, because the only
    way you could stumble on that is by memorizing names braindeadly.
    Names shouldn't be memorized, it should be inferred and memorized. For
    example, when you met a variable name firstname and lastname inside a
    class called Person, you'd immediately realize that it is Class Level
    variable because you know that the function you're currently working
    on use the name initialfirstname and initiallastname.
    It is a different story if, like Python, the use of self is
    enforced by the language, the self wouldn't be viewed as extra
    unnecessary garbage.
    in Python, self is all
    over the place. Well, there is positive and negative to both sides,
    convenience in VB, and flexibility in Python.
    As far as I'm concerned, there's *no* positive point in implicit object
    reference, and there has never been (and before some paranoid nutcase
    around accuse me of overzealous biggotry : I already held this very same
    opinion years before I discovered Python).
    There is one major positive point: convenience and shorter code.
    (isn't that two?)
    These are not rated as "positive" in my book. That's perhaps why Python
    is so far MFL ?
    Not in _your_ book. Different languages have been devised throughout
    the world to solve various problems, some of which are convenience in
    using the language itself.
    As I've pointed out, there is little harm in class-level variable's
    implicit reference.
    Have some working experience on any non-trivial C++ project ?
    No (you could say I'm a student so I've never "worked"[1]). But I've
    done some medium-sized projects in other languages.

    [1] If you understand the irony, you'd realized I was deliberately
    misunderstanding you
    Compare the following codes:
    VB.NET:
    Public Class A
    ? ? Dim var
    ? ? Public Function aFunction()
    ? ? ? ? return var
    Add three levels of inheritence and a couple globals and you'll find out
    that readability count !-)
    It's the mental model that have to be adapted here, if the current
    class is inheriting from another class, you've got to think it as
    names from parent class as it is a native names, so you don't actually
    need to know where the variable comes from
    In C++ (and VB IIRC), it might as well be a global So sorry but yes, I
    have to know where it comes from.
    How many times would you use globals, it is a Bad Thing(tm) to use
    globals in the first case. In some exceptional cases globals might be
    unavoidable, but it is trivial to work out that you have to reduce the
    amount of globals to a minimum, in almost any cases to a number you
    can use a hand to count with. And applying the hacks mentioned, why
    don't you use the m_ convention for globals, and retains the
    convenience of m_-free variables in your class variable. You use class
    variable much more often than globals, and in most projects class-
    level variable is used just as often as local-variable.
    since knowing where it
    comes from is breaking the encapsulation
    Nope, it's knowing what you're doing and how the piece of software at
    hand is working. And FWIW, while data hiding is one possible mean of
    encapsulation, it's by no way a synonym for encapsulation.
    I agree that knowing an underlying class's implementation is useful
    (in fact, very useful) but what I'm talking is about should-ness, we
    shouldn't _need_ to know the underlying implementation, but if we know
    it, it's fine and it's great, since you can do tricks that you
    couldn't do otherwise (at your own risks).

    No it's not synonym, but one way of encapsulation.
    (which, in Python is very
    weakly implemented, which favors flexibility in many cases[1]).
    [1] In Python, it is impossible to create a completely private
    variable, which is the reason why the mental model of these other
    languages doesn't fit Python.
    Never heard about the infamous '#define private public' hack in C++ ?
    And don't worry, there are also ways to get at so called 'private' vars
    in Java.
    No, but it's violating the language's rule. Python OTOH, provides
    formal ways to got to private vars.
    In any non-trivial piece of C++ code, and unless the author either used
    the explicit 'this' reference or the 'm_xxx' naming convention, you'll
    have hard time figuring out where a given name comes from when browsing
    a function's code.
    If you're used to the implicit naming scheme it's easy to know where a
    variable came from, if not the current scope, it's the class' scope
    You forgot the global scope.
    How many global variables do you have in your projects on average? If
    you always have a pageful list of globals in your projects, then you
    should consider unlearning and relearning the basic programming
    concepts. It's easy to keep track of globals, as you shouldn't have a
    lot of them even in a huge project.
    As a final note:
    I don't think implicit class reference is superior to explicit class
    reference, neither
    ...
    I'm sure you don't believe it since I'm talking on implicit's side,
    but that's the fact, I just pointed you out that implicits do have its
    positive side (even if you don't consider them positive in _your_
    book) but that doesn't meant I believe it is better than the other.

    To clear things up:
    As a final note:
    I don't think implicit class reference is superior to explicit class
    reference, but I don't think the vice versa is true either.

    I consider they have their own positive and negative sides and
    different languages have different "better" definition, for Python it
    is explicit, for C/Java/Basic it's implicit.
  • Bjoern Schliessmann at Jan 20, 2008 at 11:54 pm
    (messed up references?)

    Lie wrote:
    Please again, stop taking letters to the words
    Please don't mix up followups.

    Regards,


    Bj?rn

    --
    BOFH excuse #11:

    magnetic interference from money/credit cards
  • Bruno Desthuilliers at Jan 21, 2008 at 12:48 pm

    Lie a ?crit :
    On Jan 16, 9:23 pm, Bjoern Schliessmann <usenet-
    mail-0306.20.chr0n... at spamgourmet.com> wrote:
    Lie wrote:
    42.desthuilli... at wtf.websiteburo.oops.com> wrote:
    I used to systematically use it - like I've always systematically
    used 'this' in C++ and Java.
    And that is what reduces readability.
    IMHO not, IOPHO not. This is the nth time (n >> 1) this discussion
    comes up here. If I have learned one thing from those very lengthy
    discussions, it's that Python's "self" handling is not going to
    change.
    And ah... yes, I don't wish it go away either. In VB, excessive Me
    reduces readability, but in Python it doesn't.
    A proficient VB/C/Java programmer would frown upon the extra,
    unneeded garbage as they thought it was clear already that the
    variable refers to a class-level variable.
    C programmers surely have no opinion concerning C because it has no
    native classes.
    C-family, ok?
    Well... I'm not sure what "C-family" means, but to me it would consist
    in C, C++, Objective C, and D.
    Please stop taking my words to its letters.
    So we're supposed to actually guess what you really mean ???
    Personally, I've seen many C++ programs with complex class designs
    where it definitely helps to consistently use "this->". I cannot
    remember all local (and global) variables in bigger methods.
    In that case, you have the _option_ to do it.
    Make no sens when maintaining code wrote by someone that didn't use this
    'option'.

    (snip)
    it's the first argument of the function - which usually happens to be
    the current instance when the function is used as a method.
    And that's the point, self (or anything you name it) is almost always
    the current instance
    # this is a plain function. In this function,
    # 'obj' can be whatever that happens to have a (numeric)
    # 'stuff' attribute
    def func(obj, arg):
    return (obj.stuff + arg) / 2.0

    # this is a class with an instance attribute 'stuff'
    class Foo(object):
    def __init__(self, bar):
    self.stuff = bar + 42

    # this is another (mostly unrelated) class
    # with a class attribute 'stuff'
    class Bar(object):
    stuff = 42

    # this is a dummy container class:
    class Dummy(object): pass

    # now let's play:
    import new

    d = Dummy()
    d.stuff = 84
    print func(d, 1)

    d.baaz = new.instancemethod(func, d, type(d))
    print d.baaz(2)

    f = Foo(33)
    print func(f, 3)
    Foo.baaz = func
    f.baaz(4)

    print func(Bar, 5)
    Bar.baaz = classmethod(func)
    Bar.baaz(6)
    and that makes it functionally the same as Me and
    this in VB and Java.
    Depends on the context, cf above !-)
    Please again, stop taking letters to the words, I don't meant them to
    be exactly the same, rather the same would meant that they generally
    can be considered equal,
    If you still think that way after having read the above code, then I
    can't help. We obviously don't share the same mental model here.
    exceptions exists of course. And btw, I don't
    understand what you meant by your example, they seemed to be a
    completely OK program for me,
    Indeed it's ok (even if totally useless by itself). The point is that
    'self' (or whatever you name it) is just and only the first argument of
    a function, period.
    even though it's a bit confusing to
    follow[2].
    Nothing in it should be confusing to anyone having a decent knowledge of
    Python's object model IMHO.
    [2] btw, the reason it's a bit confusing to follow is one of my
    points: It is a Bad Thing(tm) to use the same name for different
    variables
    Where do I "use the same name for different variables" here ?
    even in a language like Python that enforce explicit naming
    of classes
    Python doesn't "enforce" explicit name of classes - IIRC, there are ways
    to instanciate anonymous class objects. But I definitively don't see how
    this relate to this discussion.

    Yes, I know, "please guess what I mean" !-) but sorry, there's no sens
    discussing a technical point without using accurate and appropriate
    technical naming of technical concepts invlved.
    Most other languages
    1) automatically assign the containing class' object
    s/containing class' object/current instance/
    in a keyword
    (Java: this, VB: Me) behind the screen,
    That's not very far from what a Python method object does -
    automatically assign the current instance to something. The difference
    is that Python uses functions to implement methods (instead of having
    two distinct contructs), so the only reliable way to "inject" the
    reference to the current instance is to pass it as an argument to the
    function (instead of making it pop from pure air).
    It isn't very far, but Python makes it obvious about the assignment
    (not behind the screen).
    Exactly. And given both the simplicity of the solution and what it let
    you do, that's a *very* GoodThing(tm) IMHO.
    I agree, it's a Good Thing but it doesn't make the point less pointy,
    the difference between Me/this and self is just the explicit
    assignment. Other things that is possible because of the explicit
    assignment is just a "coincidence" of design choice.
    Are you sure ? As far as I'm concerned, I think that the design choice
    somehow results from what it makes possible.

    (snip pointless discussion wrt/ # of attributes)
    And it is always a Bad Thing(tm) to use the same name for two
    variable in the class and in function (which is the main and only
    source of possible ambiguity) in ANY language, even in Python.
    Ho, yes.... Like, this would be bad ?

    class Person(object):
    def __init__(self, firstname, lastname, birthdate, gender):
    self.firstname = firstname
    self.lastname = lastname
    self.birthdate = birthdate
    self.gender = gender

    C'mon, be serious. It's often hard enough to come with sensible names,
    why would one have to find synonyms too ? Try to come with something
    more readable than the above, and let us know. Seriously, this braindead
    rule about "not using the same name for an attribute and a local var"
    obviously comes from languages where the "this" ref is optional, and
    FWIW it's obviously the wrong solution to a real problem (the good
    solution being, of course, to use the fully qualified name for
    attributes so there's no possible ambiguity).
    The code fragment you've given way above (about the Foo, Bar, bazz,
    and func) also suffers from the bad habits of using the same name for
    different variables.
    Where ? And how does this answer the question above ?

    And it's not a "braindead" rule
    The way you express it, and as far as i'm concerned, it is, definitively.
    The example you've given IS the most readable form since the function
    is _simple_, consider a function that have complex codes, possibly
    calculations instead of simply assigning initial values I'm sure you'd
    slip up between the self.* variables and the * variables once or
    twice,
    *you* would perhaps have this problem. And you would indeed have this
    problem in Java or C++. In Python, this problem just don't exist.
    possibly becoming the source of hard-to-find bugs.
    Consistant and intelligible naming is quite another problem. And it's
    too much dependant on the context, language, domain and whatnot for any
    rule like your one above to be universally applyable.

    And in languages that doesn't enforce explicit naming of classes,
    I still don't understand how all this relates to the naming of class
    objects ?

    Oops, sorry: you meant "in languages that has implicit instance
    reference available in methods" ? Python doesn't have it, so any rule
    deriving from this "feature" is out of scope here.
    when
    there is the two or more same names, the one with the smallest scope
    is picked, so in _simple_ functions, the trick of using full qualified
    names and overloaded local names is still possible and feasible. In
    complex functions, the trick fails even in Python, because even if
    Python and our full-concentration-brain is aware of the difference
    between self.* and *, our spreaded-concentration-brain that is
    scanning the code for the source of bugs might get stumbled on the
    confusing use of self.* and *.
    Here again, *you* may have this problem. I don't, since I always used
    explicit instance reference.
    Anyway, I actually know 3 languages (4 if C# works the same) that has
    this implicit 'this' (or whatever the name) 'feature', and at least 5
    that don't. So I'm not sure that the "most other languages" qualifier
    really applies to point 2 !-)
    What's this 5 languages?
    Smalltalk, Python, PHP, javascript, Ruby. I don't remember how Scheme,
    CLOS and OCaml handle the case.
    Among all them, only Javascript is considerably mainstream.
    Is that a joke ? PHP is probably the most used language for web apps
    (server side of course). And Python is certainly not an obscure unknown
    geek-only language no more. But anyway: you were talking about "most
    other languages" - not "most mainstream languages".
    Are they a mainstream, high-level languages
    or lesser known, low-level languages? C-family, Java, and Basic are
    the Big Three of high-level programming language.
    None of C, C++, Java nor Basic qualify as "hi-level". C is the lowest
    possible level above assembly, C++ is often refered to as an "object
    oriented assembler", Java is way too static, crippled, verbose an
    unexpressive to qualify as "hi-level" (even if it suffers from some
    problems usually associated with higher level languages). I won't even
    comment on basic (is that really a language at all ?).
    Your criteria on being high-level is simply just odd.
    My criteria on being hi-level seems quite common: automatic memory
    management, portability, "rich" builtin data types, functions as first
    class citizens, lexical closures, strong introspection features, strong
    metaprogramming support, etc...
    The rest of the
    world recognizes C-family, Java, and Basic as high-level languages.
    C was "hi-level" wrt/ assembler, indeed. And Java is "hi-level" wrt/
    C++. Ho, and _please_ don't get me started on basic !-)
    If I have to say it, Python is actually lower level than Basic.
    No comment.
    While
    Java is just below Python and C and C++ is just below Java. Why do I
    consider Basic the highest-level? Because it is the cleanest to scan
    (no confusing symbols, i.e. no curly braces, no confusing use of
    parens (Python uses (), [], and {}, VB only use ()[3]),
    Basic != VB. There are quite a few other basics here.

    Now if you choose this criteria, you may want to learn some Lisp dialect.
    In what way C++ resembles an assembler?
    C++ is some OO stuff bolted on a very close-to-the-metal language itself
    designed to write operating systems, drivers and other low-level stuff.
    Have you ever programmed in
    assembly? I did.
    How hard is it to create a simple program in assembly? And
    how hard is it to create a complex program in C++
    Roughly the same, thanks to scoping rules, dependencies hell, lack of
    automatic memory management and overcomplex features.
    (which AFAIK is used
    by hundreds of mega projects including CPython)?
    CPython - as the name implies - is written in C.
    And have you ever used Basic at all?
    I did. And not only VB.
    Some programmers would instantly frown upon Basic, simply because they
    don't know that Basic is "just another language".
    I've used at least four different variants of Basic.
    In VB, Me is extremely rarely used,
    I used to systematically use it - like I've always systematically used
    'this' in C++ and Java.
    And that is what reduces readability. A proficient VB/C/Java
    programmer
    There are quite a few proficient C/C++/Java programmers here. As far as
    I'm concerned, I would not pretend being one - I just have a good enough
    knowledge of C, Java and (alas) VB to be able to get up to speed in a
    reasonnable time frame.

    As a side note, the problem just doesn't exists in C, which has
    absolutely no support for OO.
    When I said C, it might mean C and C-family,
    When you say "C", it means "C" to everyone reading you.
    so please stop
    misunderstanding me.
    Please learn to express yourself clearly. If you say "X" when you mean
    "Y", *you* are the one responsible for misunderstandings. This is human
    communication 101 skill.

    (snip)
    I'm not saying my mindset is better than yours (it have its positives
    and negatives), in fact I apologize for getting you confused.
    My "mindset", as you say, is the one you'll find in each and every
    technical communication. You can't discuss technical points without a
    clear, unambiguous naming of technical concepts. And when a community
    exists, it usually has it's own technical idiom, whether highly specific
    (ie : "member variables" in C++, "attributes" in Python), or more
    general (ie: C is not the same thing as C++, whenever language you're
    using).
    would frown upon the extra, unneeded garbage as they
    thought it was clear already that the variable refers to a class-level
    variable.
    In C++, the canonical way to make this "clear" is to use the m_name
    convention. There must be some reason C++ programmers feel a need for
    this "extra, unneeded garbage" ?-)
    In some cases, an extremely complex class that can't be fragmented any
    further, the m_ convention is surely useful, but in most cases you
    could skip them out.
    You "could" skip this convention, but it's really considered bad
    practice by quite a lot of C++ programmers.
    And the canonical way to make this "clear" is not
    the m_ convention, it's the name itself. A well-designed class would
    choose names that is recognizable instantly from the name itself, even
    without the pseudo-name appended to it (or prepended).
    I await for your exemples.
    btw you must have been memorizing names braindeadly, because the only
    way you could stumble on that is by memorizing names braindeadly.
    Names shouldn't be memorized, it should be inferred and memorized. For
    example, when you met a variable name firstname and lastname inside a
    class called Person, you'd immediately realize that it is Class Level
    variable because you know that the function you're currently working
    on use the name initialfirstname and initiallastname.
    Fine, I now have four names to handle, each of them being possibly an
    argument, a local variable, a member variable or a global variable. Great.

    Sorry but I won't buy this.

    (snip)
    As I've pointed out, there is little harm in class-level variable's
    implicit reference.
    Have some working experience on any non-trivial C++ project ?
    No
    I would have been surprised if you had answer otherwise.
    (you could say I'm a student so I've never "worked"[1]). But I've
    done some medium-sized projects in other languages.

    [1] If you understand the irony, you'd realized I was deliberately
    misunderstanding you
    Not sure.
    Compare the following codes:
    VB.NET:
    Public Class A
    Dim var
    Public Function aFunction()
    return var
    Add three levels of inheritence and a couple globals and you'll find out
    that readability count !-)
    It's the mental model that have to be adapted here, if the current
    class is inheriting from another class, you've got to think it as
    names from parent class as it is a native names, so you don't actually
    need to know where the variable comes from
    In C++ (and VB IIRC), it might as well be a global So sorry but yes, I
    have to know where it comes from.
    How many times would you use globals, it is a Bad Thing(tm) to use
    globals in the first case.
    It is, most of the time, indeed.

    The problem is that you rarely start a project from scratch - most of
    the time, you have to work on legacy code. And you really seldom have
    the possibility to do a major rewrite to fix all warts.
    In some exceptional cases globals might be
    unavoidable, but it is trivial to work out that you have to reduce the
    amount of globals to a minimum, in almost any cases to a number you
    can use a hand to count with.
    That very nice, from a theoretical POV. That's alas just not how it
    works in real life.
    And applying the hacks mentioned, why
    don't you use the m_ convention for globals, and retains the
    convenience of m_-free variables in your class variable. You use class
    variable much more often than globals, and in most projects class-
    level variable is used just as often as local-variable.
    The problem is not what *I* (would) do, but how is the existing code.
    since knowing where it
    comes from is breaking the encapsulation
    Nope, it's knowing what you're doing and how the piece of software at
    hand is working. And FWIW, while data hiding is one possible mean of
    encapsulation, it's by no way a synonym for encapsulation.
    I agree that knowing an underlying class's implementation is useful
    (in fact, very useful) but what I'm talking is about should-ness,
    we
    shouldn't _need_ to know the underlying implementation,
    How can you hope to extend a class without _any_ knowledge of it's
    implementation ?

    (snip)
    (which, in Python is very
    weakly implemented, which favors flexibility in many cases[1]).
    [1] In Python, it is impossible to create a completely private
    variable, which is the reason why the mental model of these other
    languages doesn't fit Python.
    Never heard about the infamous '#define private public' hack in C++ ?
    And don't worry, there are also ways to get at so called 'private' vars
    in Java.
    No, but it's violating the language's rule.
    Nope. It's just making use of some part of the language's rules.
    Python OTOH, provides
    formal ways to got to private vars.
    Python doesn't have "private vars" at all.
    In any non-trivial piece of C++ code, and unless the author either used
    the explicit 'this' reference or the 'm_xxx' naming convention, you'll
    have hard time figuring out where a given name comes from when browsing
    a function's code.
    If you're used to the implicit naming scheme it's easy to know where a
    variable came from, if not the current scope, it's the class' scope
    You forgot the global scope.
    How many global variables do you have in your projects on average? If
    you always have a pageful list of globals in your projects, then you
    should consider unlearning and relearning the basic programming
    concepts.
    I'll come to you when I'll need more training, don't worry.
    It's easy to keep track of globals, as you shouldn't have a
    lot of them even in a huge project.
    Can't you understand that starting a new project afresh is *not* the
    common case ?
    As a final note:
    I don't think implicit class reference is superior to explicit class
    reference, neither
    ...
    I'm sure you don't believe it since I'm talking on implicit's side,
    but that's the fact, I just pointed you out that implicits do have its
    positive side (even if you don't consider them positive in _your_
    book) but that doesn't meant I believe it is better than the other.

    To clear things up:
    As a final note:
    I don't think implicit class reference is superior to explicit class
    reference, but I don't think the vice versa is true either.
    Once again : what classes have to do with this ?

    Seriously, how can you hope to be taken seriously when you're obviously
    confusing such important concepts as instance and class ?
  • Lie at Jan 21, 2008 at 5:26 pm

    Please stop taking my words to its letters.
    So we're supposed to actually guess what you really mean ???
    That's what human does, otherwise you'll "Fail the Turing Test".
    Personally, I've seen many C++ programs with complex class designs
    where it definitely helps to consistently use "this->". I cannot
    remember all local (and global) variables in bigger methods.
    In that case, you have the _option_ to do it.
    Make no sens when maintaining code wrote by someone that didn't use this
    'option'.

    (snip)


    it's the first argument of the function - which usually happens to be
    the current instance when the function is used as a method.
    And that's the point, self (or anything you name it) is almost always
    the current instance
    # this is a plain function. In this function,
    # 'obj' can be whatever that happens to have a (numeric)
    # 'stuff' attribute
    def func(obj, arg):
    ? ?return (obj.stuff + arg) / 2.0
    # this is a class with an instance attribute 'stuff'
    class Foo(object):
    ? ? def __init__(self, bar):
    ? ? ? self.stuff = bar + 42
    # this is another (mostly unrelated) class
    # with a class attribute 'stuff'
    class Bar(object):
    ? ?stuff = 42
    # this is a dummy container class:
    class Dummy(object): pass
    # now let's play:
    import new
    d = Dummy()
    d.stuff = 84
    print func(d, 1)
    d.baaz = new.instancemethod(func, d, type(d))
    print d.baaz(2)
    f = Foo(33)
    print func(f, 3)
    Foo.baaz = func
    f.baaz(4)
    print func(Bar, 5)
    Bar.baaz = classmethod(func)
    Bar.baaz(6)
    ?and that makes it functionally the same as Me and
    this in VB and Java.
    Depends on the context, cf above !-)
    Please again, stop taking letters to the words, I don't meant them to
    be exactly the same, rather the same would meant that they generally
    can be considered equal,
    If you still think that way after having read the above code, then I
    can't help. We obviously don't share the same mental model here.
    I don't get what you're trying to meant, in that piece of code self is
    used in the regular way, in a regular context.
    exceptions exists of course. And btw, I don't
    understand what you meant by your example, they seemed to be a
    completely OK program for me,
    Indeed it's ok (even if totally useless by itself). The point is that
    'self' (or whatever you name it) is just and only the first argument of
    a function, period.
    And it is... but I still don't get what you meant
    even though it's a bit confusing to
    follow[2].
    Nothing in it should be confusing to anyone having a decent knowledge of
    Python's object model IMHO.
    [2] btw, the reason it's a bit confusing to follow is one of my
    points: It is a Bad Thing(tm) to use the same name for different
    variables
    Where do I "use the same name for different variables" here ?
    It's not confusing in the way of object model, but in the way that you
    used meaningless names in overloaded manner.
    even in a language like Python that enforce explicit naming
    of classes
    Python doesn't "enforce" explicit name of classes - IIRC, there are ways
    to instanciate anonymous class objects. But I definitively don't see how
    this relate to this discussion.
    We're not talking about anonymous class objects here, and I'm sure you
    actually understand what I meant by "naming the class" from previous
    discussions.
    Yes, I know, "please guess what I mean" !-) but sorry, there's no sens
    discussing a technical point without using accurate and appropriate
    technical naming of technical concepts invlved.
    Well, it's not my fault for being born as a non-native speaker of
    English, sometimes what I meant might goes a bit off from what I
    write. Anyway, human languages aren't designed to be fully
    unambiguous, so it is natural for human to provide a margin of errors
    when speaking to each other, well unless you're not a human...
    Most other languages
    1) automatically assign the containing class' object
    s/containing class' object/current instance/
    in a keyword
    (Java: this, VB: Me) behind the screen,
    That's not very far from what a Python method object does -
    automatically assign the current instance to something. The difference
    is that Python uses functions to implement methods (instead of having
    two distinct contructs), so the only reliable way to "inject" the
    reference to the current instance is to pass it as an argument to the
    function (instead of making it pop from pure air).
    It isn't very far, but Python makes it obvious about the assignment
    (not behind the screen).
    Exactly. And given both the simplicity of the solution and what it let
    you do, that's a *very* GoodThing(tm) IMHO.
    I agree, it's a Good Thing but it doesn't make the point less pointy,
    the difference between Me/this and self is just the explicit
    assignment. Other things that is possible because of the explicit
    assignment is just a "coincidence" of design choice.
    Are you sure ? As far as I'm concerned, I think that the design choice
    somehow results from what it makes possible.
    It's correct, IF you see it traversing from the past, when many design
    choice is being made for any possible features that is required. If
    you dumped the past for a while, it is just a "coincidence" of design
    choice.
    And it is always a Bad Thing(tm) to use the same name for two
    variable in the class and in function (which is the main and only
    source of possible ambiguity) in ANY language, even in Python.
    Ho, yes.... Like, this would be bad ?
    class Person(object):
    ? ?def __init__(self, firstname, lastname, birthdate, gender):
    ? ? ?self.firstname = firstname
    ? ? ?self.lastname = lastname
    ? ? ?self.birthdate = birthdate
    ? ? ?self.gender = gender
    C'mon, be serious. It's often hard enough to come with sensible names,
    why would one have to find synonyms too ? Try to come with something
    more readable than the above, and let us know. Seriously, this braindead
    rule about ?"not using the same name for an attribute and a local var"
    obviously comes from languages where the "this" ref is optional, and
    FWIW it's obviously the wrong solution to a real problem (the good
    solution being, of course, to use the fully qualified name for
    attributes so there's no possible ambiguity).
    The code fragment you've given way above (about the Foo, Bar, bazz,
    and func) also suffers from the bad habits of using the same name for
    different variables.
    Where ? And how does this answer the question above ?
    And it's not a "braindead" rule
    The way you express it, and as far as i'm concerned, it is, definitively.
    Perhaps I forgot to say that always might still have exceptions.
    The example you've given IS the most readable form since the function
    is _simple_, consider a function that have complex codes, possibly
    calculations instead of simply assigning initial values I'm sure you'd
    slip up between the self.* variables and the * variables once or
    twice,
    *you* would perhaps have this problem. And you would indeed have this
    problem in Java or C++. In Python, this problem just don't exist.
    No it exists in any language, the way to avoid it is by good class
    design.
    possibly becoming the source of hard-to-find bugs.
    Consistant and intelligible naming is quite another problem. And it's
    too much dependant on the context, language, domain and whatnot for any
    rule like your one above to be universally applyable.
    It is universally applicable, with some exceptions of course, such as
    in a field where there is no agreed naming convention yet.
    And in languages that doesn't enforce explicit naming of classes,
    I still don't understand how all this relates to the naming of class
    objects ?

    Oops, sorry: you meant "in languages that has implicit instance
    reference available in methods" ? Python doesn't have it, so any rule
    deriving from this "feature" is out of scope here.
    ?when
    there is the two or more same names, the one with the smallest scope
    is picked, so in _simple_ functions, the trick of using full qualified
    names and overloaded local names is still possible and feasible. In
    complex functions, the trick fails even in Python, because even if
    Python and our full-concentration-brain is aware of the difference
    between self.* and *, our spreaded-concentration-brain that is
    scanning the code for the source of bugs might get stumbled on the
    confusing use of self.* and *.
    Here again, *you* may have this problem. I don't, since I always used
    explicit instance reference.
    I don't have that much of a problem, I only pointed out that it is
    possible to miss the names overloading in quick scanning. The reason
    why you never get stumbled is possibly because your brain memorizes
    the names and doesn't even understand what a name actually meant. This
    halved the reason of spending some time to find a meaningful name.
    With your brainset, it is just possible to create a program fully with
    names like foo and bar and never get stumbled. In this case, it
    excels, but it's a poor man's way of trying to be smart.
    Anyway, I actually know 3 languages (4 if C# works the same) that has
    this implicit 'this' (or whatever the name) 'feature', and at least 5
    that don't. So I'm not sure that the "most other languages" qualifier
    really applies to point 2 !-)
    What's this 5 languages?
    Smalltalk, Python, PHP, javascript, Ruby. I don't remember how Scheme,
    CLOS and OCaml handle the case.
    Among all them, only Javascript is considerably mainstream.
    Is that a joke ? PHP is probably the most used language for web apps
    (server side of course). And Python is certainly not an obscure unknown
    geek-only language no more. But anyway: you were talking about "most
    other languages" - not "most mainstream languages".
    Yes, I'm aware that Python and PHP indeed have larger user base than
    perhaps smalltalk and Ruby, but nevertheless they're middle sized.
    What's I'm talking about mainstream is large as in large, not medium.
    PHP's domain has lots of competition, ASP, JSP, CGI, etc and this
    market is very fragmented, even though server-side scripting plays
    important role in the Internet, the role of each language is lessened
    because of the fragmentation making none of them mainstream enough.
    Python is shaded by Java in the market for ultra portable (VM)
    language. And I'm not talking about Smalltalk and Ruby here.
    Are they a mainstream, high-level languages
    or lesser known, low-level languages? C-family, Java, and Basic are
    the Big Three of high-level programming language.
    None of C, C++, Java nor Basic qualify as "hi-level". C is the lowest
    possible level above assembly, C++ is often refered to as an "object
    oriented assembler", Java is way too static, crippled, verbose an
    unexpressive to qualify as "hi-level" (even if it suffers from some
    problems usually associated with higher level languages). I won't even
    comment on basic (is that really a language at all ?).
    Your criteria on being high-level is simply just odd.

    My criteria on being hi-level seems quite common: automatic memory
    management, portability, "rich" builtin data types, functions as first
    class citizens, lexical closures, strong introspection features, strong
    metaprogramming support, etc...
    We're talking language-wise here, not the implementation, and those
    criteria are for implementations. It is the case where we blindfold
    our eyes against "the things behind" and see only the language from
    the front. Yeah, perhaps "the things behind" would have some effect to
    the front side, like it is possible to create C with automatic memory
    management with little change in the language itself, it's possible to
    have more built-in datatypes than the standard set without major
    change in language itself. These are the criteria for language-wise
    comparison.
    The rest of the
    world recognizes C-family, Java, and Basic as high-level languages.
    C was "hi-level" wrt/ assembler, indeed. And Java is "hi-level" wrt/
    C++. Ho, and _please_ don't get me started on basic !-)
    And the world is content with that. C is probably the lowest shade a
    high level language could be, but it is still a high-level.
    If I have to say it, Python is actually lower level than Basic.
    Language-wise, indeed it is. Implementation-wise, Python might be
    higher than Basic.
    While
    Java is just below Python and C and C++ is just below Java. Why do I
    consider Basic the highest-level? Because it is the cleanest to scan
    (no confusing symbols, i.e. no curly braces, no confusing use of
    parens (Python uses (), [], and {}, VB only use ()[3]),
    Basic != VB. There are quite a few other basics here.
    I'm aware of that, but VB is the one with the largest user base, and I
    think it could be used to represent the language as a whole. And
    VB.NET is one with possibly the highest shade of level among other
    Basics.
    Now if you choose this criteria, you may want to learn some Lisp dialect.
    In what way C++ resembles an assembler?
    C++ is some OO stuff bolted on a very close-to-the-metal language itself
    designed to write operating systems, drivers and other low-level stuff.
    In what way is C++ close to the metal? It's very far actually, C-
    family don't have a one-to-one relationship with assembly or plain
    executable binary.
    Have you ever programmed in
    assembly?
    I did.
    And surely you'd realize that the level of C and assembly is very far,
    perhaps the furthest leap in programming language level.
    How hard is it to create a simple program in assembly? And
    how hard is it to create a complex program in C++
    Roughly the same, thanks to scoping rules, dependencies hell, lack of
    automatic memory management and overcomplex features.
    By saying that you've revealed that you missed my point too far. There
    is no point to continue talking about A when you're talking about B.
    (which AFAIK is used
    by hundreds of mega projects including CPython)?
    CPython - as the name implies - is written in C.
    And by saying that I'm sure you agree that even C, which is lower
    level than C++ is high-level enough to be used in large projects like
    CPython. I'm interested in seeing Python implemented in pure assembly,
    perhaps asmPython?
    And have you ever used Basic at all?
    I did. And not only VB.
    Some programmers would instantly frown upon Basic, simply because they
    don't know that Basic is "just another language".
    I've used at least four different variants of Basic.
    Then with such experience in Basic you should realize that Basic isn't
    much off from other languages.
    In VB, Me is extremely rarely used,
    I used to systematically use it - like I've always systematically used
    'this' in C++ and Java.
    And that is what reduces readability. A proficient VB/C/Java
    programmer
    There are quite a few proficient C/C++/Java programmers here. As far as
    I'm concerned, I would not pretend being one - I just have a good enough
    knowledge of C, Java and (alas) VB to be able to get up to speed in a
    reasonnable time frame.
    As a side note, the problem just doesn't exists in C, which has
    absolutely no support for OO.
    When I said C, it might mean C and C-family,
    When you say "C", it means "C" to everyone reading you.
    Depending on the context, it's easy to rule out which means what.
    so please stop
    misunderstanding me.
    Please learn to express yourself clearly. If you say "X" when you mean
    "Y", *you* are the one responsible for misunderstandings. This is human
    communication 101 skill.
    Even computers are designed to tolerate errors in data transfer, then
    human is less intelligent than computers you say?
    would frown upon the extra, unneeded garbage as they
    thought it was clear already that the variable refers to a class-level
    variable.
    In C++, the canonical way to make this "clear" is to use the m_name
    convention. There must be some reason C++ programmers feel a need for
    this "extra, unneeded garbage" ?-)
    In some cases, an extremely complex class that can't be fragmented any
    further, the m_ convention is surely useful, but in most cases you
    could skip them out.
    You "could" skip this convention, but it's really considered bad
    practice by quite a lot of C++ programmers.
    Bad, because a lot of them are already accustomed to it and it have
    become a de facto "rules".
    And the canonical way to make this "clear" is not
    the m_ convention, it's the name itself. A well-designed class would
    choose names that is recognizable instantly from the name itself, even
    without the pseudo-name appended to it (or prepended).
    I await for your exemples.
    btw you must have been memorizing names braindeadly, because the only
    way you could stumble on that is by memorizing names braindeadly.
    Names shouldn't be memorized, it should be inferred and memorized. For
    example, when you met a variable name firstname and lastname inside a
    class called Person, you'd immediately realize that it is Class Level
    variable because you know that the function you're currently working
    on use the name initialfirstname and initiallastname.
    Fine, I now have four names to handle, each of them being possibly an
    argument, a local variable, a member variable or a global variable. Great.

    Sorry but I won't buy this.
    THAT'S the point. You are unable to infer that the name
    initialfirstname and initiallastname is a local variable, since it is
    quite impossible for something initial to be a member variable or
    global. If it is a global, it shouldn't be named initial, perhaps
    default, if it is member variable, it should be plain vanilla
    firstname and lastname. This is called inferring scope from name.
    As I've pointed out, there is little harm in class-level variable's
    implicit reference.
    Have some working experience on any non-trivial C++ project ?
    No
    I would have been surprised if you had answer otherwise.
    (you could say I'm a student so I've never "worked"[1]). But I've
    done some medium-sized projects in other languages.
    [1] If you understand the irony, you'd realized I was deliberately
    misunderstanding you
    Not sure.
    Don't cut my words apart, it's meant to be together or it lose its
    sense of humor.
    Compare the following codes:
    VB.NET:
    Public Class A
    Dim var
    Public Function aFunction()
    return var
    Add three levels of inheritence and a couple globals and you'll find out
    that readability count !-)
    It's the mental model that have to be adapted here, if the current
    class is inheriting from another class, you've got to think it as
    names from parent class as it is a native names, so you don't actually
    need to know where the variable comes from
    In C++ (and VB IIRC), it might as well be a global So sorry but yes, I
    have to know where it comes from.
    How many times would you use globals, it is a Bad Thing(tm) to use
    globals in the first case.
    It is, most of the time, indeed.

    The problem is that you rarely start a project from scratch - most of
    the time, you have to work on legacy code. And you really seldom have
    the possibility to do a major rewrite to fix all warts.
    But it is always possible to reduce the most critical of all of them.
    In some exceptional cases globals might be
    unavoidable, but it is trivial to work out that you have to reduce the
    amount of globals to a minimum, in almost any cases to a number you
    can use a hand to count with.
    That very nice, from a theoretical POV. That's alas just not how it
    works in real life.
    A bit utopic, I agree, but it's always possible.
    And applying the hacks mentioned, why
    don't you use the m_ convention for globals, and retains the
    convenience of m_-free variables in your class variable. You use class
    variable much more often than globals, and in most projects class-
    level variable is used just as often as local-variable.
    The problem is not what *I* (would) do, but how is the existing code.
    since knowing where it
    comes from is breaking the encapsulation
    Nope, it's knowing what you're doing and how the piece of software at
    hand is working. And FWIW, while data hiding is one possible mean of
    encapsulation, it's by no way a synonym for encapsulation.
    I agree that knowing an underlying class's implementation is useful
    (in fact, very useful) but what I'm talking is about should-ness,
    we
    shouldn't _need_ to know the underlying implementation,
    How can you hope to extend a class without _any_ knowledge of it's
    implementation ?
    By knowing its interface is usually enough to extend a class.
    (USUALLY!)
    (which, in Python is very
    weakly implemented, which favors flexibility in many cases[1]).
    [1] In Python, it is impossible to create a completely private
    variable, which is the reason why the mental model of these other
    languages doesn't fit Python.
    Never heard about the infamous '#define private public' hack in C++ ?
    And don't worry, there are also ways to get at so called 'private' vars
    in Java.
    No, but it's violating the language's rule.
    Nope. It's just making use of some part of the language's rules.
    No, its a hack that should be illegal, a kind of abuse of rules.
    Python OTOH, provides
    formal ways to got to private vars.
    Python doesn't have "private vars" at all.
    THAT'S the point. Even __vars and _vars that are supposed to be
    (semantic-wise) the private variable of Python is accessible from
    outside while still using a formal ways of accessing it (instead of a
    hack)
    It's easy to keep track of globals, as you shouldn't have a
    lot of them even in a huge project.
    Can't you understand that starting a new project afresh is *not* the
    common case ?
    But I'm sure even an old, dirty codes wouldn't usually have as much
    global as a twenty pages listing of globals. If they do, then just
    quit that job.
    As a final note:
    I don't think implicit class reference is superior to explicit class
    reference, neither
    ...
    I'm sure you don't believe it since I'm talking on implicit's side,
    but that's the fact, I just pointed you out that implicits do have its
    positive side (even if you don't consider them positive in _your_
    book) but that doesn't meant I believe it is better than the other.
    To clear things up:
    As a final note:
    I don't think implicit class reference is superior to explicit class
    reference, but I don't think the vice versa is true either.
    Once again : what classes have to do with this ?

    Seriously, how can you hope to be taken seriously when you're obviously
    confusing such important concepts as instance and class ?
    I'm struggling with English as of now, so please make me more confused
    by having to choose the most proper terms, when it is easy to rule out
    what I meant.

    This is going to be my last two cents on this topic. I'm tired of this
    pointless discussion. We could like a language even though we have
    principal differences on how to see the language and how to think
    about it.
  • Francesco Guerrieri at Jan 6, 2008 at 9:48 pm

    On Jan 5, 2008 11:31 AM, wrote:

    import tok

    class code:
    def __init__( self, start, stop ):
    startLoc = start
    stopLoc = stop

    class token(code):
    pass
    Apart from the missing self, remember that the __init__(...) of the
    base classes is not automatically called, unless you do it explicitly
    or you do not provide one in the derived class.
    So for instance you could have something like

    class token(code):
    def __init__(self, ...):
    # do the token specific initialization here
    ....
    # Now init the base class
    code.__init__(self, ....)

    Or, better, you could use super
    if you were using new-style classes (which you are not...), like in
    the following:

    class token(code):
    def __init__(self, ...):
    # do your initialization here
    super(token, self).__init__(....)

    which is much better suited to allow multiple inheritance (there has
    been a discussion in these days about the MRO, look for a paper by
    Michele Simionato).
    Quoting Alex Martelli in Python in a nutshell (page 97):
    "If you get into the habit of always coding superclass calls with
    super, your classes will fit smoothly even in complicated inheritance
    structures. There are no ill effects whatsoever if the inheritance
    structure instead turns out to be simple, as long, of course, as
    you're only using the new-style object model, as I recommend".

    bye,
    Francesco

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedJan 5, '08 at 10:31a
activeJan 21, '08 at 5:26p
posts19
users10
websitepython.org

People

Translate

site design / logo © 2022 Grokbase