Are there any idiom rules as to where to put import statements in D?

In Python they can go anywhere but PEP-8 suggests they should all go at the top of a file, just after the module documentation string.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wednesday, 7 June 2017 at 12:39:07 UTC, Russel Winder wrote:
> Are there any idiom rules as to where to put import statements in D?
>
> In Python they can go anywhere but PEP-8 suggests they should all go at the top of a file, just after the module documentation string.

I don't know if there is any official dogma on how to use imports, but given that local imports inside templates are only loaded if the template is instantiated, there are benefits to using local imports in those cases.

Another use for local imports is in unittests - any import that is only used in unittests may benefit from being moved from module scope to inside the unittests themselves, or for an import used by many tests, a version (unittest) block.

In my own code, I use very loose guidelines but prefer to put any imports that are used only in one or two functions, inside those functions. Imports that are used by multiple functions are placed at the top of the file, just below the module declaration (if any).

Similarly, I try to use selective imports when only a few symbols from a module are used in my module, but find that this becomes unwieldy past 3-5 symbols.

--
  Biotronic

On Wednesday, 7 June 2017 at 12:39:07 UTC, Russel Winder wrote:
> Are there any idiom rules as to where to put import statements in D?
>
> In Python they can go anywhere but PEP-8 suggests they should all go at the top of a file, just after the module documentation string.

Well for ones that aren't scoped (i.e. used pervasively throughout the module) I always put them after the module declaration (if not the file containing main) and doc comment.

For scoped imports they go either on the line after the opening brace of the enclosing scope, or the line before the (selectively) imported symbol is used (if there is a reasonable amount of code preceding the opening brace).

Perhaps the https://dlang.org/dstyle.html imports section should be expanded.

On Wed, Jun 07, 2017 at 01:17:39PM +0000, Nicholas Wilson via Digitalmars-d-learn wrote:
> On Wednesday, 7 June 2017 at 12:39:07 UTC, Russel Winder wrote:
> > Are there any idiom rules as to where to put import statements in D?
> > 
> > In Python they can go anywhere but PEP-8 suggests they should all go at the top of a file, just after the module documentation string.
> 
> Well for ones that aren't scoped (i.e. used pervasively throughout the
> module) I always put them after the module declaration (if not the
> file containing main) and doc comment.
> 
> For scoped imports they go either on the line after the opening brace of the enclosing scope, or the line before the (selectively) imported symbol is used (if there is a reasonable amount of code preceding the opening brace).
[...]

I follow the same convention.

Though lately, I've been finding myself moving away more and more from global imports, and moving imports into the scope in which they're actually used.  While that sometimes necessitates more typing, I find that it also improves code readability and movability: having scoped imports in the block in which the symbol is used means reducing the likelihood of overload conflicts with unfortunately-named symbols (there are a few of these in Phobos). And I can easily move that code into a different source file and have it Just Work, instead of having to twiddle with the import statements at the top of the file (and inadvertently leave useless imports in the original file where they are no longer needed).

Nowadays I generally only use module-level import for things that are truly used pervasively, like std.range.primitives, and std.stdio in the module where main() is defined.  I try to avoid importing std.stdio anywhere else, unless that module is directly concerned with I/O, and force myself to structure the code such that such a dependency is not needed in the first place -- e.g., write generic range-based algorithms instead of code sprinkled with calls writeln.  I found that this has helped improve my code quality significantly, and my code has become much more reusable.


T

-- 
The best compiler is between your ears. -- Michael Abrash

On Wed, 2017-06-07 at 10:08 -0700, H. S. Teoh via Digitalmars-d-learn wrote:
> On Wed, Jun 07, 2017 at 01:17:39PM +0000, Nicholas Wilson via Digitalmars-d-learn wrote:
> > On Wednesday, 7 June 2017 at 12:39:07 UTC, Russel Winder wrote:
> > > Are there any idiom rules as to where to put import statements in D?
> > > 
> > > In Python they can go anywhere but PEP-8 suggests they should all
> > > go
> > > at the top of a file, just after the module documentation string.
> > 
> > Well for ones that aren't scoped (i.e. used pervasively throughout
> > the
> > module) I always put them after the module declaration (if not the
> > file containing main) and doc comment.

I am also tending to import individual symbols from modules rather than whole modules. In Python this can sometime be the wrong thing to do, but then the scope rules are different to D. The D import scope rules seem to be equivalent to Python star imports, which is a nightmare.

> > For scoped imports they go either on the line after the opening
> > brace
> > of the enclosing scope, or the line before the (selectively)
> > imported
> > symbol is used (if there is a reasonable amount of code preceding
> > the
> > opening brace).

I hadn't got into scoped imports. I suspect I am now going to become a fan of them.

> I follow the same convention.
> 
> Though lately, I've been finding myself moving away more and more
> from
> global imports, and moving imports into the scope in which they're
> actually used.  While that sometimes necessitates more typing, I find
> that it also improves code readability and movability: having scoped
> imports in the block in which the symbol is used means reducing the
> likelihood of overload conflicts with unfortunately-named symbols
> (there
> are a few of these in Phobos). And I can easily move that code into a
> different source file and have it Just Work, instead of having to
> twiddle with the import statements at the top of the file (and
> inadvertently leave useless imports in the original file where they
> are
> no longer needed).
> 
> Nowadays I generally only use module-level import for things that are
> truly used pervasively, like std.range.primitives, and std.stdio in
> the
> module where main() is defined.  I try to avoid importing std.stdio
> anywhere else, unless that module is directly concerned with I/O, and
> force myself to structure the code such that such a dependency is not
> needed in the first place -- e.g., write generic range-based
> algorithms
> instead of code sprinkled with calls writeln.  I found that this has
> helped improve my code quality significantly, and my code has become
> much more reusable.
> 

OK, I am now convinced.

This still leaves the question of "whole module imports" vs "symbols from modules". Because D imports are equivalent to Python or Java star imports, which are anathema, I am thinking "symbols from modules" remains the best strategy even with scoping.


> T
> 
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder