Steven D'Aprano steve at pearwood.info
Fri Jan 4 23:20:53 EST 2019

On Fri, Jan 04, 2019 at 01:01:51PM -0600, Abe Dillon wrote:

> I keep coming back to this great video <https://vimeo.com/74316116> 

I've just watched it, its a bit slow to start but I agree with Abe that 
it is a great video. (And not just because the speaker agrees with me 
about 80 columns :-)

I don't agree with everything he says, but even where I disagree it is 
great food for thought. I *strongly* suggest people watch the video, 
although you might find (as I did) that the main lessons of it are 
that many common Java idioms exist to work around poor language design, 
and that IDEs rot the brain.


Coming back to the ALLCAPS question, the speaker makes an excellent 
point that in Java, you don't need a naming convention for constants 
because the compiler will give an error if you try to write to a 

But we don't have that in Python. Even if you run a linter that will 
warn on rebinding of constants, you still need a way to tell the linter 
that it is a constant.

The speaker also points out that in programming, we only have a very few 
mechanisms for communicating the meaning of our code:

- names;
- code structure;
- spacing (indentation, grouping).

Code structure is set by the language and there's not much we can do 
about it (unless you're using a language like FORTH where you can create 
your own flow control structures). So in practice we only have naming 
and spacing.

That's an excellent point, but he has missed one more:

* naming conventions.

In Python, we use leading and trailing underscores to give strong hints 
about usage:

    _spam     # private implementation detail

    __spam    # same, but with name mangling

    __spam__  # overload an operator or other special meaning

    spam_     # avoid name clashes with builtins

We typically use CamelCase for classes, making it easy to distinguish 
classes from instances, modules and functions.

And we use ALLCAPS for constants. If that's not needed in Java (I have 
my doubts...) we should also remember the speaker's very good advice 
that just because something is needed (or not needed) in language X, 
doesn't mean that language Y should copy it.


More information about the Python-ideas mailing list