Could someone please add Lars Gustaebel (SF ID "gustaebel") as a
developer? He's responsible for writing and maintaining tarfile.py,
but his bugfixes usually sit around in the tracker until someone gets
around to looking at them, which is inefficient.
Thanks!
--amk
A few weeks ago, the suggestion was made on Python-Dev that it might be time
to consider replacing the ConfigParser module and that we should hold a
"shootout" (ie ask for implementations and see what we get).
Since then I've been playing around with this... not the parsing part (which
so far I have completely ignored) but the programmer interface. There needs
to be a well-thought-out data model for the information stored, and the user
interface needs to be very easy to use, yet not so "magical" that it becomes
difficult to understand.
I have put together what I think is probably my best proposal. It is based
on a superset of ini config files and java .property files. There is a
convenient access mechanism ("config.my_app.some_value") as well as more
general approaches ("config.values['my_app.serviceByPort.80']"). I have
tried to consider issues like unicode (I permit fairly lenient mixing of
unicode and str), and unit testing ("... call config.clear_all() in the
tearDown() method of any unittests that use the config module..."). I have
even considered carefully what to leave OUT (converting to non-string data
types, interpolating values, things like that).
I think that I am now at the point where I could really use some input from
others. So I'd like to invite people to review my design and send me your
suggestions. I'm not expecting this as a *useful* module yet (it doesn't
yet parse files!), but it seemed like a good stage at which to ask for
feedback. I'm attaching two files, config.py and configTest.py, and they
are also available from these urls:
http://www.mcherm.com/publish/2004-10-17/config.pyhttp://www.mcherm.com/publish/2004-10-17/configTest.py
Thanks in advance for reviewing this.
-- Michael Chermside
Hello!
I submitted a number of patches to the SF tracker. Few of them were
accepted, but most of them still are unreviewd by core team.
What can I do to help? (A polite way to say "how can I push them?" :)
I have updated them to Python 2.4b1. Actually, only one of them
required minor changes (different line numbers). But I must admit that
the patches are not a simple bug fix, so it is probably too late to
apply them for 2.4. They can wait for 2.5... but I am afraid they will
be just forgotten.
The patches are:
http://python.org/sf/754022
This is the biggest and the oldest. It hangs in the tracker since
Python 2.2. In short, it makes the webbrowser.py runs through _tryorder
list of browsers and trie to run every browser until one started
successfully. Currently webbrowser.py tries to run a browser and if it
fails - stops trying. Assigned to Fred Drake.
http://python.org/sf/784089
A program to scan python files and list those require -*- coding -*-
directive. Reviewed by Marc-Andre Lemburg and Andrew Kuchling.
http://python.org/sf/821862
Makes ftplib.py a bit more RFC959-compliant. The RFC requires the FTP
protocol to be run not over TCP but over telnet. For most people there
is no difference but there is a subtle different for those who use
non-ASCII encodings: chr(255) - a special character in telnet - requires
a special handling. My patch adds a toggle that allows to turn telnet on
(actually, it only doubles chr(255) in command stream, but it is one of
two things that are required for FTP-over-telnet). By default it is off
to preserve backward compatibility.
http://python.org/sf/1038388
The smallest and the simplest of all. 3 lines patch that adds
__main__ to whichdb.py, so one can run it on the command line:
$ whichdb.py *.db
Oleg.
--
Oleg Broytmann http://phd.pp.ru/ phd(a)phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
On Sun, Oct 17, 2004 at 03:38:11PM -0700, Michael Chermside wrote:
> My apologies, my previous email was intended to go to python-list, not
> python-dev. I didn't intend to bother this list with it until it was
> at a point where I thought it was a contender for inclusion. Sometimes
> I really wish there was an "Unsend" option for email.
I think it raised a point though - there were a few wildly different
ideas about what ConfigParser's replacement should be. Would it be wise
to discuss first what ConfigParser is *supposed* to be, and where it
fits in peoples' applications?
If this hits a chord with you, pump your reply button and discuss!
If you look at the current ConfigParser, you might find the following:
- It is a simple storage method for text data that categorises sets
of keys with sets of values.
- Its backend format is simple and fast for other tools to parse
(even for on-request applications, like web scripts).
- For almost any complex data, it becomes immediately less useful,
but with a small amount of external wrapping, can also be used for
more complex configuration structures.
- It is *not* a means for declaring objects or doing sums: that is
what the Python syntax itself is for.
My problems with the current ConfigParser are as follows:
- The interface is unfriendly and error-prone. Examples:
- read(): raises no exception if a file is missing. This is
against Python culture, and the unsurprising name causes IMHO
surprising behaviour, especially for the standard library.
- readfp(): 'more than one way to do it'. File-like objects are such
a fundamental part of Python that I think read() should go
away entirely.
This would mean that a programmer is explicitly reminded of
the errors that can occur when opening his configuration file
as he explicitly types the file() factory expression himself.
- Again, for getting values there are a few methods which
essentially repeat themselves - getint(), getfloat(), etc.
What is wrong with int(obj.get(...))?
- get() shares the same method name as the infinitely popular
dict.get() method, yet does not support a <default> argument.
- String interpolation! There is a friendly string syntax as a
standard library feature these days, and less friendly
interpolation has always existed in the language itself. This
should go, and be made more explicit for the programmer.
In my opinion we should differenciate at an early stage between complex
processing tasks (Python itself) and storing random snippets of
configuration data.
In short, removing the functions that really shouldn't be there and
modernizing the code, would be a good starting place for a replacement.
Only then we can start talking about ConfigParser-NG.
Thanks,
David.
--
Now that my house has burned down I have a much better view of the moon.
Dear community,
I would love to publish Stackless 3.1, of course.
Also I know that there is some inherent bug in it.
I'm seeking a person who would take the job to
find the buglet. He would need to debug and
nail down a commercial application, which I cannot
make public. (S)He would need to sign an NDA with me.
The success payment would be $500. If the problem
shows up to be very hard (to some undefined definition
of very hard, to be negotiated), it can be increased
to $1000.
If my app works afterwards, Stackless 3.1 is just fine.
If it doesn't work, no payment happens.
The identified problem needs to be documented by a
reprodicuble test case.
If somebody is interested, please contact me privately.
And be aware, this is really no easy stuff. You need to
be a real hardcore system hacker with many years of
experience.
Here is the CVS path to the dev trunk:
CVSROOT=:pserver:anonymous@stackless.com:/home/cvs
cvs co slpdev/src/2.3/dev
The cheapest complete solution wins. Hurry up :-)
Sincerely -- chris
--
Christian Tismer :^) <mailto:tismer@stackless.com>
tismerysoft GmbH : Have a break! Take a ride on Python's
Carmerstr. 2 : *Starship* http://starship.python.net/
10623 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 31 86 04 18 home +49 30 802 86 56 mobile +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
[From Mail to python-announce list]
> I'd like to give you an updated status report of the popen5 project. Since
> my last post at 2004-06-04, this has happened:
...
> With these changes, the subprocess module now feels quite complete. In the
> near future, I will focus on getting the module included in the standard
> library.
I've recieved very positive feedback on my module. Many users are also
asking me if this module will be included in the standard library. That
is, of course, my wish as well.
So, can the subprocess module be accepted? If not, what needs to be done?
/Peter Åstrand <astrand(a)lysator.liu.se>
Martin wrote:
> Also, upgrading from 2.4a3 (with extensions installed) to 2.4b1
> (with no extensions) would have the same effect - there is simply
> no support for restoring older versions of the extensions when
> uninstalling (and upgrading from 2.4a3 to 2.4b1 is actually the
> same as uninstalling 2.4a3 first).
this appears to be exactly the case with me, I run both the 2.3 and
2.4 branches on the same box... and I upgraded py2.4a3 to py2.4b1.
the funny thing is that when I installed Py2.4a3 some time back all
went well. this time the installer restored the last setup options
(except the setup dir... I do not use %systemdrive%\python24\) and
removed ALL file associations, including for Py2.3.4, and messed up
the overall python registry configuration! (which is quite odd....).
--
Alex.
