<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 01/06/2014 09:18 PM, Aline Manera
wrote:<br>
</div>
<blockquote cite="mid:52CAAD1C.706@linux.vnet.ibm.com" type="cite">On
01/05/2014 11:05 AM, Zhou Zheng Sheng wrote:
<br>
<blockquote type="cite">on 2014/01/04 00:32, Aline Manera wrote:
<br>
<blockquote type="cite">On 01/03/2014 04:23 AM, Mark Wu wrote:
<br>
<blockquote type="cite">Hi Aline,
<br>
<br>
I would like to start a discussion about the code style for
importing
<br>
modules by this chance.
<br>
<br>
I saw you and Rodrigo had reorganized the "import"
statements(commit
<br>
65f6ad3 and e467b32).
<br>
But personally, I don't agree with the rule you're
following. It
<br>
doesn't comply with PEP8 and bring
<br>
extra unnecessary rules.
<br>
<br>
1. Currently, the kimchi imports and external imports are
separated.
<br>
But according to pep8:
<br>
we still need differentiate the standard library and
third-party
<br>
library. So we just have three groups
<br>
at most and put a blank line between each groups. [1]
<br>
<br>
2. For better looking, we can further organize the imports
in each
<br>
group:
<br>
A. Sort by the import statement: all imports
starting with
<br>
'import' are put together while
<br>
all imports starting with 'from' are put
together. But we
<br>
don't need an explicit separating line
<br>
between them
<br>
B. Sort by module name following the first word
('import' or
<br>
'from')
<br>
<br>
For this patch, I don't think we need two blank to separate
them
<br>
because they belongs to the same group.
<br>
<br>
Does it make thanks for you?
<br>
<br>
</blockquote>
As I've already said, we are a different rule from pep8 for
imports
<br>
<br>
We are using the following rule:
<br>
</blockquote>
Hi Aline.
<br>
<br>
Maybe you did not see my previous reply to Mark's proposal. I
listed
<br>
some reasons to stick to PEP 8 import rules. The problem here is
not
<br>
that we do not know the kimchi rule, but is actually we have
different
<br>
idea on the rule. Would you explain why the current rule is
superior to
<br>
PEP 8?
<br>
<br>
As I wrote, since almost all Python projects comply with PEP,
the
<br>
current rule is very counterintuitive to me (especially the
<br>
two-blank-line-between-import-section rule). I'd believe this
rule would
<br>
also be strange to other Python developers, and you create extra
<br>
maintenance effort to reminding and describing the kimchi rule
to
<br>
Pythonic people who already "programmed" themselves to work with
PEP.
<br>
<br>
In fact the PEP 8 is more reasonable on the grouping. It
differentiate
<br>
standard lib and third-party lib import. This is very
convenience if
<br>
someone sees a new module to him, and want to lookup
documentation. He
<br>
can just refer to Python official site for standard lib and
search on
<br>
google for third-party lib. Otherwise, he has to read more code
to
<br>
determine if it's an third-party import.
<br>
<br>
The one-blank-line-between-section rule of PEP 8 makes all the
import
<br>
sections compact. We use 2 blank lines between classes because
classes
<br>
are complicated logical entities. However import statements are
just
<br>
listings, they are very simple. Using one blank line is enough
and we
<br>
get compact information.
<br>
<br>
Maybe the current kimchi rule is better in some cases, but the
point is
<br>
that all PEPs are discussed and recognize by lots of Python
developers.
<br>
PEPs are kind of collective intelligence. We should follow PEPs
to make
<br>
our project welcome to the whole Python community, unless we
have good
<br>
enough reason or special enough use case to break it.
<br>
<br>
Here I'm proposing the PEP 8 rule again, while I'm not simply
against
<br>
the current kimchi rule. I'm open to here your considerations.
Would you
<br>
mind explaining your concerns on the current kimchi rule? Why
it's good
<br>
for us? How it's better than PEP 8? Why changing it to PEP 8 is
not
<br>
good for us? Are there some special use case to break PEP 8?
What
<br>
benefit do we get to abandon PEP 8?
<br>
</blockquote>
<br>
Oh... I think this discussion is becoming bigger than it really
is.
<br>
<br>
First of all, let me get it clear, I am not against the PEP 8
style.
<br>
<br>
The intention with the imports organization patches was to
organize them according
<br>
to *a rule* (whatever is that) to avoid getting duplicated imports
and so on.
<br>
<br>
No patch is accepted upstream before being reviewed by at least
one developer.
<br>
Which means the imports organization patches were sent to review
and accepted
<br>
without other suggestion.</blockquote>
Actually, at that time, I have provided my suggestion on that:<br>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<a
href="https://groups.google.com/forum/#%21msg/project-kimchi/smxYARdcNEY/rGpxBjjW7JMJ">https://groups.google.com/forum/#!msg/project-kimchi/smxYARdcNEY/rGpxBjjW7JMJ</a><br>
<br>
As what I said before, the duplicate import can be resolved by the
pep8 check.<br>
<blockquote cite="mid:52CAAD1C.706@linux.vnet.ibm.com" type="cite">
Maybe because of the short time until the patch be applied
<br>
or even because we are in a transition for the PEP 8 style.
<br>
Because that, Kimchi is using a different rule than PEP.
<br>
<br>
As you may know, I proposed the current import rule and I am not a
PEP expert because
<br>
that I didn't heed to it.
<br>
<br>
But I am open to change it if all of you agree it is a better
solution.
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">import ...
<br>
import ...
<br>
import ...
<br>
<br>
<2 lines>
<br>
<br>
from ... import ...
<br>
from ... import ...
<br>
<br>
<2 lines>
<br>
<br>
import kimchi...
<br>
from kimchi import ...
<br>
<br>
<2 lines>
<br>
<br>
All those blocks must be in alphabetic order
<br>
<br>
So, please, organize the imports accordingly to it
<br>
<br>
<blockquote type="cite">Thanks.
<br>
Mark.
<br>
<br>
[1] <a class="moz-txt-link-freetext" href="http://www.python.org/dev/peps/pep-0008/">http://www.python.org/dev/peps/pep-0008/</a>
<br>
</blockquote>
</blockquote>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>