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

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

Function for the path of the script?

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

Contents

  Function for the path of the script? Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-26 19:23 -0700
    Re: Function for the path of the script? Skip Montanaro <skip.montanaro@gmail.com> - 2013-10-26 21:42 -0500
    Re: Function for the path of the script? Gary Herron <gary.herron@islandtraining.com> - 2013-10-26 19:52 -0700
    Re: Function for the path of the script? Chris Angelico <rosuav@gmail.com> - 2013-10-27 14:01 +1100
      Re: Function for the path of the script? Grant Edwards <invalid@invalid.invalid> - 2013-10-28 14:49 +0000
        Re: Function for the path of the script? Chris Angelico <rosuav@gmail.com> - 2013-10-29 01:59 +1100
        Re: Function for the path of the script? rurpy@yahoo.com - 2013-10-28 21:00 -0700
          Re: Function for the path of the script? Steven D'Aprano <steve@pearwood.info> - 2013-10-29 05:27 +0000
            Re: Function for the path of the script? Grant Edwards <invalid@invalid.invalid> - 2013-10-29 14:31 +0000
    Re: Function for the path of the script? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-27 03:42 +0000
    Re: Function for the path of the script? Ben Finney <ben+python@benfinney.id.au> - 2013-10-27 15:10 +1100
      Re: Function for the path of the script? Roy Smith <roy@panix.com> - 2013-10-27 09:38 -0400
      Re: Function for the path of the script? Grant Edwards <invalid@invalid.invalid> - 2013-10-28 14:58 +0000
        Re: Function for the path of the script? Ben Finney <ben+python@benfinney.id.au> - 2013-10-29 09:50 +1100
          Re: Function for the path of the script? Grant Edwards <invalid@invalid.invalid> - 2013-10-29 14:26 +0000
    How to find where data files are installed for my Python program (was: Function for the path of the script?) Ben Finney <ben+python@benfinney.id.au> - 2013-10-27 15:28 +1100
      Re: How to find where data files are installed for my Python program (was: Function for the path of the script?) rurpy@yahoo.com - 2013-10-26 22:18 -0700
      Re: How to find where data files are installed for my Python program Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-10-27 20:58 +1300
        Re: How to find where data files are installed for my Python program Ian Kelly <ian.g.kelly@gmail.com> - 2013-10-27 09:50 -0600
        Re: How to find where data files are installed for my Python program Ben Finney <ben+python@benfinney.id.au> - 2013-10-28 10:13 +1100
        Re: How to find where data files are installed for my Python program Ben Finney <ben+python@benfinney.id.au> - 2013-10-28 10:31 +1100
        Re: How to find where data files are installed for my Python program Chris Angelico <rosuav@gmail.com> - 2013-10-28 10:58 +1100
        Re: How to find where data files are installed for my Python program Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-28 00:34 +0000
        Re: How to find where data files are installed for my Python program Chris Angelico <rosuav@gmail.com> - 2013-10-28 17:51 +1100
          Re: How to find where data files are installed for my Python program Roy Smith <roy@panix.com> - 2013-10-28 08:51 -0400
            Re: How to find where data files are installed for my Python program Chris Angelico <rosuav@gmail.com> - 2013-10-29 00:06 +1100
    Re: How to find where data files are installed for my Python program (was: Function for the path of the script?) Chris Angelico <rosuav@gmail.com> - 2013-10-27 16:49 +1100
    Re: Function for the path of the script? Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-28 15:57 -0700
    Re: Function for the path of the script? Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-28 22:56 -0700

Page 1 of 2  [1] 2  Next page →

#57704 — Function for the path of the script?

Am I the only one who finds this function super useful?

def _code_file() :
    return os.path.abspath(inspect.getsourcefile(_code_file))


I've got one in every script. It's the only one I have to copy around. For my workflow ... so handy.

I've got os.path.dirname aliased to dn, so its dn(_code_file()) that I find myself reaching for fairly often...

[toc] | [next] | [standalone]

#57706

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

Strange. I almost never want to know the location of the file that's
executing, and when I do, I just reference the __file__ module level
attribute.

Skip

[toc] | [prev] | [next] | [standalone]

#57707

On 10/26/2013 07:23 PM, Peter Cacioppi wrote:
> Am I the only one who finds this function super useful?
>
> def _code_file() :
>      return os.path.abspath(inspect.getsourcefile(_code_file))
>
>
> I've got one in every script. It's the only one I have to copy around. For my workflow ... so handy.
>
> I've got os.path.dirname aliased to dn, so its dn(_code_file()) that I find myself reaching for fairly often...

Huh?  In what kind of a workflow are you running a python file without 
knowing *what* file you are runnung?

Or am I just misinterpreting what this code does?

Confused but curious,
Gary Herron

[toc] | [prev] | [next] | [standalone]

#57708

On Sun, Oct 27, 2013 at 1:52 PM, Gary Herron
<gary.herron@islandtraining.com> wrote:
> Huh?  In what kind of a workflow are you running a python file without
> knowing *what* file you are runnung?

It's very common to want to know what directory you're in - it's a
good way to find data files.

ChrisA

[toc] | [prev] | [next] | [standalone]

#57832

On 2013-10-27, Chris Angelico <rosuav@gmail.com> wrote:
> On Sun, Oct 27, 2013 at 1:52 PM, Gary Herron
><gary.herron@islandtraining.com> wrote:

>> Huh?  In what kind of a workflow are you running a python file without
>> knowing *what* file you are runnung?

I've been writing Python programs for 10+ years.  Never have I felt a
need to know the location of the file that's running.  I do sometimes
want to know the _name_ of the file (for multipurpose programs), but I
don't ever remember caring where that file was.

> It's very common to want to know what directory you're in - it's a
> good way to find data files.

From a Unix point of view, that's also very wrong.  Data files don't
belong in the same directory as the executable.

-- 
Grant Edwards               grant.b.edwards        Yow! Is this an out-take
                                  at               from the "BRADY BUNCH"?
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#57834

On Tue, Oct 29, 2013 at 1:49 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2013-10-27, Chris Angelico <rosuav@gmail.com> wrote:
>> It's very common to want to know what directory you're in - it's a
>> good way to find data files.
>
> From a Unix point of view, that's also very wrong.  Data files don't
> belong in the same directory as the executable.

For installed programs, maybe; but we run a lot of scripts out of
source control, like a sanity checker that gets run immediately before
a commit. Some of them need data files that are also source-managed,
so we have them in the same directory. Locating those files is usually
easiest done by tailing onto the script's path.

ChrisA

[toc] | [prev] | [next] | [standalone]

#57875

On 10/28/2013 08:49 AM, Grant Edwards wrote:
> > On 2013-10-27, Chris Angelico <rosuav@gmail.com> wrote:
>> >> On Sun, Oct 27, 2013 at 1:52 PM, Gary Herron
>> >> It's very common to want to know what directory you're in - it's a
>> >> good way to find data files.
> > 
> > From a Unix point of view, that's also very wrong.  Data files don't
> > belong in the same directory as the executable.

In the case of applications installed in /opt, data files 
quite often go in a subdirectory of the executable (or a 
subdirectory of the executable's parent dir) and getting 
the executable's dir is the first step to find the data 
files.

This is not only *not wrong* but the FHS prohibits locating 
such files outside of the /opt subdirectory tree, with some 
minor exceptions.

This was pointed out before but since you said you ignore
posts from GG you probably missed it, and will probably miss
this one too, and thus continue to post bad information.
  
This is a small but illustrative example of why such broad-
brush filtering is a bad idea.  But it is your choice.

[toc] | [prev] | [next] | [standalone]

#57883

On Mon, 28 Oct 2013 21:00:39 -0700, rurpy wrote:

> This was pointed out before but since you said you ignore posts from GG
> you probably missed it, and will probably miss this one too, and thus
> continue to post bad information.
>   
> This is a small but illustrative example of why such broad- brush
> filtering is a bad idea.  But it is your choice.

Yes, it is unfortunate that somebody such as yourself who takes the time 
to post well using Google Groups gets tared with the same brush as those 
who don't, but then as my granny used to say, if you lie down with dogs 
you'll get fleas.

If you don't want to be associated with the typical GG posts, you have 
the choice to stop using GG. And just as you make the choice that the 
convenience of GG outweighs the annoyance of being filtered, I expect 
Grant has made the choice that the convenience of avoiding unwanted GG 
posts outweighs the risk of throwing out a useful post or two.

Isn't freedom of choice wonderful? No matter what you choose, you'll 
annoy somebody, possibly yourself :-)


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#57921

On 2013-10-29, Steven D'Aprano <steve@pearwood.info> wrote:
> On Mon, 28 Oct 2013 21:00:39 -0700, rurpy wrote:
>
>> This was pointed out before but since you said you ignore posts from GG
>> you probably missed it, and will probably miss this one too, and thus
>> continue to post bad information.
>>   
>> This is a small but illustrative example of why such broad- brush
>> filtering is a bad idea.  But it is your choice.
>
[...]

> If you don't want to be associated with the typical GG posts, you
> have the choice to stop using GG. And just as you make the choice
> that the convenience of GG outweighs the annoyance of being filtered,
> I expect Grant has made the choice that the convenience of avoiding
> unwanted GG posts outweighs the risk of throwing out a useful post or
> two.

At the time I made that choice there was a significant problem with
spam being sent using GG posts.  I'm told that the list server
attempted to filter out those posts, but those of us who read this via
Usenet got the full broadside of ads and scams.  Based on the S/N
ratio of non-spam GG posts, the choice was pretty obvious.

-- 
Grant Edwards               grant.b.edwards        Yow! Edwin Meese made me
                                  at               wear CORDOVANS!!
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#57711

On Sat, 26 Oct 2013 19:23:43 -0700, Peter Cacioppi wrote:

> Am I the only one who finds this function super useful?
> 
> def _code_file() :
>     return os.path.abspath(inspect.getsourcefile(_code_file))
> 
> 
> I've got one in every script. It's the only one I have to copy around.
> For my workflow ... so handy.
> 
> I've got os.path.dirname aliased to dn, so its dn(_code_file()) that I
> find myself reaching for fairly often...


I'm afraid I don't find it useful. I won't say that I *never* need to 
check the location of a module, but it's certainly very rare. I'm curious 
-- what are you doing that you copy this function into every script?

Also, as given, the above function fails if the source code is not 
available (say, you provide only the .pyc file without any corresponding 
source). A better way is to inspect the module object's __file__ 
attribute:

py> import math
py> math.__file__
'/usr/local/lib/python2.7/lib-dynload/math.so'

(Built-in modules which don't exist as a separate file, like sys, have no 
__file__ attribute, so be prepared to catch the exception.)


Inside the module itself, the easiest way to get your own path is to 
check the global variable __file__.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#57713

Peter Cacioppi <peter.cacioppi@gmail.com> writes:

> Am I the only one who finds this function super useful?
>
> def _code_file() :
>     return os.path.abspath(inspect.getsourcefile(_code_file))

I've used ‘os.path.dirname(os.path.abspath(__file__))’ to find the
directory containing the current file, in the past. But that was before
Python's ‘unittest’ module could discover where the test code lives.

> I've got one in every script. It's the only one I have to copy around.
> For my workflow ... so handy.

What workflow requires you to know the filename of the module, within
the module?

-- 
 \                              “Time wounds all heels.” —Groucho Marx |
  `\                                                                   |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#57740

In article <mailman.1636.1382847023.18130.python-list@python.org>,
 Ben Finney <ben+python@benfinney.id.au> wrote:

> Peter Cacioppi <peter.cacioppi@gmail.com> writes:
> 
> > Am I the only one who finds this function super useful?
> >
> > def _code_file() :
> >     return os.path.abspath(inspect.getsourcefile(_code_file))
> 
> I've used ‘os.path.dirname(os.path.abspath(__file__))’ to find the
> directory containing the current file, in the past. But that was before
> Python's ‘unittest’ module could discover where the test code lives.
> 
> > I've got one in every script. It's the only one I have to copy around.
> > For my workflow ... so handy.
> 
> What workflow requires you to know the filename of the module, within
> the module?

We use:

    config_dir = os.path.abspath(os.path.dirname(__file__))
    songza_dir, _ = os.path.split(config_dir)
    top_dir, _ = os.path.split(songza_dir)
    assert os.path.exists(top_dir + "/.hg")
    return top_dir

in our config files.  This gives us the absolute path to the top of our 
source tree (I don't remember why we do the double os.path.split() 
instead of the more obvious "../..").  We know the file where this code 
lives is two levels down from the top of the source tree.

Once we've got the absolute path to the top of the tree, that's used in 
all sorts of places to locate data files, and to generate configurations 
for other applications (nginx, etc).

[toc] | [prev] | [next] | [standalone]

#57833

On 2013-10-27, Ben Finney <ben+python@benfinney.id.au> wrote:

> What workflow requires you to know the filename of the module, within
> the module?

If you have a utility that can be used to do several related things,
one way to tell that utility which you want to do is with command line
arguments.  For example your utility checks sys.argv[1] for a command
or option flag.  Another way is to give the file multiple names, and
check sys.argv[0] to see what name you've been invoked under.  The
latter approach not unusual in the Unix world, and has been carried to
a rather astounding extent by the "busybox" project:

  http://www.busybox.net/about.html

It's all the command-line utilities you need for a small Unix system
in a single binary: one executable with dozens and dozens of links
(hard or symbolic).
  
-- 
Grant Edwards               grant.b.edwards        Yow! I request a weekend in
                                  at               Havana with Phil Silvers!
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#57851

Grant Edwards <invalid@invalid.invalid> writes:

> On 2013-10-27, Ben Finney <ben+python@benfinney.id.au> wrote:
>
> > What workflow requires you to know the filename of the module, within
> > the module?
>
> If you have a utility that can be used to do several related things,
> one way to tell that utility which you want to do is with command line
> arguments.

That's a case for inspecting the command line.

> For example your utility checks sys.argv[1] for a command or option
> flag. Another way is to give the file multiple names, and check
> sys.argv[0] to see what name you've been invoked under.

Exactly so. This isn't a use case for finding the filesystem location of
the module.

-- 
 \        “We have to go forth and crush every world view that doesn't |
  `\                believe in tolerance and free speech.” —David Brin |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#57920

On 2013-10-28, Ben Finney <ben+python@benfinney.id.au> wrote:
> Grant Edwards <invalid@invalid.invalid> writes:
>
>> On 2013-10-27, Ben Finney <ben+python@benfinney.id.au> wrote:
>>
>> > What workflow requires you to know the filename of the module, within
>> > the module?
>>
>> If you have a utility that can be used to do several related things,
>> one way to tell that utility which you want to do is with command line
>> arguments.
>
> That's a case for inspecting the command line.
>
>> For example your utility checks sys.argv[1] for a command or option
>> flag. Another way is to give the file multiple names, and check
>> sys.argv[0] to see what name you've been invoked under.
>
> Exactly so. This isn't a use case for finding the filesystem location
> of the module.

Indeed. I was answering a question about a use case knowing the
_filename_, not the path for the file.


-- 
Grant Edwards               grant.b.edwards        Yow! I wonder if I should
                                  at               put myself in ESCROW!!
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#57714 — How to find where data files are installed for my Python program (was: Function for the path of the script?)

Chris Angelico <rosuav@gmail.com> writes:

> It's very common to want to know what directory you're in - it's a
> good way to find data files.

That's a naive way to do it (though it's often good enough, for a
program only used on one system).

For programs intending to be used across many systems, the data files
often shouldn't be placed in the same directory as the program.

On systems conforming to the Filesystem Hierarchy Standard, it's
forbidden: programs go in a platform-specific location
<URL:http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA>,
while platform-independent data files go in a separate location
<URL:http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA>.

The ‘package_data’ feature of Distutils (originally from Setuptools)
<URL:http://docs.python.org/2/distutils/setupscript.html#installing-package-data>
doesn't help with this. The specified files are simply installed in a
subdirectory of the platform-specific program location, which violates
the FHS as described above.

So, what facility is there in Python to:

* allow the operating system to set separate installation locations for
  the program versus the data files; and

* allow the program to interrogate the operating system for where its
  data files are installed

in a way that lets the programmer ignore the specifics of each operating
system, while leaving it up to the system administrator to decide to
place data files separate from program files at install time?

-- 
 \         “I still have my Christmas Tree. I looked at it today. Sure |
  `\               enough, I couldn't see any forests.” —Steven Wright |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#57722 — Re: How to find where data files are installed for my Python program (was: Function for the path of the script?)

On 10/26/2013 10:28 PM, Ben Finney wrote:
> Chris Angelico <rosuav@gmail.com> writes:
> 
>> It's very common to want to know what directory you're in - it's a
>> good way to find data files.
> 
> That's a naive way to do it (though it's often good enough, for a
> program only used on one system).
> 
> For programs intending to be used across many systems, the data files
> often shouldn't be placed in the same directory as the program.
> 
> On systems conforming to the Filesystem Hierarchy Standard, it's
> forbidden: programs go in a platform-specific location
> <URL:http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA>,
> while platform-independent data files go in a separate location
> <URL:http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA>.

What about Python applications installed in /opt?
On my systems, unless a third party app is packaged and
distributed by the OS package manager, it goes in /opt
and AFAIK, it is blessed practice to keep all the app
files in the same subdirectory tree there.

[toc] | [prev] | [next] | [standalone]

#57729 — Re: How to find where data files are installed for my Python program

Ben Finney wrote:
> On systems conforming to the Filesystem Hierarchy Standard, it's
> forbidden: programs go in a platform-specific location
> <URL:http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA>,
> while platform-independent data files go in a separate location
> <URL:http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA>.

But Python code itself is platform-independent, so it
should count as data for the purposes of the FHS,
shouldn't it?

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#57752 — Re: How to find where data files are installed for my Python program

On Sun, Oct 27, 2013 at 1:58 AM, Gregory Ewing
<greg.ewing@canterbury.ac.nz> wrote:
> Ben Finney wrote:
>>
>> On systems conforming to the Filesystem Hierarchy Standard, it's
>> forbidden: programs go in a platform-specific location
>>
>> <URL:http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA>,
>> while platform-independent data files go in a separate location
>>
>> <URL:http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA>.
>
>
> But Python code itself is platform-independent, so it
> should count as data for the purposes of the FHS,
> shouldn't it?

I don't see why Python files should be treated any differently than
other non-binary executables, e.g. shell scripts.

[toc] | [prev] | [next] | [standalone]

#57772 — Re: How to find where data files are installed for my Python program

Gregory Ewing <greg.ewing@canterbury.ac.nz> writes:

> Ben Finney wrote:
> > On systems conforming to the Filesystem Hierarchy Standard, it's
> > forbidden: programs go in a platform-specific location
> > <URL:http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA>,
> > while platform-independent data files go in a separate location
> > <URL:http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA>.
>
> But Python code itself is platform-independent, so it should count as
> data for the purposes of the FHS, shouldn't it?

True in most cases, but not all (think extension modules, compiled to
architecture-specific bytecode). But you're right, I over-simplified.

The FHS specifies that the first location isn't only for
platform-specific files, but is also for “object files, libraries, and
internal binaries that are not intended to be executed directly by users
or shell scripts”.

The second location is for “all read-only architecture independent data
files” (where the context makes it clear that “data files” is exclusive
of program files).

So, whether Python bytecode is platform-specific or not, it is relegated
by the FHS to a separate location from data files. The separation
requirement remains, and Python's distutils doesn't support it.

What Python facilities do we have for supporting both install-time
decisions about package install layout, and run-time requirements to
find the files wherever they were installed?

-- 
 \         “Two paradoxes are better than one; they may even suggest a |
  `\                                         solution.” —Edward Teller |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

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

csiph-web