Re: [openstack-dev] [Horizon] import only module message and #noqa

2014-01-03 Thread Russell Bryant
On 01/03/2014 10:10 AM, Radomir Dopieralski wrote:
 I think that we can actually do a little bit better and remove many of
 the #noqa tags without forfeiting automatic checking. I submitted a
 patch: https://review.openstack.org/#/c/64832/
 
 This basically adds a h302_exceptions option to tox.ini, that lets us
 specify which names are allowed to be imported. For example, we can do:
 
 [hacking]
 h302_exceptions = django.conf.settings,
   django.utils.translation.ugettext_lazy,
   django.core.urlresolvers.
 
 To have settings, _ and everything from urlresolvers importable without
 the need for the #noqa tag.
 
 Of course every project can add their own names there, depending what
 they need.

Isn't that what import_exceptions is for?  For example, we have this
in nova:

import_exceptions = nova.openstack.common.gettextutils._

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Horizon] import only module message and #noqa

2014-01-03 Thread Radomir Dopieralski
On 03/01/14 16:18, Russell Bryant wrote:
 On 01/03/2014 10:10 AM, Radomir Dopieralski wrote:
 I think that we can actually do a little bit better and remove many of
 the #noqa tags without forfeiting automatic checking. I submitted a
 patch: https://review.openstack.org/#/c/64832/

 This basically adds a h302_exceptions option to tox.ini, that lets us
 specify which names are allowed to be imported. For example, we can do:

 [hacking]
 h302_exceptions = django.conf.settings,
   django.utils.translation.ugettext_lazy,
   django.core.urlresolvers.

 To have settings, _ and everything from urlresolvers importable without
 the need for the #noqa tag.

 Of course every project can add their own names there, depending what
 they need.
 
 Isn't that what import_exceptions is for?  For example, we have this
 in nova:
 
 import_exceptions = nova.openstack.common.gettextutils._
 
No exactly, as this will disable all import checks, just like # noqa.

-- 
Radomir Dopieralski

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Horizon] import only module message and #noqa

2014-01-03 Thread Gabriel pettier
On Fri, Jan 03, 2014 at 10:18:58AM -0500, Russell Bryant wrote:
 On 01/03/2014 10:10 AM, Radomir Dopieralski wrote:
  I think that we can actually do a little bit better and remove many of
  the #noqa tags without forfeiting automatic checking. I submitted a
  patch: https://review.openstack.org/#/c/64832/
  
  This basically adds a h302_exceptions option to tox.ini, that lets us
  specify which names are allowed to be imported. For example, we can do:
  
  [hacking]
  h302_exceptions = django.conf.settings,
django.utils.translation.ugettext_lazy,
django.core.urlresolvers.
  
  To have settings, _ and everything from urlresolvers importable without
  the need for the #noqa tag.
  
  Of course every project can add their own names there, depending what
  they need.
 
 Isn't that what import_exceptions is for?  For example, we have this
 in nova:
 
 import_exceptions = nova.openstack.common.gettextutils._
 
 -- 
 Russell Bryant
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I guess it could work too, but that would disable all warnings against 
these imports (unused imports, * imports, etc), right? I think a 
specific option is useful.

-- 
Gabriel Pettier
Software Engineer at CloudWatt.com 
06 85 10 36 34

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Horizon] import only module message and #noqa

2014-01-03 Thread Russell Bryant
On 01/03/2014 10:35 AM, Radomir Dopieralski wrote:
 On 03/01/14 16:18, Russell Bryant wrote:
 On 01/03/2014 10:10 AM, Radomir Dopieralski wrote:
 I think that we can actually do a little bit better and remove many of
 the #noqa tags without forfeiting automatic checking. I submitted a
 patch: https://review.openstack.org/#/c/64832/

 This basically adds a h302_exceptions option to tox.ini, that lets us
 specify which names are allowed to be imported. For example, we can do:

 [hacking]
 h302_exceptions = django.conf.settings,
   django.utils.translation.ugettext_lazy,
   django.core.urlresolvers.

 To have settings, _ and everything from urlresolvers importable without
 the need for the #noqa tag.

 Of course every project can add their own names there, depending what
 they need.

 Isn't that what import_exceptions is for?  For example, we have this
 in nova:

 import_exceptions = nova.openstack.common.gettextutils._

 No exactly, as this will disable all import checks, just like # noqa.
 

Ah, makes sense.  Thanks.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Horizon] import only module message and #noqa

2013-12-30 Thread Gabriel pettier
So Tatiana pointed 
http://lists.openstack.org/pipermail/openstack-dev/2013-June/thread.html#9993 
to me, and from there i went on to read 
http://lists.openstack.org/pipermail/openstack-dev/2013-August/thread.html#13074
 
and i can see valid points for H302, even if it annoy me sometime, if 
it's better for reviews, i understand.

Sorry for the noise

On Mon, Dec 30, 2013 at 03:43:03PM +0100, Gabriel pettier wrote:
 Hi
 
 Reading horizon's code and recent reviews, i'm under the impression that 
 it's a common practice to use #noqa to bypass the import only modules 
 qa message, i'm unconvinced of the advantages of this policy (i think 
 the namespace is often cleaner when one import only the symbols needed 
 from the modules), so i think this policy could be removed, by adding 
 H302 to the list of ignored errors in tox.ini.
 
 This would allow removing a lot of #noqa comments, making for cleaner 
 code.
 
 If there are significant advantages to this policy, however, it should 
 be made more consistently applied to fix all these imports.
 
 Regards
 
 -- 
 Gabriel Pettier
 Software Engineer at CloudWatt.com 
 06 85 10 36 34
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Gabriel Pettier
Software Engineer at CloudWatt.com 
06 85 10 36 34

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev