Python coding style? (Flake8/PEP8...)

Alois Mahdal amahdal at redhat.com
Wed May 14 11:11:40 UTC 2014


Thanks both Michal and Stephen for comments.

Just few comments, mostly from the point of view of static analysis
tools usability.


On Fri, 09 May 2014 10:18:25 +0200
Michal Minář <miminar at redhat.com> wrote:
> 
>   * autogenerated class names and methods for modules in providers
>     - they are very long
>     - mix of CamelCase, lowercase and underscores
>     - but they just make sense since they correspond to CIM
> equivalents
>   * CamelCase used throughout unittest
>     - when using unittest.TestCase as a base class for our test cases,
>       it's just impossible to follow these coding styles. Overriding
>       any method results in CamelCased method in your code.

AFAIK casing is not exactly required by PEP8; there are
recommendations, but at least it's not enforced by the pep8 script by
default.

One exception is the line length 79, but even considering the above,
I believe it would be very rare to have such long ID that would force
us to break this rule (and still make sense).


>   * OpenLMI Scripts and particularly command-line wrappers are
>     specifically designed for quick prototyping and do not follow
>     any coding style at all (you may expect a bunch of warnings).

For that matter, at least flake8 and pep8 can be disabled by magic
comment in file header.


> Making at least our tests look similar should not be a big problem.
> Let's start with that and see, where it gets. Please, go on with your
> idea. Let's discuss the details on review :).

Thanks, I have already started with lmi.test.util.  (Unfortunately it's
not on RB yet due to problems with RBTools --- I'm working on resolving
that.)


Thanks,
aL.

-- 
Alois Mahdal <amahdal at redhat.com>
Platform QE, BaseOS Daemons
#qa, #brno, #daemons


More information about the openlmi-devel mailing list