function v. method

fuzzylollipop jarrod.roberson at gmail.com
Fri Jul 21 15:36:07 EDT 2006


Antoon Pardon wrote:

> Suppose I am writing my own module, I use an underscore, to
> mark variables which are an implementation detail for my
> module.
>
> Now I need to import an other module in my module and need access
> to an implementation variable from that module. So now I have
> variables with an underscore which have two different meanings:

you don't understand what "implementation detail" means, it means it is
NOT part of the public API and no client code should ever use it.

If you reference _vara in your code and it is in someone elses module
you don't understand YOU ARE NOT SUPPOSED TO DO THAT!

>   1) This is an implemantation detail of this module, It is the
>      users of my module who have to be extra carefull using it.

Users of your module should NEVER KNOW any of the _ or __ stuff exists
to begin with.

>   2) This is an implemantation detail of the other module,
>      I should be extra carefull using it.

You should NEVER use it.

> And I find variable starting or ending with an underscore ugly. :-)
>
> --
> Antoon Pardon

But like my previous post states, you can mark stuff private in Java
all you want, you can still access. Having the compiler or runtime
enforce that just adds an extra step to turn that enforcement off.

You can do the same thing, in C++.

So WHY does a language need this enforcement.

And the "large code base" needs the "robustness" is not a valid
argument.

Since Apple has proven this NOT to be the case with Cocoa which is in
Objective-C and "knows about access control but doesn't really use
them"

Anyone that things a language HAS to have these constructs enforced by
the compiler or runtime, lacks disipline.

Python has exactly what every other language EFFECTIVELY has, a common
way to document  or "tag" what is _private but might need "Friend"
access, and what is REALLY __private.

If you don't like this, then that is your problem go use a language
that gives you that false sense of secuirty, don't expect it to change.




More information about the Python-list mailing list