I am working on a proposal that will add the need to have a new .cfg
file to read for a stdlib package.
This is an existing need already for distutils (with distutils.cfg).
I have a proposal: let's create a mechanism that allows a stdlib
package to store values in a central
configuration file that can be overriden by a per-user configuration file.
This file would be located in the "data" path returned by the install
scheme (see sysconfig.py for details)
so roughly : in sys.prefix for the global one, and in ~/.local/ for
the local per-user one.
Then each package would look in the local one and "update" the global
one with it if found
The files would be a configparser ini-like file, with one mandatory
section that is the name of the package or
module in the stdlib the filename
For example, if "multiprocessing" needs a configuration file, it will
be called "multiprocessing.cfg"
and have at least one section:
foo = 1
Last, the configparser (or replacer) would provide a new API called
"get_config(package_name)" that would
read the configuration and return a config object packages can work with.
A nice add-on would be to make it possible to configure the paths, so
os packagers could
drive where the cfg file should be located on their systems
Does it sounds like a good idea ?
Tarek Ziadé | http://ziade.org
Two cents: The Basedir Spec, used by free software desktop environments
like Xfce, LXDE, Rox, GNOME or KDE, proposes a scheme that would fit the
I proposed following the spec in #7175 too.
There exists a Python module to retrieve these dirs, but it’s poorly
written. I’ve been meaning to get in touch with the maintainers and
propose improvements for a while but haven’t had time yet.
A very nice thing in my opinion would be to integrate config file and
command line parsing. Logilab and others did that. Countless projects
On Fri, Feb 5, 2010 at 3:46 PM, Guido van Rossum <guido(a)python.org> wrote:
> Ping Christian. :-)
> On Fri, Feb 5, 2010 at 12:32 PM, Gerald Britton
> <gerald.britton(a)gmail.com> wrote:
>> Wow! Fast! So, since I'm not a dev and don't know the ropes, what is
>> the next step to get the method included?
>> On Fri, Feb 5, 2010 at 3:26 PM, Guido van Rossum <guido(a)python.org> wrote:
>>> On Fri, Feb 5, 2010 at 11:39 AM, Gerald Britton
>>> <gerald.britton(a)gmail.com> wrote:
>>>> In the list archives, this thread
>>>> discusses adding a clear() method to list objects, to complement those
>>>> available for sets and dictionaries. Later in the thread:
>>>> Christian Heimes provided a patch to do it and R. H. commented that
>>>> all it would take is Guido's blessing.
>>>> So, I'm wondering, can we do this? What are the steps needed to ask
>>>> this work to be blessed?
>>>> Gerald Britton
>>>> Python-ideas mailing list
>>> --Guido van Rossum (python.org/~guido)
>> Gerald Britton
> --Guido van Rossum (python.org/~guido)
Pinging Christian! (Sorry I don't have your direct email address)
Collin Winter wrote:
> On Tue, Feb 2, 2010 at 2:02 AM, M.-A. Lemburg <mal(a)egenix.com> wrote:
>> Collin Winter wrote:
>>> If such a restrictive plugin-based scheme had been available when we
>>> began Unladen Swallow, I do not doubt that we would have ignored it
>>> entirely. I do not like the idea of artificially tying the hands of
>>> people trying to make CPython faster. I do not see any part of Unladen
>>> Swallow that would have been made easier by such a scheme. If
>>> anything, it would have made our project more difficult.
>> I don't think that it has to be restrictive - much to the contrary,
>> it would provide a consistent API to those CPython internals and
>> also clarify the separation between the various parts. Something
>> which currently does not exist in CPython.
> We do not need an API to CPython's internals: we are not interfacing
> with them, we are replacing and augmenting them.
Right, and that's the idea behind making the VM pluggable: you
define the boundaries and interfaces of the components you want
to replace and then have Python redirect all calls to your
implementation by linking against your VM instead of the default
>> Note that it may be easier for you (and others) to just take
>> CPython and patch it as necessary. However, this doesn't relieve
>> you from the needed maintenance - which, I presume, is one of the
>> reasons why you are suggesting to merge U-S back into CPython ;-)
> That is incorrect. In the year we have been working on Unladen
> Swallow, we have only updated our vendor branch of CPython 2.6 once,
> going from 2.6.1 to 2.6.4. We have occasionally cherrypicked patches
> from the 2.6 maintenance branch to fix specific problems. The
> maintenance required by upstream CPython changes has been effectively
Patch level releases usually don't include any disruptive
changes to the code, so I'm not sure whether your experience
with going from 2.6.1 to 2.6.4 provides a good example of
what maintaining compatibility with Python's main line of
development really means in terms of effort.
There are a few things to consider:
* if you want to stay compatible with Python, you have to
provide updated releases of your version for every
supported Python version (including all patch level releases)
* you need to build releases with more or less the same
frequency as CPython
* you need to closely follow Python trunk development if
want to avoid lagging behind Python's releases by a few
and all this for a long period of time.
Otherwise, I don't see how you could convince users to
use your branch instead of the Python mainline version.
> We are seeking to merge with CPython for three reasons: 1) verify that
> python-dev is interested in this project, and that we are not wasting
> our time; 2) expose the codebase to a wider, more heterogenous testing
> environment; 3) accelerate development by having more hands on the
> code. Upstream maintenance requirements have had zero impact on our
I'm sure that python-dev is interested in your project.
I'm not sure whether it would be fair to go with your approach
instead of the other existing branches, such as Stackless or
How easy would it be for those projects to continue supporting
Python if U-S were to be merged into main line Python ?
> In any case, I'll be interested in reading your PEP that outlines how
> the plugin interface should work, which systems will be pluggable, and
> exactly how Unladen Swallow, WPython and Stackless would benefit.
> Let's move further discussion of this to python-ideas until there's
> something more concrete here. The py3k-jit branch will live long
> enough that we could update it to work with a plugin system, assuming
> it is demonstrated to be beneficial.
Perhaps I'll write a PEP outlining the idea in more detail.
However, without support from developers of such VMs, I don't
see much reason in trying to design something that will not
eventually get used.
I have a feeling that I'm not getting the point across:
by making it easier for VM developers to hook into the CPython
system, we'd all benefit.
VM developers could rely on a consistent interface to develop against,
python-dev would know where non-mainline VMs hook into the system
and users could choose the VM that best fits their needs.
Professional Python Services directly from the Source (#1, Feb 03 2010)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611