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

[Mark Wu]

On 01/06/2014 09:18 PM, Aline Manera wrote:
> 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.
Actually,  at that time,  I have provided my suggestion on that:
https://groups.google.com/forum/#!msg/project-kimchi/smxYARdcNEY/rGpxBjjW7JMJ 
<https://groups.google.com/forum/#%21msg/project-kimchi/smxYARdcNEY/rGpxBjjW7JMJ>

As what I said before,  the duplicate import can be resolved by the pep8 
check.
> 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/
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140107/2ae2ee8c/attachment.html>