This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients Arfrever, brett.cannon, eric.smith, eric.snow, lemburg, ncoghlan, pitrou
Date 2012-04-25.12:06:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <4F97E8CC.5030602@egenix.com>
In-reply-to <1335354459.3413.1.camel@localhost.localdomain>
Content
Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou@free.fr> added the comment:
> 
>>> Look for "pybuilddir.txt".
>>
>> Oh dear. Another one of those hacks... why wasn't this done using
>> constants passed in by the configure script and simple string
>> comparison ?
> 
> How would that help distinguish between an installed Python and a
> non-installed Python? If you have an idea about that, please open an
> issue and explain it precisely :)

The question pybuildir.txt apparently tries to solve is whether Python
is running from the build dir or not. It's not whether Python was
installed or not. Checking for the build dir can be done by looking
at the argv[0] of the executable and comparing that to the build dir.
This can be compiled into the interpreter using a constant, say
BUILDIR. At runtime, you'd simply compare the current argv[0] to
the BUILDDIR. If it matches, you know that you can assume the
build dir layout with reasonable certainty and proceed accordingly.
No need for extra joins, file reads, etc.

But given the enormous startup time of Python 3.3, those few stats
won't make a difference anyway. This would need a completely different
holistic approach. Perhaps something for SoC project.
History
Date User Action Args
2012-04-25 12:06:41lemburgsetrecipients: + lemburg, brett.cannon, ncoghlan, pitrou, eric.smith, Arfrever, eric.snow
2012-04-25 12:06:40lemburglinkissue14657 messages
2012-04-25 12:06:40lemburgcreate