[Kimchi-devel] [PATCH 1/3] Generate libvirt's interface XML definition for vlanned bridge

Zhou Zheng Sheng zhshzhou at linux.vnet.ibm.com
Sun Jan 5 13:05:06 UTC 2014


on 2014/01/04 00:32, Aline Manera wrote:
> On 01/03/2014 04:23 AM, Mark Wu wrote:
>> Hi Aline,
>>
>> I would like to start a discussion about the code style for importing
>> modules by this chance.
>>
>> I saw you and Rodrigo had reorganized the "import" statements(commit
>> 65f6ad3 and e467b32).
>> But personally, I don't agree with the rule you're following.  It
>> doesn't comply with PEP8 and bring
>> extra unnecessary rules.
>>
>> 1.  Currently, the kimchi imports and external imports are separated. 
>> But according to pep8:
>>      we still need differentiate the standard library and third-party
>> library.  So we just have three groups
>>      at most and put a blank line between each groups. [1]
>>
>> 2.  For better looking,  we can further organize the imports in each
>> group:
>>      A.  Sort by the import statement:  all imports starting with
>> 'import' are put together while
>>           all imports starting with 'from' are put together.  But we
>> don't need an explicit separating line
>>           between them
>>      B.  Sort by module name following the first word ('import' or
>> 'from')
>>
>> For this patch,  I don't think we need two blank to separate them
>> because they belongs to the same group.
>>
>> Does it make thanks for you?
>>
> 
> As I've already said, we are a different rule from pep8 for imports
> 
> We are using the following rule:

Hi Aline.

Maybe you did not see my previous reply to Mark's proposal. I listed
some reasons to stick to PEP 8 import rules. The problem here is not
that we do not know the kimchi rule, but is actually we have different
idea on the rule. Would you explain why the current rule is superior to
PEP 8?

As I wrote, since almost all Python projects comply with PEP, the
current rule is very counterintuitive to me (especially the
two-blank-line-between-import-section rule). I'd believe this rule would
also be strange to other Python developers, and you create extra
maintenance effort to reminding and describing the kimchi rule to
Pythonic people who already "programmed" themselves to work with PEP.

In fact the PEP 8 is more reasonable on the grouping. It differentiate
standard lib and third-party lib import. This is very convenience if
someone sees a new module to him, and want to lookup documentation. He
can just refer to Python official site for standard lib and search on
google for third-party lib. Otherwise, he has to read more code to
determine if it's an third-party import.

The one-blank-line-between-section rule of PEP 8 makes all the import
sections compact. We use 2 blank lines between classes because classes
are complicated logical entities. However import statements are just
listings, they are very simple. Using one blank line is enough and we
get compact information.

Maybe the current kimchi rule is better in some cases, but the point is
that all PEPs are discussed and recognize by lots of Python developers.
PEPs are kind of collective intelligence. We should follow PEPs to make
our project welcome to the whole Python community, unless we have good
enough reason or special enough use case to break it.

Here I'm proposing the PEP 8 rule again, while I'm not simply against
the current kimchi rule. I'm open to here your considerations. Would you
mind explaining your concerns on the current kimchi rule? Why it's good
for us?  How it's better than PEP 8? Why changing it to PEP 8 is not
good for us? Are there some special use case to break PEP 8? What
benefit do we get to abandon PEP 8?

> 
> import ...
> import ...
> import ...
> 
> <2 lines>
> 
> from ... import ...
> from ... import ...
> 
> <2 lines>
> 
> import kimchi...
> from kimchi import ...
> 
> <2 lines>
> 
> All those blocks must be in alphabetic order
> 
> So, please, organize the imports accordingly to it
> 
>> Thanks.
>> Mark.
>>
>> [1] http://www.python.org/dev/peps/pep-0008/
-- 
Thanks and best regards!

Zhou Zheng Sheng / 周征晟
E-mail: zhshzhou at linux.vnet.ibm.com
Telephone: 86-10-82454397




More information about the Kimchi-devel mailing list