Laszlo Nagy <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
