[EMAIL PROTECTED] wrote:
> so the following would not result in any conflicts
>
> class A:
>def __init__(self):
> self.__i= 0
>
> class B(A):
>def __init__(self):
> A.__init__(self)
> self.__i= 1
>
Be careful here. The above won't result in any conflicts, but related
[EMAIL PROTECTED] a écrit :
> Your suggestion ('_name' -> implementation, 'name' -> API)
This is not "my" convention, it's *the* (mostly agreed upon) Python
convention. Like 'self', or CONSTANT, or a whole lot of things in Python.
> makes sense
> as a convention between programmers that know a
<[EMAIL PROTECTED]> wrote:
...
> I don't think it is reasonable in general to only subclass from base
> classes you have studied the full API of, however. The double
I think you underestimate the level of coupling that inevitably occurs
between base and derived classes. In general, such coupl
Your suggestion ('_name' -> implementation, 'name' -> API) makes sense
as a convention between programmers that know a fair amount about each
other's classes before using them.
I don't think it is reasonable in general to only subclass from base
classes you have studied the full API of, however.
I see what you mean now.
It would indeed be enlightening if I wanted to study the internals of
Tkinter, and perhaps one day I will.
--
http://mail.python.org/mailman/listinfo/python-list
[EMAIL PROTECTED] wrote:
(snip)
> So putting two underscores in front of an instance variable (or any
> identifier used inside the scope of a class statement) invokes a name
> mangling mechanism
(snip)
> Is it commonplace to use underscores
I assume you mean double underscore...
> when definin
[EMAIL PROTECTED] wrote:
> Suppose you want to write a subclass of some existing class you are
> importing from a module you didn't write and that you don't want to
> study the internals of
No need to study its internals. Fire up a Python interpreter and
inspect its outside:
>>> import foomod
Fredrik Lundh wrote:
> [EMAIL PROTECTED] wrote:
>
> > Now, 'i' might have already been defined by A or by the call to
> > A.__init__() so if you define it without knowing that, you could be
> > changing the behavior of A's methods in unknown ways, which is
> > obviously a bad thing.
>
> http://doc
Steve Juranich wrote:
> This should prove most enlightening:
>
> import Tkinter
> dir(Tkinter.Canvas)
>
>
Huh?
Chris Marshall
--
http://mail.python.org/mailman/listinfo/python-list
[EMAIL PROTECTED] wrote:
> Now, 'i' might have already been defined by A or by the call to
> A.__init__() so if you define it without knowing that, you could be
> changing the behavior of A's methods in unknown ways, which is
> obviously a bad thing.
http://docs.python.org/tut/node11.html#SECTION
This should prove most enlightening:
import Tkinter
dir(Tkinter.Canvas)
On 10 Nov 2005 14:53:04 -0800, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Suppose you want to write a subclass of some existing class you are
> importing from a module you didn't write and that you don't want to
> study
11 matches
Mail list logo
