By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,743 Members | 1,122 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,743 IT Pros & Developers. It's quick & easy.

Basic inheritance question

P: n/a
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.)
Jan 5 '08 #1
Share this Question
Share on Google+
14 Replies


P: n/a
-On [20080105 11:36], Ma************@gmail.com (Ma************@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...
Jan 5 '08 #2

P: n/a
On Jan 5, 10:31*am, MartinRineh...@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
Jan 5 '08 #3

P: n/a


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.
Jan 5 '08 #4

P: n/a
Ma************@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,
Bjrn

--
BOFH excuse #294:

PCMCIA slave driver

Jan 5 '08 #5

P: n/a
Lie
On Jan 5, 5:40*pm, MartinRineh...@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.
Jan 5 '08 #6

P: n/a
Lie a crit :
On Jan 5, 5:40 pm, MartinRineh...@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 ?
Jan 6 '08 #7

P: n/a
On Jan 5, 2008 11:31 AM, <Ma************@gmail.comwrote:
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
Jan 6 '08 #8

P: n/a
On Jan 5, 4:53 am, Bjoern Schliessmann <usenet-
mail-0306.20.chr0n...@spamgourmet.comwrote:
MartinRineh...@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.
Jan 7 '08 #9

P: n/a
Lie
On Jan 7, 2:46*am, Bruno Desthuilliers
<bdesth.quelquech...@free.quelquepart.frwrote:
Lie a crit :
On Jan 5, 5:40 pm, MartinRineh...@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
Jan 14 '08 #10

P: n/a
Lie a crit :
On Jan 7, 2:46 am, Bruno Desthuilliers
<bdesth.quelquech...@free.quelquepart.frwrote:
>Lie a crit :
>>On Jan 5, 5:40 pm, MartinRineh...@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.

Jan 15 '08 #11

P: n/a
Lie
On Jan 15, 9:00*pm, Bruno Desthuilliers <bruno.
42.desthuilli...@wtf.websiteburo.oops.comwrote:
Lie a crit :
On Jan 7, 2:46 am, Bruno Desthuilliers
<bdesth.quelquech...@free.quelquepart.frwrote:
Lie a crit :
>On Jan 5, 5:40 pm, MartinRineh...@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).
Jan 16 '08 #12

P: n/a
Lie wrote:
42.desthuilli...@wtf.websiteburo.oops.comwrote:
>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,
Bjrn

--
BOFH excuse #109:

The electricity substation in the car park blew up.

Jan 16 '08 #13

P: n/a
Lie a crit :
On Jan 15, 9:00 pm, Bruno Desthuilliers <bruno.
42.desthuilli...@wtf.websiteburo.oops.comwrote:
>Lie a crit :
>>On Jan 7, 2:46 am, Bruno Desthuilliers
<bdesth.quelquech...@free.quelquepart.frwrote:
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 !-)
Jan 16 '08 #14

P: n/a
(messed up references?)

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

Regards,
Bjrn

--
BOFH excuse #11:

magnetic interference from money/credit cards

Jan 20 '08 #15

This discussion thread is closed

Replies have been disabled for this discussion.