«

On Mon, 24 Jan 2005 15:35:11 -0600, Philippe C. Martin wrote:

> The real reason behind my using private variables is so they do not appear
> in the epydoc generated documentation and confuse my users.

You mean single or double underscores? I just checked and at least epydoc
2.1 doesn't include single-underscore values, but those aren't "private"
in sense we're talking in this thread (some form of compiler enforcement).

The real reason behind my using private variables is so they do not
appear in the epydoc generated documentation and confuse my users.

Regards,

Philippe




--
***************************
Philippe C. Martin
SnakeCard LLC
www.snakecard.com
***************************

I used double underscore because I thought it was the correct way to name
private variables/methods - I will have to change those to single
underscore since that it the current methodology.

A private variable to me:
1) is internal to the processing of a class and needs not be accessed by
external or derivated objects. (I won't get into the
potential need of "protected" variables/methods - Python creators have not
made those distinctions for reasons that they believe are good and I'm not
the one to discuss them)
2) Must not be documented to library users as they're using it would
go againts 'law' 1).
3) I wish I had one, but there is only one Isaac Asimov after all

Regards,

Philippe








On Mon, 24 Jan 2005 11:45:34 -0500, Jeremy Bowers wrote:

> On Mon, 24 Jan 2005 15:35:11 -0600, Philippe C. Martin wrote:
>
>> The real reason behind my using private variables is so they do not appear
>> in the epydoc generated documentation and confuse my users.
>
> You mean single or double underscores? I just checked and at least epydoc
> 2.1 doesn't include single-underscore values, but those aren't "private"
> in sense we're talking in this thread (some form of compiler enforcement).

Philippe C. Martin wrote:
> I used double underscore because I thought it was the correct way to name
> private variables/methods - I will have to change those to single
> underscore since that it the current methodology.
>
> A private variable to me:
> 1) is internal to the processing of a class and needs not be accessed by
> external or derivated objects.
[snip]
> 2) Must not be documented to library users as they're using it would
> go againts 'law' 1).

Yeah, I use single-underscores for similar reasons, and so that
PythonWin doesn't show my "private" variables in the drop-down list of
object attributes. I think for most uses, no name-mangling is required...

Of course, I could generate an arbitrary number of "problem cases" -- I
just don't think they happen often in real code...

Steve