Question about PEP 8

Ben Finney bignose+hates-spam at benfinney.id.au
Mon Sep 10 20:34:16 EDT 2007


Laszlo Nagy <gandalf at shopzeus.com> writes:

> Here is my problem. There is ConfigParser, StringIO, Queue,
> HTMLParser etc. They are all part of the standard library.

Yes, many modules in the standard library don't conform to PEP 8;
 these are known bugs.

> Most of these are modules with only a "main class"
> defined. ConfigParser module contains ConfigParser class, Queue
> module contains Queue class etc. Should I use CapWords for the
> module (and file) name or not?

Since that's what it's called, you can't reasonably avoid it.

> E.g. should I
> from mess.wxmegaeidgets.GenericDialog import GenericDialog
>
> or
> from mess.wxmegaeidgets.genericdialog import GenericDialog

Have you tried either of these? Use the one that works.

> (suppose that the module contains only the GenericDialog class. BTW,
> will Py3K change the standard library names in order to follow PEP
> 8?)

There is a distinct "clean up the standard library" project; I can't
recall if it is intended to be part of Py3k.

> Great, but what if I subclass wx widgets? They all have
> CapWords. (wx.Window.ShowModal, wx.Window.Bind etc.) I must use
> CapitalizedWords for method names because sometimes I have to override
> inherited methods, and it is not possible to change their name. Where
> should be the limit?

PEP 8 can't retroactively change the code you're importing. It's a
guideline for code that *you* write; i.e. when you write a new module,
or a new class or function, follow the guidelines.

Existing code is how it is, and a lot of code is already written that
relies on the names in e.g. wxWidgets. Only a backwards-imcompatible
upgrade (such as Py3k) can hope to remove those non-conformant names.

> If I create a composite widget then should I use
> lowercase and underscores?

If it's a class, use TitleCase; if it's an instance or a function, use
lower_case. If it *must* be the same name as something else
(e.g. you're overriding an existing inherited function), you have no
choice but to name it whatever the original is named.

> If I create a class that is not itself a widget, but works with
> widgets? The PEP defines the "theoretically good" coding style, but
> what is the correct style in an environment where you have third
> party libraries that are not following the PEP?

Follow PEP 8 for your code. Grit your teeth and use the non-standard
conventions of third-party libraries, until such time as they are
(backward-incompatibly) changed to be compliant.

-- 
 \     "Don't be afraid of missing opportunities. Behind every failure |
  `\      is an opportunity somebody wishes they had missed."  -- Jane |
_o__)                                          Wagner, via Lily Tomlin |
Ben Finney



More information about the Python-list mailing list