Mailman 3 December 2009 - Python-Dev

First draft of "sysconfig"
by Tarek Ziadé Jan. 1, 2010

Jan. 1, 2010

Hello, A while ago I've proposed to refactor the APIs that provides access to the installation paths and configuration variables at runtime into a single module called "sysconfig", and make it easier for all implementations to work with them. I've started a branch and worked on it, and I'd like to ask here for some feedback. And in particular from Jython and IronPython people because they would probably need to work in that file for their implementation and/or propose things to add. My … [View More]understanding is that we have people like Phillip (Jenvey), Michael F., Frank W. in this list so they can comment directly and I don't need to cross-post this mail elsewhere. == Installation schemes == First, the module contains the installation schemes for each platform CPython uses. An install scheme is a mapping where the key is the "code" name for a directory, and the value the path of that directory, with some $variable that can be expanded. Install schemes are stored in a private mapping, where the keys are usually the value of os.name, and the value, the mapping I've mentionned earlier. So, for example, the paths for win32 are: _INSTALL_SCHEMES = { ... 'nt': { 'stdlib': '$base/Lib', 'platstdlib': '$base/Lib', 'purelib': '$base/Lib/site-packages', 'platlib': '$base/Lib/site-packages', 'include': '$base/include', 'platinclude': '$base/include', 'scripts': '$base/Scripts', 'data' : '$base', }, ... } where each key corresponds to a directory that contains some Python files: - stdlib : root of the standard library - platstdlib: root of platform-specific elements of the standard library - purelib: the site-packages directory for pure python modules - platlib: the site-packages directory for platform-specific modules - include: the include dir - platinclude: the include dir for platform-specific files - scripts: the directory where scripts are added - data: the directory where data file are added All these directory are read and used by: - distutils when a package is installed, so the install command can dispatch files in the right place - site.py, when Python is initialized IOW, any part of the stdlib can use these paths to locate and work with Python files. The public APIs are: * get_path_names() : returns a list of the path names ("stdlib", "platstdlib", etc.) * get_paths(scheme, vars) : Returns a mapping containing an install scheme. - "scheme" is the name of the scheme, if not provided will get the default scheme of the current platform - vars is an optonal mapping that can provide values for the various $variables. Notice that they all have default values, for example $base == sys.prefix. for example: get_paths('nt') * get_path(name, scheme, vars): Returns one path corresponding to the scheme. for example : get_paths('stdlib', 'nt') Those API are generic, but maybe we could add specific APIs like: * get_stdlib_path('nt') These API are basically a refactoring of what already exist in distutils/command/install.py == Configuration variables == distutils.sysconfig currently provides some APIs to read values from files like Makefile and pyconfig.h. These API have been placed in the global sysconfig module: * get_config_vars(): return a dictionary of all configuration variables relevant for the current platform. * get_config_var(name): Return the value of a single variable * get_platform(): Return a string that identifies the current platform. (this one is used by site.py for example) * get_python_version() : return the short python version (sys.version[:3]) -- this one could probably go away but is useful because that's the marker used by Python in some paths. == code, status, next steps == The code of the module can be viewed here, it's a revamp of distutils.sysconfig: http://svn.python.org/view/*checkout*/python/branches/tarek_sysconfig/Lib/s… I've refactored distutils/ and site.py so they work with this new module, and added deprecation warnings in distutils.sysconfig. All tests pass in the branch, but note that the code is still using the .h and Makefile files. This will probably be removed later in favor of a static _sysconfig.py file generated when Python is built, containing the variables sysconfig reads. I'll do this second step after I get some feedback on the proposal. Regards Tarek -- Tarek Ziadé | http://ziade.org [View Less]

15 36

Rough 3.2 release schedule
by Georg Brandl Dec. 31, 2009

Dec. 31, 2009

... is in PEP 392. Nothing much to see, except that the final date is December 11, 2010. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

3 3

PyCon Early Bird is Ending Soon!
by VanL Dec. 29, 2009

Dec. 29, 2009

Do you have a year-end hole in your training budget? Or will the improved economy let you finally attend a work conference? Come to sunny and warm Atlanta in February for PyCon 2010. Early bird registration ends on January 6. Register: https://us.pycon.org/2010/register/ See the talks: http://us.pycon.org/2010/conference/talks/ Get trained at a tutorial: http://us.pycon.org/2010/tutorials/ Also see the five (or more!) talks that people can't miss at PyCon: PyOraGeek: PyCon pre-favorites &… [View More]

1 0

Proposing PEP 386 for addition
by Tarek Ziadé Dec. 29, 2009

Dec. 29, 2009

Hello, On behalf of the Distutils-SIG, I would like to propose PEP 386 for inclusion in the sdtlib, and have a final discussion here on Python-dev. http://www.python.org/dev/peps/pep-0386 This PEP has been discussed for some time in Distutils-SIG, and we agreed there that it's important to have it accepted for the future of packaging because: 1/ it will offer interoperability for all Python package managers out there. (namely: Distutils, Distribute, Setuptools, Pip, PyPM) 2/ it will provide … [View More]

13 26

Disallow float arguments where an integer is expected in Python 2.7.
by Mark Dickinson Dec. 28, 2009

Dec. 28, 2009

In Python 2.7, PyArg_ParseTuple and friends currently accept a float argument where an integer is expected, but produce a DeprecationWarning in this case. This can be seen in various places in Python proper: >>> itertools.combinations(range(5), 2.0) __main__:1: DeprecationWarning: integer argument expected, got float <itertools.combinations object at 0x10059f638> Are there any objections to turning this DeprecationWarning into a TypeError for Python 2.7? The behaviour has … [View More]

3 2

Summary of Python tracker Issues
by Python tracker Dec. 25, 2009

Dec. 25, 2009

ACTIVITY SUMMARY (12/18/09 - 12/25/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2540 open (+18) / 16858 closed (+17) / 19398 total (+35) Open issues with patches: 1019 Average duration of open issues: 701 days. Median duration of open issues: 458 days. Open Issues Breakdown open 2506 (+18) pending 33 ( +0) Issues Created Or Reopened (37) … [View More]

1 0

x86 osx 5 buildbot slave
by Thomas Heller Dec. 21, 2009

Dec. 21, 2009

I have to shutdown the x86 osx 5 buildbot slave permanently, because the machine is getting a new role. Martin, please remove it from the configuration. -- Thanks, Thomas

2 1

Re: [Python-Dev] [issue1644818] Allow importing built-in submodules
by Julien Danjou Dec. 19, 2009

Dec. 19, 2009

At 1261178549 time_t, Martin v. Löwis wrote: > > Is there to chance to see this *bug* fixed someday? > > Please ask on python-dev. I may be willing to revive my five-for-one offer. Not sure I really understand, but I can ask gain here: will that patch, which seems correct finally merged and get this bug closed? Cheers, -- Julien Danjou // ᐰ <julien(a)danjou.info> http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Trust no one.

5 7

Summary of Python tracker Issues
by Python tracker Dec. 18, 2009

Dec. 18, 2009

ACTIVITY SUMMARY (12/11/09 - 12/18/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2552 open (+44) / 16811 closed (+18) / 19363 total (+62) Open issues with patches: 1020 Average duration of open issues: 692 days. Median duration of open issues: 449 days. Open Issues Breakdown open 2517 (+43) pending 34 ( +1) Issues Created Or Reopened (65) … [View More]

1 0

Command line options for features in stdlib WAS: Pronouncement on PEP 389: argparse?
by Olemis Lang Dec. 15, 2009

Dec. 15, 2009

/me starting a new thread because this goes beyond argparse itself On Tue, Dec 15, 2009 at 4:34 AM, Antoine Pitrou <solipsis(a)pitrou.net> wrote: > Steven Bethard <steven.bethard <at> gmail.com> writes: >> >> Because people are continuing this discussion, I'll say again that >> argparse already supports this: > > Well I think the point is that if there is a default, the default should be > sensible and not run against expectations. +1 > It … [View More]would probably be fine not to have a default at all, too. -1 I really think that it's good to expect the same (similar) behavior when the same options is accepted by multiple commands. In the end that's a decision of the people implementing the concrete command line tool, but it is nice to rely on something like : «if you forgot, or don't remember or don't know about it then the std decision is performed» Now that you mention all this , I follow up with a comment that is more about -v switch . Most of the time I realize that command line apps have logging capabilities and should also allow different verbosity levels (e.g. -q, -s, -v, --noisy) . The good thing is that this always can be done the same way (i.e. using log levels defined in logging module ) . The not so good news is that (in practice) coders have to do it over and over every time they create a new command line app, and users might need to remember those switches if the author used different names . My suggestion is that it would be nice to identify std switches and add support for configuring the cmd-line parser and logger instance OOTB {{{ #!python import argparse import logging if __name__ == ’__main__’: # create the parser parser = argparse.ArgumentParser(description=’XXX’) # add the arguments ... # add args for verbosity level logging.add_args(parser) # parse the command line args = parser.parse_args() # configure logging -- # probably omitted if an option handles this logging.fileConfig(*cfg_args) # setup the logger instance logging.argparseConfig(getLogger('xxx'), args) }}} The same reasoning could probably be extended to other modules in stdlib (e.g. default encoding, testing, ...). It's probably a good idea to define a set of (std) command line args for std features (preferently without conflicting with existing standards ;o) and provide shortcuts to ease configuration process when building command line tools PS: This thread might also be related to the previous one about logging configuration using dicts -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Automated init. - http://bitbucket.org/osimons/trac-rpc-mq/changeset/e122336d1eb2/ [View Less]

1 0