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

Groups > comp.lang.python > #51514 > 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 Joshua Landau <joshua@landau.ws> - 2013-07-29 23:37 +0100
    Re: import syntax Neil Cerutti <neilc@norwich.edu> - 2013-07-30 13:03 +0000

#51514 — Re: import syntax

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

On 29 July 2013 21:23, Devyn Collier Johnson <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

[toc] | [next] | [standalone]

#51552

On 2013-07-29, Joshua Landau <joshua@landau.ws> wrote:
> 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

1a) Does it work?
1b) Can you prove it?

It's best to at least have some regression tests before you start
refactoring and optimizing.

-- 
Neil Cerutti

[toc] | [prev] | [standalone]

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

csiph-web