Steven Miales extensions - comp.lang.python

Message from discussion Steven Miales extensions

Guido van Rossum

More options Aug 13 1996, 3:00 am

Newsgroups: comp.lang.python

From: Guido van Rossum <gu...@CNRI.Reston.VA.US>

Date: 1996/08/13

Subject: Re: Steven Miales extensions

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

> - We are discussing some way to express scope for certains
> identifiers, right ? Look at definition of a class, we write
> "class foo", or look at a global, we write "global foo". (We do
> *not* write @foo, %foo or ___foo.) So writing "var foo ..." for
> privacy is consistent.

Hmm, these are quite different. 'global' is the only statement that
tells the *parser* (or (byte-code) compiler, if you want) something
about a name; in all other cases, the parser forgets the name as soon
as it's generated the code for it. (Not quite true, since assignments
are scanned for evidence of variables, but that's an optimization
that's -- mostly -- transparent).

> - Using underscore, uppcase letter or some punctuation mark as
> prefix or suffix to indicate semantics for an indentifier is,
> IMHO, inferior.
> + underscore has a long standing tradition of being equal to
> [a-z][A-Z] in identifiers,

Not true -- *leading* underscore has a long tradition (in the C world,
anyway, but we don't really want to ignore that here) of meaning
"internal use" (of some kind). ANSI C has exact rules for the use of
names with single and double leading underscore (anything beginning
with two underscores or with an underscore and an upper case letter is
reserved for the compiler).

Python follows this lead: ``from M import *'' does not import names
with leading underscore, and uses double leading+trailing underscores
for hidden attributes. The idea of the latter is that user code
should never define or use such names except to reference the special
semantics associated with them (e.g. __dict__, __init__, __add__, even
__version__), and the implementation can use these to insert stuff of
its own into a namespace that is otherwise wholly owned by the user
(e.g. __doc__, __file__).

> + making letter uppercase to be syntax to indicate special
> identifier semantics
> is *error prone*, just like . vs. .. or _ vs. __ , and

No dispute there. There are too many conflicting conventions for when
to use upper case to make any sense out of them. This is as bad as
Fortran's ``implicit integer (i-n)''. For many people it takes
considerable effort to notice that "Spam" and "spam" are spelled
differently.

> + use of punctuation marks gives real uggly code (save them for
> operators where they do proper job).

Agreed. Therein lies the road to Perl :-) Peter Munnings' choice of
`.' was very tasteful by comparison, but still not good enough (in my
eyes anyway).

> I can live with the already defined scheme for builtins because
> that's primarily a naming convention, it's not enforced by syntax.

It may not be enforced by syntax, but it's enforced by the virtual
machine, which is practically as strong a force.

> - To those who feel it very important that scope is reflected in the
> name, it's free to use whatever naming scheme. In the process of
> scrutinizing other peoples code, finding out the scope for a
> certian identifier is, to my experience, a lesser effort
> regardless what language it happen to be.

Python is an experiment in how much freedom programmers need. Too
much freedom and nobody can read another's code; too little and
expressiveness is endangered. Python has a little less freedom than C
-- for example, it enforces more consistent use of indentation. You
are still free to choose by how much you indent your code so it looks
good to your eyes, and you can mix spaces and tabs if your editor has
that habit, but you have to be consistent in the indentation of your
code body. Nobody has complained about *that* (the complaints have
been about not having braces as well).

Enforcing capitalization rules isn't quite the same. There are many
conflicting conventions for capitalization in the world (from classic
K&R style which uses ALLCAPS for macros and lower case for everything
else, to the X11 library style), and it's often necessary to maintain
consistency with conventions that are used by some other software
component, e.g. when wrapping a C or C++ library in Python
(interfacing to X11 or to Microsoft APIs comes to mind).

I believe that enforcing the leading double underscore to mean private
variable has a chance of surviving amongst this all. It has very
little actual use apart from the combination with double_trailing
underscore, and some people tell me that they've been using this
already for private variables. It's a logical extension of the use of
a single leading underscore as a convention to indicate internal use
of some kind. It's not too intrusive, and not too much typing --
after all, we *like* having to write ``self.spam = 1'' rather than
``spam = 1'' since it saves us looking up spam in the class definition
or hunting for a local variable declaration for it.

I'm not putting this in 1.4, but I'm very tempted to put it in the
next version. The 'var' proposal seems far from completion, and is
also lacking supporters apart from Donald...

--Guido van Rossum (home page: http://www.python.org/~guido/)

Reply to author Forward