<div dir="ltr">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.<div><br></div><div>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?):</div><div><br></div><div> * `collections.defaultdict(collections.defaultdict(list))` - no thank you</div><div> * `datetime.datetime - meh</div><div><br></div><div>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?</div><div><br></div><div>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)</div><div><br></div><div>-Clay</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 25, 2015 at 10:51 AM, Duncan Thomas <span dir="ltr"><<a href="mailto:duncan.thomas@gmail.com" target="_blank">duncan.thomas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi<br><br></div>So a review [1] 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,<br><br></div>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<br><br></div>Thanks<br clear="all"><div><div><div><div><br><br>[1] <a href="https://review.openstack.org/#/c/145780/" target="_blank">https://review.openstack.org/#/c/145780/</a><span class="HOEnZb"><font color="#888888"><br>-- <br><div>Duncan Thomas</div>
</font></span></div></div></div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>