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 barry
Recipients barry, benjamin.peterson, eric.araujo
Date 2010-09-16.20:40:53
SpamBayes Score 3.330669e-16
Marked as misclassified No
Message-id <20100916164048.547267f5@mission>
In-reply-to <1284668836.67.0.717287318969.issue9877@psf.upfronthosting.co.za>
Content
On Sep 16, 2010, at 08:27 PM, Éric Araujo wrote:

>Éric Araujo <merwok@netwok.org> added the comment:
>
>> I don't agree that it's a bad thing that sysconfig exposes
>> implementation specific information - it seems kind of the point of
>> it.
>
>Well, it exposes configuration information, for example paths (which
>should exist in all VMs), but things like the existence of a .h file
>seem implementation details that should not be public IMO.

If that's the case, then where should this information be exposed?  I think it
needs to be exposed *somewhere*.  You don't want people just guessing or
reinventing all the file system search code that's already in sysconfig.

I'm also not convinced that the paths and schemes are implementation
agnostic.  For example, you'd have to add schemes for each of the other
implementations (and their variants, e.g. Jython installed on POSIX vs. Jython
installed on Windows).  And clearly, some of the scheme paths described in the
module are pretty specific to autoconf's model of the world.  (Does IronPython
really have platinclude?)

Now, I definitely have my own beefs about sysconfig's API, but it is what it
is, so unless there's a clear alternative, I think sysconfig should expose
information that will be useful for programmatically determining configuration
details of the Python you're running.
History
Date User Action Args
2010-09-16 20:40:56barrysetrecipients: + barry, benjamin.peterson, eric.araujo
2010-09-16 20:40:53barrylinkissue9877 messages
2010-09-16 20:40:53barrycreate