PEP 318: Can't we all just get along?

[Mel Wilson]

In article <Michael.J.Fromberger-8D423C.10094219082004 at localhost>,
"Michael J. Fromberger" <Michael.J.Fromberger at Clothing.Dartmouth.EDU> wrote:
>By contrast, the special leading-double-underscore convention for class
>members and the idea to identify instance, static, or class methods
>based on the name of their first parameter, are not even a visibly
>syntactic change.  Each of these ideas specially overloads the single
>most common programming-language operation -- interpretation of a
>variable name -- under particular circumstances.  This technique is (as
>far as I know) nearly unprecedented in other languages, so it would be
>surprising to most programmers.  Furthermore, I think it makes code less
>readable, by hiding important facts inside an implicit assumption about
>the content of non-keyword identifiers, which are otherwise never
>special.

   It relates to Standard C, where the standard divides up
the namespace into names available to the implementation,
and names which a programmer can use without risk of being
clobbered by an implementation.  The distinction is based on
leading underscores and uppercase letters.

   FORTRAN applied a default type of INTEGER to variables
whose names began with I, J, K, L, M or N. Such a move in
Python might make

        i = raw_input ('Number, please: ')

equivalent to

        @raw_input
        @int
        i = 'Number, please: '

(which I don't recommend) or

        i = raw_input ('Number, please: ')
        i = int (i)

>Many people respond to this by saying, "The programmer has to be careful
>anyway, so what is one more thing?"  You could ask the same question
>about drivers and beer.  Little distractions add up to big mistakes.

   Yeah.  At some point in a language's life, it begins to
matter just how many things the programmer has to be careful
about.  Gerald Weinberg has something to say about this in
_The Psychology of Computer Programming_.  The generality vs
raggedness of the distinctions that have to be made matter.
One of Weinberg's examples is in FORTRAN which had tricky
but not essentially difficult rules for which expressions
were and were not allowed in array subscripts.  It was found
that many programmers shied away from using some legal forms,
because it was less trouble to avoid the forms than to
remember where the edge was between legal and illegal.


        Regards.        Mel.