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) -Clay On Wed, Feb 25, 2015 at 10:51 AM, Duncan Thomas <duncan.tho...@gmail.com> wrote: > Hi > > 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 > readable, > > 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 > > Thanks > > >  https://review.openstack.org/#/c/145780/ > -- > Duncan Thomas > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev