Re: [openstack-dev] [Horizon] import only module message and #noqa
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
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
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
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
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