Question about PEP 8
bignose+hates-spam at benfinney.id.au
Tue Sep 11 02:34:16 CEST 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
> 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
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 |
More information about the Python-list