[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 04/37] qapi: move generator entrypoint into module
From: |
Markus Armbruster |
Subject: |
Re: [PATCH 04/37] qapi: move generator entrypoint into module |
Date: |
Thu, 17 Sep 2020 09:46:29 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
John Snow <jsnow@redhat.com> writes:
> On 9/16/20 7:54 AM, Markus Armbruster wrote:
>> John Snow <jsnow@redhat.com> writes:
>>
>>> As part of delinting and adding type hints to the QAPI generator, it's
>>> helpful for the entrypoint to be part of the module, only leaving a very
>>> tiny entrypoint shim outside of the module.
>>>
>>> As a result, all of the include statements are reworked to be module-aware,
>>> as explicit relative imports.
>> Should this be split into two commits, one for each of the
>> paragraphs
>> above?
>>
>
> Hmm ... I hadn't considered it was possible, but actually ... I guess
> I can split those out, yeah.
>
>> PEP 8 recommends absolute imports, with one exception:
>> However, explicit relative imports are an acceptable
>> alternative to
>> absolute imports, especially when dealing with complex package
>> layouts where using absolute imports would be unnecessarily verbose:
>> from . import sibling
>> from .sibling import example
>> Standard library code should avoid complex package layouts and
>> always use absolute imports.
>> Do you think it covers your use of relative imports?
>>
>
> Admittedly I am going by trial and error; my experience is that the
> relative imports behave the nicest.
>
> There is a historical fear of explicit relative imports because they
> are "new" and years of Python2 compatibility
Having to struggle with that for years was bound to damage brains.
> rendered many afraid of
> them. It is advice safely ignored in my opinion.
>
> Using absolute imports (e.g. from qapi.sibling import foo) gets messy
> in virtual environments when you have *installed* the module in
> question: it becomes ambiguous as to *which* qapi you meant: the one
> in this folder, or the one installed to the environment?
>
> Python, mypy, pylint, flake8 etc disagree sometimes, or can get
> confused; thinking there are two copies of each module.
>
> Just my experience that relative imports seem to give me the least trouble.
>
>>> This is done primarily for the benefit of python tooling (pylint, mypy,
>>> flake8, et al) which otherwise has trouble consistently resolving
>>> "qapi.x" to mean "a sibling file in this folder."
>> Can you give me an example of some tool having troube?
>>
>
> I'd have to code up some examples. I have some hobby code unrelated to
> QEMU where I struggled to get flake8, mypy, and pylint all cooperating
> with an import regime until I gave up and used explicit relative imports.
I'd make the switch when we actually do run into trouble.
But I'm willing to take your advice and switch now.
[...]
- [PATCH 00/37] qapi: static typing conversion, pt1, John Snow, 2020/09/15
- [PATCH 05/37] qapi: Remove wildcard includes, John Snow, 2020/09/15
- [PATCH 06/37] qapi: delint using flake8, John Snow, 2020/09/15
- Re: [PATCH 06/37] qapi: delint using flake8, Markus Armbruster, 2020/09/16
- Re: [PATCH 06/37] qapi: delint using flake8, John Snow, 2020/09/16
- Re: [PATCH 06/37] qapi: delint using flake8, Markus Armbruster, 2020/09/17
- Re: [PATCH 06/37] qapi: delint using flake8, John Snow, 2020/09/17
- Re: [PATCH 06/37] qapi: delint using flake8, Markus Armbruster, 2020/09/18
- Re: [PATCH 06/37] qapi: delint using flake8, John Snow, 2020/09/18
- Re: [PATCH 06/37] qapi: delint using flake8, Markus Armbruster, 2020/09/21
- Re: [PATCH 06/37] qapi: delint using flake8, John Snow, 2020/09/21