Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #51520 > unrolled thread

Re: import syntax

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: import syntax Devyn Collier Johnson <devyncjohnson@gmail.com> - 2013-07-29 19:24 -0400

#51520 — Re: import syntax

[Multipart message — attachments visible in raw view] — view raw

On 07/29/2013 06:37 PM, Joshua Landau wrote:
> On 29 July 2013 21:23, Devyn Collier Johnson <devyncjohnson@gmail.com 
> <mailto:devyncjohnson@gmail.com>> wrote:
>
>
>     On 07/29/2013 04:20 PM, Tim Chase wrote:
>
>         On 2013-07-29 16:09, Dave Angel wrote:
>
>             On 07/29/2013 03:48 PM, Devyn Collier Johnson wrote:
>
>                 The PEP8 recommends importing like this:
>
>                 import os
>                 import re
>
>                 not like this:
>
>                 import os, re
>
>             I got a bit further, and if I'm only using a couple of
>             functions
>             from the import, I'll list them in the comment.
>
>         If I just plan to use a small subset, I tend to reach for the
>
>            from sys import stdout, stderr, exit
>
>         sort of syntax.  I find it makes my code read a bit more
>         cleanly than
>         having to type "sys.stderr.write(...)" everywhere but is still
>         pretty
>         readable.
>
>         -tkc
>
>
>     So, there are no advantages or disadvantages when disregarding
>     readability?
>
>
> Sure, just as one light is no brighter or dimmer than another when 
> disregarding luminosity.
>
> As people have said, it improves diffs as well. It flows quicker into 
> the "from module import things" form (which I oft prefer), too.
>
> When asking these questions, ask yourself "why would it *compile* 
> differently? It wouldn't. Plus, premature optimisation is the root of 
> all evil.
>
> 1) Write your code
> 2) If it's slow:
> 2a) Do you have time? If so:
> 2b) Is it important to speed up, or is the slowness not worth spending 
> the hours fixing?
> 2c) Profile it to see what's actually slow
> 2d) Realise that the slow part is not what you thought it was
> 2e) Fix the bit that's slow (and nothing else)
> 2f) Repeat from 2
> 3) Write some more code
Joshua, nice work-flow instructions.

Mahalo,

DCJ

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web