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

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/