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

于 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.

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