[Python-ideas] 'from os.path import FILE, DIR' or internal structure of filenames

[Cameron Simpson]

On 20Apr2014 14:41, anatoly techtonik <techtonik at gmail.com> wrote:
>On Sun, Sep 29, 2013 at 2:26 AM, Cameron Simpson <cs at zip.com.au> wrote:
>> -1 for any names commencing with __ (or even _).
>
>So you like it DIR, PATH

As per-module/file predefined global "constants"? Possibly. Still -0, but open 
to argument on naming issues.

>> -1 for new globals.
>
>So you want this:
>    from os.path import DIR, PATH

I'm less good on these. That would import some staticish values (or are they to 
be functions?) which can't be right for the importing module. I suspect I'm 
misunderstanding your intent here.

>> -1 because I can imagine wanting different nuances on the definitions
>>    above; in particular for DIR I can well imagine wanting bare
>>    dirname(abspath(FILE)) - semanticly different to your construction.
>>    There's lots of scope for bikeshedding here.
>
>Assuming that FILE is always absolute, how that:
>   dirname(abspath(FILE))
>is different from that:
>   abspath(dirname(FILE))
>?

Depends what "absolute" means. When the source file was obtained by traversing 
a symlink, is FILE naive (ignored the symlink, just has to start at "/") or
resolved (absolute path to FILE which does not traverse a symlink)?

I can imagine use cases for both, and therefore the bikeshedding.

>> -1 because this is trivial trival code.
>
>Code is trivial, but the problem is not. In particular, this code
>doesn't work after os.chdir

I'm fairly sure I acknowledged this. [...] Aha:

On Mon, 30 Sep 2013 08:17:46 +1000 I wrote:
   Of course, chdir and passing paths to programs-which-are-not-my-children
   present scope for wanting abspath, but in the very common simple
   case: unnecessary and therefore undesirable.
   And I'm aware that modules-inside-zip-files don't work with this;
   let us ignore that; they won't work  with abspath either:-)

And what should happen for code from zipfiles? Something must happen, even if 
it is just NameError or the like, for "not supported".

>> -1 because you can do all this with relative paths anyway, no need for abspath
>
>Non reliable because of os.chdir

As mentioned above, yes. But very often irrelevant. (Hmm, maybe not in the 
general case of library code imported before a chdir and used afterwards.)

Chdir's global nature (witin the process) is one reason casual use of it is 
discouraged; an amazing amount of stuff can be broken by a chdir.

>> -1 because I can imagine being unable to compute abspath in certain
>>     circumstances ( certainly on older UNIX systems you could be
>>     inside a directory without sufficient privileges to walk back
>>     up the tree for getcwd and its equivalents )
>
>Fear and uncertainty. Can you confirm that Python is able to launch script, but
>abspath fails in these circumstances? There might be a bc break in 3.5

I'd need a suitable system today. On Linux, getcwd() has been a system call for 
a long time (I remember being slapped down on that very issue once). Let's try 
this Mac:

   $ mkdir -p fooo/baaa
   $ cd fooo/baaa
   $ chmod 0 ..
   $ /bin/pwd
   pwd: .: Permission denied
   $

So, yeah, not always reliable.

This means that anything that presupplies names for [PHP-like __FILE__ and 
__DIR__] needs to compute it at need, not always. And the downside is that if 
these idoms, and importantly reliance on these idioms, becomes common then 
suddenly every Python program becomes a ticking time bomb for being run in an 
unusual-but-valid environment.

Any kind of security conscious environment may require programs to run in 
constrained contexts. It is best to minimise the presumptions that a program 
makes in the name of convenience. More than once I've met devs whose code ran 
only in their (very very open/unsecured) dev environment and failed even in our 
staging environments.

So I while it is rare, I don't think "/bin/pwd doesn't work" should be entirely 
ignored.

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

Every particle continues in its state of rest or uniform motion in a straight
line except insofar as it doesn't.      - Sir Arther Eddington