On Mar 17, 2006, at 12:40 AM, Martin v. Löwis wrote:
> Fredrik Lundh wrote:
>> I don't think many people embed setup.py scripts, so alternative
>> (e) would pro-
>> bably cause the least problems:
>>
>> e) sys.executable contains the full path to the program used
>> to invoke
>> this
Fredrik Lundh wrote:
> I don't think many people embed setup.py scripts, so alternative (e) would
> pro-
> bably cause the least problems:
>
> e) sys.executable contains the full path to the program used to invoke
> this interpreter instance, or None if this could not be determined.
It s
Fred L. Drake, Jr. wrote:
> Fredrik Lundh wrote:
> > d) If Python was started from a standard Python interpreter,
>
> My understanding matches Guido's description, so I'm not sure any changes are
> needed.
the problem with that is that your understanding doesn't match the
implementation
(wh
On Thu, 2006-03-16 at 12:02 +0100, Fredrik Lundh wrote:
> a) sys.executable points to the executable that was used to load the
> Python interpreter library/dll.
>
> this use is supported by the docstring and the implementation, and is
> quite
> common in the wild. an application
Fredrik Lundh schrieb:
>how about this alternative ? (extended (b)).
>
>d) If Python was started from a standard Python interpreter,
>sys.executable contains the full path to this interpreter. If not,
>or if the path could not be determined, sys.executable is set to
>None.
>
>
At 07:40 PM 3/16/2006 +0100, Fredrik Lundh wrote:
>Looks like I might have to withdraw my (d) proposal, and, once again, suggest
>that we stick to the "GetProgramFullPath" sense, as implemented, and add a
>new variable for the originally intended but not really implemented "GetInter-
>preterPath" s
> > > a) sys.executable points to the executable that was used to load the
> > > Python interpreter library/dll.
> > >
> > > this use is supported by the docstring and the implementation, and is
> > > quite
> > > common in the wild. an application using this interpretation may
Th
> Fredrik Lundh wrote:
> > a) sys.executable points to the executable that was used to load the
> > Python interpreter library/dll.
> >
> > this use is supported by the docstring and the implementation, and is
> > quite
> > common in the wild. an application using this interpreta
Guido van Rossum wrote:
> Can you say more about the motivation for wanting this reinterpreted?
Fredrik Lundh wrote:
> d) If Python was started from a standard Python interpreter,
My understanding matches Guido's description, so I'm not sure any changes are
needed. Since an embedding appl
Fredrik Lundh wrote:
> the definition of sys.executable is a bit unclear, something that has led to
> incompatible use in deployed code.
>
> the docstring for sys.executable says "pathname of this Python interpreter",
> which can be interpreted as either
>
> a) sys.executable points to the ex
Guido van Rossum wrote:
> For finding related files, sys.exec_prefix and sys.prefix should be used
except that they're defined in terms of where the standard library is:
prefix -- prefix used to find the Python library
exec_prefix -- prefix used to find the machine-specific Python librar
When I added this my intention was a mixture of (b) and (c) -- I
wasn't thinking of situations where there was a difference. (If you
remember Python's very early history, embedding wasn't something I had
anticipated -- hence the "Great Renaming".)
The use that I had in mind does things like os.sys
the definition of sys.executable is a bit unclear, something that has led to
incompatible use in deployed code.
the docstring for sys.executable says "pathname of this Python interpreter",
which can be interpreted as either
a) sys.executable points to the executable that was used to load the
13 matches
Mail list logo
