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

[Aline Manera]

On 01/05/2014 11:05 AM, Zhou Zheng Sheng wrote:
> 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?

Oh... I think this discussion is becoming bigger than it really is.

First of all, let me get it clear, I am not against the PEP 8 style.

The intention with the imports organization patches was to organize them 
according
to *a rule* (whatever is that) to avoid getting duplicated imports and 
so on.

No patch is accepted upstream before being reviewed by at least one 
developer.
Which means the imports organization patches were sent to review and 
accepted
without other suggestion. Maybe because of the short time until the 
patch be applied
or even because we are in a transition for the PEP 8 style.
Because that, Kimchi is using a different rule than PEP.

As you may know, I proposed the current import rule and I am not a PEP 
expert because
that I didn't heed to it.

But I am open to change it if all of you agree it is a better solution.

>> 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/