best way to ensure './' is at beginning of sys.path?

[Cameron Simpson]

CCed to Neal: could you confirm or refute my suppositions below, or further 
clarify? Thanks.

On 04Feb2017 12:46, Steve D'Aprano <steve+python at pearwood.info> wrote:
>On Sat, 4 Feb 2017 10:13 am, Ben Finney wrote:
>> Neal Becker <ndbecker2 at gmail.com> writes:
>>> I want to make sure any modules I build in the current directory
>>> overide any others. To do this, I'd like sys.path to always have './'
>>> at the beginning.
>>
>> The ‘sys.path’ list is used only for *absolute* imports. Modules in the
>> current directory should not be imported with an absolute path[0]. So, the
>> current directory should not be in ‘sys.path’.
>[...]
>> [0]: Why not? See the rationale for forcing absolute import by default
>>
><URL:https://www.python.org/dev/peps/pep-0328/#rationale-for-absolute-imports>,
>>      “[I]t is not clear whether ‘import foo’ refers to a top-level
>>      module or to another module inside the package.[…] It's a
>>      particularly difficult problem inside packages because [without
>>      explicit relative import syntax] there's no way to specify which
>>      module is meant.”
>
>I'm not sure that this reasoning applies to Neal's situation. He doesn't
>seem to be talking about a single package, as such, more like he has a
>bunch of unrelated libraries in a single directory. My *guess* is that he
>probably has something like a ~/python or ~/scripts directory, and he likes
>to cd into that directory before running one of the scripts.
>
>I don't know what problem Neal thinks he is solving by always inserting ./
>at the front of sys.path. But the rationale above doesn't seem relevant to
>the *pure technical question* of inserting ./ at the start of sys.path.

I think it is relevant. Why? _Because_ we don't have Neal's wider context, 
which he hasn't provided. Purely technical advice is all very well, and 
definitiely a necessary component to answers.

However, I can't count the number of times I've encountered people requesting a 
specific technical solution to a problem defined only in terms of the technical 
task. And when that particular solution is something that is _usually_ a bad 
idea, one should always accompany the techincal advice with a bit of discussion 
of related alternatives and the up and downsides. Particularly, why the 
requested technical solution is often not thought to be a good thing. And 
ideally with a request for the wider context that _causes_ the OP to request a 
particular solution.

Now, we do actually have a bit of Neal's wider context:

  I want to make sure any modules I build in the current directory
  overide any others.

His requested _particular_ technical solution is this:

  To do this, I'd like sys.path to always have './'
  at the beginning.

I think that's probably a poor technical solution for reasons I've alluded to 
in another post. Ben has provided greater context around that can be done with 
imports so that Neal can perhaps choose another method with the same outcome in 
terms of his wider objective.

From my own perspective, I often want something that feels like what I think 
Neal may want: when I'm debugging my own modules I want the "lib/python" 
subdirectory of my code repository at the start of my Python path in order that 
imports find my developement modules ahead of their installed/published copies.

Now, I have _many_ development directories because I tend to make one for each 
branch in progress, and just cd to the particular dev tree I'm working on.

In this circumstance I've got a personal script called "dev" which prepends the 
_absolute_ paths of the various lib subdirs to the relevant paths, so it sticks 
$PWD/lib/python to the front of $PYTHONPATH. And then it executes whatever 
command I supply:

  dev python -m cs.venti.store_tests

for example.

I suspect Neal could do with something like that instead.

Neal, could you confirm or refute or clarify how this all fits your situation?

Cheers,
Cameron Simpson <cs at zip.com.au>