private variables/methods

[Alex Martelli]

Harri Pesonen wrote:
   ...
> Because it has been asked 4000 times probably means that there is a
> great need for the feature...

I can't think of ANY "feechur" from other popular languages that hasn't
been asked for, thousands of times.  Does this mean that "there is a
great need" for each and all of them?  Not at all: it just means that people
hanker for what they're familiar with.  If Python were to satisfy even 
1/10th of this incessant barrage of requests, it would devolve to a
large amorphous blob -- like many other languages have.  The people
requesting these features are typically NOT experienced with Python:
they haven't experienced how the LACK of these features in fact makes
it easier and more productive to write application programs.


> "Python" doesn't want a "private" keyword? 

If Python can be said to have a will -- embodied in Guido or spread
as community consensus -- it definitely doesn't.

> I have quite a limited Python
> experience but I would like to have the following features in Python
> that are common in other languages:

Not 'but', but rather, THEREFORE.  Reread your words with this
change and with some luck you may get it.


> * Option Explicit
> * variable type declaration (optional)
> * private variables/methods
> 
> Most of these are handy for large projects, where you want to be sure
> that a class is not misused (by other developers). These also mean that
> it is much harder to create bugs. I like Python a lot, but with these
> features it would be much better for serious development of complex
> applications, not just for scripting.

You are wrong.  I used to harbor similar illusions (to a lesser degree,
because I _did_ have SOME experience with other dynamic languages,
but not in using them for really large apps) back when the language I
most used was C++.  I was wrong, too.

Other developers aren't any likelier to "misuse" your class than you
are to misdesign it in the first place -- and you'll NEVER "be sure"
anyway, as restrictions can be worked around.  _ADVISORY_
indications of "privacy" -- the convention of starting the name with
a single underscore -- are much simpler and equally effective for
your purposes.  Python is wonderfully effective for programming
large applications, exactly as it is today.


> One thing I have noticed that the keyword "global" is very confusing.

You are right.  It would be better if the current module could be
imported -- by using some reserved special module name in a
perfectly ordinary 'import' instruction -- so that global variables
could then be re-bound as attributes of this module.

Just to give you an idea, in today's Python you could add this
feature as:

# part to be executed once, e.g. in site.py
import __builtin__, sys
_base_import = __builtin__.__import__
def __import__(name, *args):
    if name == '__current_module__':
        name = sys._getframe(1).f_globals['__name__']
    return _base_import(name, *args)
__builtin__.__import__ = __import__
# end of part to be executed once

# example use
x = 23

def set_the_global():
    import __current_module__
    __current_module__.x = 45

print x
set_the_global()
print x


emits
23
45

> For example, the following is syntactically valid Python:
> 
> a = 1
> def b():
> a = 2
> def c():
> return a
> 
> But it does not work as expected. Function b just creates a new local
> variable "a" inside function b! The correct function is of course:
> 
> def b():
> global a
> a = 2
> 
> On the other hand, function c refers to the same global variable just
> fine without any extra "global" keyword. Why on earth?? :-) In every

Because reading is different from writing.  Reading globals is (more or
less) all right; writing globals is a delicate decision that is well worth
emphasizing.  So, anything that's written (any name that's re-bound,
to be precise) is deemed to be local -- unless explicitly mentioned in
a global statement.

The problem with global is that it's not clear enough.  If there simply
was NO way at all to have any assignment to a bare name, such
as "a=2", EVER affect anything BUT a local, things would be much
clearer; the need to import __current_module__ would emphasize what
a serious, think-twice-about-it decision it is to choose to rebind
module-global names.  It would also emphasize that 'global' means
'of this module', not in any way of ALL modules -- a misconception
that often affects newbies.

Hmmm -- maybe THIS is worth proposing for 2.4 (with a
pending deprecation warning for the global statement)...

> other language I know you don't need "global". It is ugly.

Problem is, it's not quite ugly enough (nor quite clear enough).
Discouraging you from affecting globals is a swell idea, but I
think the 'global' statement may not be enough for that, whence
my newly conceived suggestion about importing...


Alex