[Python-Dev] API for the new sysconfig module (original) (raw)

Tarek Ziadé ziade.tarek at gmail.com
Sat Dec 11 09:26:35 CET 2010

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>

More information about the Python-Dev mailing list