Open Stack

Strongly agreed.

>     1. Does it make sense to implement all imports uniformly like that is done in other projects?
>    
>     Something like this would be nice:
>    
>     from quantum.api.extensions import (
>          ExtensionMiddleware,
>          PluginAwareExtensionManager,
>     )

A topic not discussed is module-level import vs object-level import.
While other core projects only use module-level import, Horizon uses both
and object-level imports are widely used like below.

I would like to use module-level import.
It reduces the number of imports and it has consistency with other project.

What do you think about it?

Thanks.
Akihiro

>>>>> Date: Thu, 6 Jun 2013 13:02:30 -0700
>>>>> From: Matt Joyce <matt.joyce at cloudscaling.com>
>>>>> Subject: Re: [openstack-dev] [Horizon] HACKING.rst and import standards
> 
> Huge +1
> 
> On Jun 6, 2013 12:03 PM, "Gabriel Hurley" <Gabriel.Hurley at nebula.com> wrote:
> 
>     I suggest that we start with enabling H301 (one import per line), H303 (no wildcards), and
>     H306 (alphabetical). I’m honestly surprised by how many violations there are for that last one
>     since we generally try to do that already. Obviously it’ll be a sizable patch to make this
>     happen, but it’d be great to get it done. Please file a bug/blueprint for it.
>    
>      
>    
>     Thanks!
>    
>      
>    
>     -          Gabriel
>    
>      
>    
>     From: Joe Gordon [mailto:joe.gordon0 at gmail.com]
>     Sent: Thursday, June 06, 2013 9:09 AM
>     To: OpenStack Development Mailing List
>     Subject: Re: [openstack-dev] [Horizon] HACKING.rst and import standards
>    
>      
>    
>     Although there is no HACKING.rst in Horizon, it does use the hacking plugin to flake8, just
>     that the tests are all disabled.(https://github.com/openstack/horizon/blob/master/tox.ini#L40
>     ).  You can start gating on one import per line (H301) and alphabetical order (H306), by
>     fixing the issues and re-enabling the checks in tox.ini.
>    
>      
>    
>     'flake8 --statistics --select H3' shows the number off issues:
>    
>      
>    
>     194     H301  one import per line
>    
>     16      H302  import only modules.'from collections import Sequence' does not import a module
>    
>     7       H303  No wildcard (*) import.
>    
>     131     H304  No relative imports. 'from .views import UsageView' is a relative import
>    
>     179     H306  imports not in alphabetical order (django.conf.urls.static.static,
>     django.conf.settings)
>    
>      
>    
>      
>    
>      
>    
>      
>    
>     On Thu, Jun 6, 2013 at 3:42 AM, Dolph Mathews <dolph.mathews at gmail.com> wrote:
>    
>     +1; that's why alphabetical imports and one import per line!
> 
>     On Thursday, June 6, 2013, Bhandaru, Malini K wrote:
>    
>     +1
>    
>     Anything to avoid/ease manual merge.  Good job describing problem Tatiana.
>     Malini
>    
>     -----Original Message-----
>     From: Tatiana V. Mazur [mailto:tmazur at mirantis.com]
>     Sent: Thursday, June 06, 2013 1:44 AM
>     To: openstack-dev at lists.openstack.org
>     Subject: [openstack-dev] [Horizon] HACKING.rst and import standards
>    
>     Hello!
>    
>     Recently I had to upload some patch sets and rebase some branches for this purpose. It appears
>     that rebasing on changed master branch is not a trivial task. You know, when nearly each
>     Horizon module includes a total mash of comma separated imports, that's really not a trivial
>     task.
>     Problems start when you add some method from the same module in an existing import statement
>     like here:
>    
>     from .views import (IndexView, CreateView, EditAttachmentsView, DetailView,
>                          CreateSnapshotView)
>    
>     or even here:
>    
>     from .views import IndexView
>     from .views import AddPoolView, AddMemberView, AddMonitorView, AddVipView from .views import
>     (UpdatePoolView, UpdateMemberView,
>                          UpdateVipView, UpdateMonitorView) from .views import PoolDetailsView,
>     VipDetailsView from .views import MemberDetailsView, MonitorDetailsView from .views import
>     AddPMAssociationView, DeletePMAssociationView
>    
>     All patch sets including this kind of changes can't be merged automatically. You have to
>     rebase manually, just because of a few imports. I was wondering if there is a local Horizon
>     standard for importing and tried to find it in HACKING.rst (like all standards are described
>     in other projects). And it appears there's no HACKING.rst in Horizon! That's why I have a few
>     questions:
>    
>     1. Does it make sense to implement all imports uniformly like that is done in other projects?
>    
>     Something like this would be nice:
>    
>     from quantum.api.extensions import (
>          ExtensionMiddleware,
>          PluginAwareExtensionManager,
>     )
>     from quantum.common import config
>     from quantum.extensions import (
>          credential,
>          qos,
>     )
>    
>     Or just one import per line. That would solve merging problems and code would look much
>     better.
>    
>     2. Does it make sense to add HACKING.rst in Horizon?
>    
>     I think yes. We could describe standards there and we would never get such kind of rebase and
>     merge problems.
>    
>     What do you think about it? I could do it if you find it reasonable .
> 
>     Kind regards,
>     Tatiana
>    
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>    
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>    
>      
>    
>     --
>    
>      
>    
>     -Dolph
>    
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>    
>      
> 
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
>