Re: [Python-Dev] API for the new sysconfig module
Wiadomość napisana przez Raymond Hettinger w dniu 2010-12-11, o godz. 22:18: *(I sometimes lose track of which changes were made in both branches pre-2.7, which ones were mode post-2.7 release, and which ones went in pre-2.7, but were 3.x only regardless) Right. I missed that it was already in 2.7. So, now we're stuck with it, forever. Why not deprecate it for 3.2 (easy since it's probably not yet used anywhere anyway, even in 2.7) and introduce sys.sysconfig. I really like that much better than Java-like accessor functions. -- Best regards, Łukasz Langa tel. +48 791 080 144 WWW http://lukasz.langa.pl/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for the new sysconfig module
On Sun, 12 Dec 2010 13:01:42 +0100 Łukasz Langa luk...@langa.pl wrote: Wiadomość napisana przez Raymond Hettinger w dniu 2010-12-11, o godz. 22:18: *(I sometimes lose track of which changes were made in both branches pre-2.7, which ones were mode post-2.7 release, and which ones went in pre-2.7, but were 3.x only regardless) Right. I missed that it was already in 2.7. So, now we're stuck with it, forever. Why not deprecate it for 3.2 (easy since it's probably not yet used anywhere anyway, even in 2.7) and introduce sys.sysconfig. We already had a lot of churn around these APIs (distutils friends). I don't think it's a good idea to introduce even more churn. Oh and by the way it's too late to add or remove features from 3.2. I really like that much better than Java-like accessor functions. Do you actually use sysconfig yourself? It's quite a specialized module, and I don't think API elegance arguments have a great weight here. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for the new sysconfig module
On Dec 12, 2010, at 02:42 PM, Antoine Pitrou wrote: On Sun, 12 Dec 2010 13:01:42 +0100 Łukasz Langa luk...@langa.pl wrote: Wiadomość napisana przez Raymond Hettinger w dniu 2010-12-11, o godz. 22:18: *(I sometimes lose track of which changes were made in both branches pre-2.7, which ones were mode post-2.7 release, and which ones went in pre-2.7, but were 3.x only regardless) Right. I missed that it was already in 2.7. So, now we're stuck with it, forever. Why not deprecate it for 3.2 (easy since it's probably not yet used anywhere anyway, even in 2.7) and introduce sys.sysconfig. We already had a lot of churn around these APIs (distutils friends). I don't think it's a good idea to introduce even more churn. Oh and by the way it's too late to add or remove features from 3.2. I really like that much better than Java-like accessor functions. Do you actually use sysconfig yourself? It's quite a specialized module, and I don't think API elegance arguments have a great weight here. I have used them and I do think they're fairly ugly and unwieldy. However, I agree that we should not rush into a different design. Since sysconfig was essentially refactored out of distutils (and now we have two ways to do it!), and we're getting distutils2 for 3.3, I think it would be better to work out a more natural design for sysconfig for 3.3. Then the sysconfig module can go through the natural deprecation cycle. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for the new sysconfig module
On Sun, Dec 12, 2010 at 11:42 PM, Antoine Pitrou solip...@pitrou.net wrote: I really like that much better than Java-like accessor functions. Do you actually use sysconfig yourself? It's quite a specialized module, and I don't think API elegance arguments have a great weight here. I would also like those advocating replacement of a tried and tested API with oh, you can just use a single function for it to rewrite distutils2 and the other tools that currently used distutils.sysconfig based on their single function approach before *anything* gets touched. This is not an API that was invented on a whim. It is well-established, with existing use cases that are essential to the wider Python ecosystem, and are more easily managed on some Linux distributions if they don't involve a dependency on distutils. Proposing to throw it away in favour of an ill-defined single function that indiscriminately mixes system data with metadata about that data because some people that don't even use the module find it aesthetically displeasing seems... unwise. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for the new sysconfig module
Lukasz Langa luk...@langa.pl wrote: Wiadomość napisana przez Raymond Hettinger w dniu 2010-12-11, o godz. 22:18: Right. I missed that it was already in 2.7. So, now we're stuck with it, forever. Why not deprecate it for 3.2 (easy since it's probably not yet used anywhere anyway, even in 2.7) and introduce sys.sysconfig. I really like that much better than Java-like accessor functions. When I use sysconfig, I just want to get things done as quickly and painlessly as possible. The API suits me just fine (in fact, I find it one of the APIs that are easy to remember). Given that sysconfig will always contain a certain amount of hackery and will always change to accommodate new systems, I'd prefer that it remains a standalone module. Stefan Krah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for the new sysconfig module
On Sun, Dec 12, 2010 at 3:05 PM, Barry Warsaw ba...@python.org wrote: On Dec 12, 2010, at 02:42 PM, Antoine Pitrou wrote: On Sun, 12 Dec 2010 13:01:42 +0100 Łukasz Langa luk...@langa.pl wrote: Wiadomość napisana przez Raymond Hettinger w dniu 2010-12-11, o godz. 22:18: *(I sometimes lose track of which changes were made in both branches pre-2.7, which ones were mode post-2.7 release, and which ones went in pre-2.7, but were 3.x only regardless) Right. I missed that it was already in 2.7. So, now we're stuck with it, forever. Why not deprecate it for 3.2 (easy since it's probably not yet used anywhere anyway, even in 2.7) and introduce sys.sysconfig. We already had a lot of churn around these APIs (distutils friends). I don't think it's a good idea to introduce even more churn. Oh and by the way it's too late to add or remove features from 3.2. I really like that much better than Java-like accessor functions. Do you actually use sysconfig yourself? It's quite a specialized module, and I don't think API elegance arguments have a great weight here. I have used them and I do think they're fairly ugly and unwieldy. However, I agree that we should not rush into a different design. Since sysconfig was essentially refactored out of distutils (and now we have two ways to do it!), and we're getting distutils2 for 3.3, I think it would be better to work out a more natural design for sysconfig for 3.3. Then the sysconfig module can go through the natural deprecation cycle. I don't think any API refactoring worth the pain here. I don't see the proposed changes make the caller's code that much better. The existing one is good enough in my opinion. Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for the new sysconfig module
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 ncogh...@gmail.com wrote: On Sat, Dec 11, 2010 at 7:59 AM, R. David Murray rdmur...@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 | ncogh...@gmail.com | Brisbane, Australia ... Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Uns... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for the new sysconfig module
On Sat, 11 Dec 2010 12:55:25 +1000 Nick Coghlan ncogh...@gmail.com wrote: On Sat, Dec 11, 2010 at 12:44 PM, Terry Reedy tjre...@udel.edu wrote: On 12/10/2010 4:59 PM, R. David Murray wrote: Like Éric, I'm not sure what the implications of the existing module having been released in 2.7 and 3.2 beta are in terms of making such an API change. I am with Raymond on this: the purpose of betas is so we can test *and* make changes. No one should base production software on a beta release. It's also the key difference between betas and release candidates. Seems that both you and Terry have missed the part where the sysconfig API is already part of 2.7, though. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for the new sysconfig module
On Sun, Dec 12, 2010 at 12:17 AM, Antoine Pitrou solip...@pitrou.net wrote: On Sat, 11 Dec 2010 12:55:25 +1000 Nick Coghlan ncogh...@gmail.com wrote: On Sat, Dec 11, 2010 at 12:44 PM, Terry Reedy tjre...@udel.edu wrote: On 12/10/2010 4:59 PM, R. David Murray wrote: Like Éric, I'm not sure what the implications of the existing module having been released in 2.7 and 3.2 beta are in terms of making such an API change. I am with Raymond on this: the purpose of betas is so we can test *and* make changes. No one should base production software on a beta release. It's also the key difference between betas and release candidates. Seems that both you and Terry have missed the part where the sysconfig API is already part of 2.7, though. I had missed that, yes*. I suspect Raymond may have missed it as well. Cheers, Nick. *(I sometimes lose track of which changes were made in both branches pre-2.7, which ones were mode post-2.7 release, and which ones went in pre-2.7, but were 3.x only regardless) -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for the new sysconfig module
On Dec 11, 2010, at 9:21 AM, Nick Coghlan wrote: On Sun, Dec 12, 2010 at 12:17 AM, Antoine Pitrou solip...@pitrou.net wrote: On Sat, 11 Dec 2010 12:55:25 +1000 Nick Coghlan ncogh...@gmail.com wrote: On Sat, Dec 11, 2010 at 12:44 PM, Terry Reedy tjre...@udel.edu wrote: On 12/10/2010 4:59 PM, R. David Murray wrote: Like Éric, I'm not sure what the implications of the existing module having been released in 2.7 and 3.2 beta are in terms of making such an API change. I am with Raymond on this: the purpose of betas is so we can test *and* make changes. No one should base production software on a beta release. It's also the key difference between betas and release candidates. Seems that both you and Terry have missed the part where the sysconfig API is already part of 2.7, though. I had missed that, yes*. I suspect Raymond may have missed it as well. Cheers, Nick. *(I sometimes lose track of which changes were made in both branches pre-2.7, which ones were mode post-2.7 release, and which ones went in pre-2.7, but were 3.x only regardless) Right. I missed that it was already in 2.7. So, now we're stuck with it, forever. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for the new sysconfig module
Hi, Original discussion for the sysconfig module was short: http://mail.python.org/pipermail/python-dev/2009-May/089520.html Tarek will reply better, but I think the issue to solve was to move sysconfig out of distutils, improving its API a bit in the process but not overhauling it completely. A single function returning a nested dictionary could be added if deemed useful, but to me the existing API separates concerns (paths and variables for example) without being confusing nor having too many names. Exceptions: get_python_version could be removed; get_scheme_names and get_path_names could be replaced by constants. Maybe Tarek chose accessors to keep freedom for later, or just for consistency. sysconfig being new in 2.7 and 3.2, I don’t know how compatibility concerns apply. I think it would be bad to have highlighted the new module in 2.7 and then remove it in 3.2, since 2.6 and 2.7 have the goal of helping people moving to 3.x. Also, I don’t see where those 800 lines of code would live if the sysconfig module is removed; maybe in platform, which is already long? (it could be made smaller with some code modernization, removal of the popen function, but not much smaller). Final note: with 3.2 being in beta, I don’t know how much can be changed now. The old way required source code available ability at runtime, the new sysconfig module captures everything it needs at build time. Not yet :) See http://bugs.python.org/issue9878 Regards ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for the new sysconfig module
On Dec 10, 2010, at 6:20 AM, Éric Araujo wrote:
Final note: with 3.2 being in beta, I don’t know how much can be changed
now.
Part of the purpose of a beta, and in our case, two betas is to give
people a chance to exercise new APIs and fix them before they
become set in stone two months later.
IMO, sysconfig did not warrant a whole module. The pile of
awkward accessor functions is harder to learn / remember
than the simple data structure shown in the last email.
Rather than using two levels of dictionary, it's also possible
to use a named tuple if you think that is more clean looking:
c = sys.sysconfig()
c.config_vars.get('SO)
'.pyd'
c.platform
'win32'
c.paths.get('stdlib')
'C:\\Python32\\Lib'
# the named tuple fields:
c.fields
['config_vars', 'platform', 'version', 'scheme_names', 'paths']
This would be a straight-forward API that uses existing, well-known
tools (attribute access and dict.get) instead of an unnecessary
nest of ad-hoc accessor functions living in a new module.
Tastes may vary on writing getter functions for every category
of interest but we did not need a whole new module for this.
The referenced email didn't indicate much if any thought about
the API design, so I think should get that thought now.
If those functions were already public in distutils, it is trivial
to write an adapter for them there.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for the new sysconfig module
On Fri, 10 Dec 2010 12:27:26 -0800
Raymond Hettinger raymond.hettin...@gmail.com wrote:
IMO, sysconfig did not warrant a whole module.
Where would you put it?
Rather than using two levels of dictionary, it's also possible
to use a named tuple if you think that is more clean looking:
c = sys.sysconfig()
c.config_vars.get('SO)
'.pyd'
Some of these things are computed at runtime by parsing makefiles and
other stuff. You don't want to do it as soon as the module is imported.
There may also be some bootstrap issues when importing some of the
necessary modules from the top level.
The current API is fine IMO. Perhaps it could be refined a bit, but
there's nothing horrendous. It's not for everyone to use; creating
dict-like classes over these APIs would be a terrible waste of time,
and add a useless maintenance burden.
If those functions were already public in distutils, it is trivial
to write an adapter for them there.
The whole point was to separate them from distutils.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for the new sysconfig module
On Dec 10, 2010, at 12:56 PM, Antoine Pitrou wrote:
On Fri, 10 Dec 2010 12:27:26 -0800
Raymond Hettinger raymond.hettin...@gmail.com wrote:
IMO, sysconfig did not warrant a whole module.
Where would you put it?
A single function in the sys module.
Rather than using two levels of dictionary, it's also possible
to use a named tuple if you think that is more clean looking:
c = sys.sysconfig()
c.config_vars.get('SO)
'.pyd'
Some of these things are computed at runtime by parsing makefiles and
other stuff. You don't want to do it as soon as the module is imported.
The proposal is for a function that does the computation when invoked,
not when imported. The function returns a named tuple so that we can
use Python's builtin accessors like attributes and dict.get().
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for the new sysconfig module
On Thu, 09 Dec 2010 16:18:14 -0800, Raymond Hettinger raymond.hettin...@gmail.com wrote: Does anyone know why this needed a separate module and so many accessor functions? Originally sysconfig was moved *out* of distutils, and distutils was changed to use it. But that proved to be as fragile as many other distutils changes. When distutils was reverted, sysconfig was kept because of the long term desire to move it out of distutils. At that point I think it would have been very easy to propose API changes, but I suppose it didn't occur to anyone to think about that possibility. ISTM it mostly could have been reduced to single call returning a nested dictionary. If what was returned was, as you suggested on IRC, a set of named tuples, it seems to me that would be a very convenient interface. And since all values (as I understand it) are intended to be static (even if some aren't at the moment), it seems to make sense from an implementation standpoint as well. Like Ãric, I'm not sure what the implications of the existing module having been released in 2.7 and 3.2 beta are in terms of making such an API change. -- R. David Murray www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for the new sysconfig module
On 12/10/2010 4:59 PM, R. David Murray wrote: Like Éric, I'm not sure what the implications of the existing module having been released in 2.7 and 3.2 beta are in terms of making such an API change. I am with Raymond on this: the purpose of betas is so we can test *and* make changes. No one should base production software on a beta release. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for the new sysconfig module
On Sat, Dec 11, 2010 at 7:59 AM, R. David Murray rdmur...@bitdance.com wrote: On Thu, 09 Dec 2010 16:18:14 -0800, Raymond Hettinger raymond.hettin...@gmail.com wrote: ISTM it mostly could have been reduced to single call returning a nested dictionary. If what was returned was, as you suggested on IRC, a set of named tuples, it seems to me that would be a very convenient interface. And since all values (as I understand it) are intended to be static (even if some aren't at the moment), it seems to make sense from an implementation standpoint as well. Like Éric, I'm not sure what the implications of the existing module having been released in 2.7 and 3.2 beta are in terms of making such an API change. 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 | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for the new sysconfig module
On Sat, Dec 11, 2010 at 12:44 PM, Terry Reedy tjre...@udel.edu wrote: On 12/10/2010 4:59 PM, R. David Murray wrote: Like Éric, I'm not sure what the implications of the existing module having been released in 2.7 and 3.2 beta are in terms of making such an API change. I am with Raymond on this: the purpose of betas is so we can test *and* make changes. No one should base production software on a beta release. It's also the key difference between betas and release candidates. Completely new features are still out after the first beta, but tweaking the APIs of new-in-this-release features is still possible with sufficient justification. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] API for the new sysconfig module
Does anyone know why this needed a separate module and so many accessor
functions?
ISTM it mostly could have been reduced to single call returning a nested
dictionary.
Raymond
from sysconfig import *
import json
def sysconf():
return dict(paths = get_paths(),
config_vars = get_config_vars(),
platform = get_platform(),
version = get_python_version(),
scheme_names = get_scheme_names(),
)
print(json.dumps(sysconf(), indent=2))
{
config_vars: {
EXE: .exe,
VERSION: 32,
py_version_nodot: 32,
exec_prefix: C:\\Python32,
platbase: C:\\Python32,
userbase: C:\\Documents and Settings\\Raymond\\Application
Data\\Python,
LIBDEST: C:\\Python32\\Lib,
py_version_short: 3.2,
prefix: C:\\Python32,
base: C:\\Python32,
SO: .pyd,
projectbase: C:\\Python32,
BINLIBDEST: C:\\Python32\\Lib,
srcdir: C:\\Python32,
py_version: 3.2b1,
abiflags: ,
INCLUDEPY: C:\\Python32\\Include,
BINDIR: C:\\Python32
},
platform: win32,
version: 3.2,
scheme_names: [
nt,
nt_user,
os2,
os2_home,
osx_framework_user,
posix_home,
posix_prefix,
posix_user
],
paths: {
platinclude: C:\\Python32\\Include,
platstdlib: C:\\Python32\\Lib,
platlib: C:\\Python32\\Lib\\site-packages,
purelib: C:\\Python32\\Lib\\site-packages,
stdlib: C:\\Python32\\Lib,
scripts: C:\\Python32\\Scripts,
include: C:\\Python32\\Include,
data: C:\\Python32
}
}
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for the new sysconfig module
On Fri, Dec 10, 2010 at 10:18 AM, Raymond Hettinger raymond.hettin...@gmail.com wrote: Does anyone know why this needed a separate module and so many accessor functions? ISTM it mostly could have been reduced to single call returning a nested dictionary. Tarek will likely answer for himself, but I believe it is a matter of providing like-for-like replacements of existing distutils APIs, specifically: http://docs.python.org/dev/distutils/apiref.html#module-distutils.sysconfig The old way required source code available ability at runtime, the new sysconfig module captures everything it needs at build time. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
