[openstack-dev] H302 considered harmful
clay.gerrard at gmail.com
Fri Feb 27 20:43:15 UTC 2015
So, Swift doesn't enforce H302 - and our imports are sorta messy frankly -
but it doesn't really bother me, and I do rather enjoy the terseness of not
having to spell out the module name. It's not really a chore to maintain,
if you don't know where a name came from split the window (or drop a
marker) and pop up to the top of the file and there it is - mystery solved.
But I've been living in the code base to long to say if hurts new-comers
trying to grok where things are coming from. I'd be willing to entertain
feedback on this.
But one thing that I'd really love to hear feedback on is if people using
H302 ever find it's inconvenient to enforce the rule *all the time*?
Particularly in stdlib where it'd be *such* bad form to collide with a
common name like `defaultdict` or `datetime` anyway, if you see on of those
names without the module - you *know* where it came from (hopefully?):
* `collections.defaultdict(collections.defaultdict(list))` - no thank you
* `datetime.datetime - meh
Anyway, every time I start some project greenfield I try to make myself
H302, (i *do* get so sick of "is it time.time() or time() in this file?") -
but I normally break down as soon as I get to a name I'd rather just be be
in my right there in my globals... @contextlib.contextmanager,
functools.partial, itertools.ifilter - maybe it's just stdlib names?
Not sure if there's any compromise, probably better to either *just import
modules*, or live with the inconsistency (you eventually get nose-blind to
do it ;P)
On Wed, Feb 25, 2015 at 10:51 AM, Duncan Thomas <duncan.thomas at gmail.com>
> So a review  was recently submitted to cinder to fix up all of the H302
> violations, and turn on the automated check for them. This is certainly a
> reasonable suggestion given the number of manual reviews that -1 for this
> issue, however I'm far from convinced it actually makes the code more
> Is there anybody who'd like to step forward in defence of this rule and
> explain why it is an improvement? I don't discount for a moment the
> possibility I'm missing something, and welcome the education in that case
>  https://review.openstack.org/#/c/145780/
> Duncan Thomas
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev