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

[Sheldon]

On 01/07/2014 12:05 PM, Zhou Zheng Sheng wrote:
> 于 2014年01月06日 21:18, 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.
> Hi, thanks for the reply.
>
> I know you are for PEP 8, but using a different import rule other than
> PEP 8 is not fully PEP 8 compliant. As regard to duplicated imports, I
> think pyflakes can check this type of error, and lots of other errors.
> Many Python projects use pyflakes or pylint to check logical errors.
zhengsheng:
add the doc "PEP8 Checking Using Syntastic" to git hub wiki.
https://github.com/kimchi-project/kimchi/wiki/PEP8-Checking-Using-Syntastic
>> 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.
> Yes, but when we discovered a better way to arrange imports, we can
> slowly transit to the better one.
>> 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/
>


-- 
Thanks and best regards!

Sheldon Feng(冯少合)<shaohef at linux.vnet.ibm.com>
IBM Linux Technology Center