[Python-Dev] API for the new sysconfig module

[Tarek Ziadé]

Sorry to get late in the discussion I am travelling.

Nick resumes well the motivations behind sysconfig.

I'll emphase that this module could hold more functions in the future that
could be useful to other python implementations to abstract what is a python
installation. E.g. more than paths and variables.

On Dec 11, 2010 3:53 AM, "Nick Coghlan" <ncoghlan at gmail.com> wrote:

On Sat, Dec 11, 2010 at 7:59 AM, R. David Murray <rdmurray at bitdance.com>
wrote:
> On Thu, 09 Dec 201...

>> ISTM it mostly could have been reduced to single call returning a nested
dictionary.
>
> If what ...
We've reverted from beta to pseudo-alpha after discovering
sufficiently egregious mistakes in the past. (we didn't *actually*
revert the build naming because release IDs that don't increase
monotonically can confuse matters). However, I don't think this is
sufficiently egregious to qualify.

My own reasons for advocating retention of the separate module:

1. Something equivalent to the current sysconfig module is going to be
needed to actually work out the contents of the data structure.
Rewriting all that in C would be silly, so the most that could happen
is to rename "sysconfig" to "_sysconfig".

2. Invoking Python code from sys module functions is possible but
untidy (generally involving implicit module imports). Since we need a
module anyway for implementation purposes, why not make it public?

3. The sysconfig module docs provide a nicer space to talk about the
purpose of the provided information rather than squirreling it away in
a corner of the sys module docs

4. "python -m sysconfig" provides a useful dump of the system status

5. The API design did not get much *new* thought, as the idea was to
allow users to do anything that the old distutils.sysconfig could do,
but without requiring them to depend on distutils to get that
functionality. The easiest way to ensure that is to just copy the
existing API rather than trying to get creative. Don't think of it as
adding a "whole new module", thinking of it as decoupling a relatively
small existing module (i.e. distutils.sysconfig) from a larger package
that isn't installed by default on all systems (i.e. distutils).

A concrete problem with Raymond's idea in particular is that there is
actually a full set of paths defined for *each scheme*. get_path() and
get_paths() let you ignore this most of the time, since there is an
appropriate default scheme defined for each platform, so they just use
that if you don't specify one explicitly. A named tuple could
obviously expose the paths for all of the schemes, with the paths for
the default scheme duplicated at the top level, but the data structure
starts looking very messy at that point. The named tuple idea also
conflates meta-data about the sysconfig data (the list of scheme names
and path names) with the actual data for the current platform
(platform, version, paths, config_vars).

So I think reusing the tried and tested API is easily justified in
this case. What may be desirable in 3.3 (particularly with the
distutils2 reintegration taking place), is to revisit the sysconfig
API to see if there are better ways to expose some of the data (such
as a function returning a named tuple containing the raw data
underlying the output of "python -m sysconfig").


Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
________________...

Python-Dev mailing list
Python-Dev at python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20101211/39dc0c69/attachment.html>