I noticed a few compiler warnings, when I compile Python on my amd64 with
gcc 4.0.3:
Objects/longobject.c: In function ‘PyLong_AsDouble’:
Objects/longobject.c:655: warning: ‘e’ may be used uninitialized in this function
Objects/longobject.c: In function ‘long_true_divide’:
Objects/longobject.c:2263: warning: ‘aexp’ may be used uninitialized in this function
Objects/longobject.c:2263: warning: ‘bexp’ may be used uninitialized in this function
Modules/linuxaudiodev.c: In function ‘lad_obuffree’:
Modules/linuxaudiodev.c:392: warning: ‘ssize’ may be used uninitialized in this function
Modules/linuxaudiodev.c: In function ‘lad_bufsize’:
Modules/linuxaudiodev.c:348: warning: ‘ssize’ may be used uninitialized in this function
Modules/linuxaudiodev.c: In function ‘lad_obufcount’:
Modules/linuxaudiodev.c:369: warning: ‘ssize’ may be used uninitialized in this function
Those are all fairly harmless, just the compiler can't figure out that they
are never actually used when they aren't explicitly initialized, because the
initialization happens a few functioncalls deeper into the callstack. This
one:
Python/marshal.c: In function ‘PyMarshal_ReadShortFromFile’:
Python/marshal.c:410: warning: ‘rf.end’ is used uninitialized in this function
Python/marshal.c:410: warning: ‘rf.ptr’ is used uninitialized in this function
(The linenumber is off, it should be 884)
is more of the same, except you can't tell from the function that it is a
"can never happen" situation: if PyMarshal_ReadShortFromFile() was called
with NULL as fp, it would actually use the uninitialized 'end' and 'ptr'
struct members. An assert() is probably in place here.
Should these warnings be fixed? I know Tim has always argued to fix them, in
the past (and I agree,) and it doesn't look like doing so, by initializing
the variables, wouldn't be too big a performance hit.
I also noticed test_logging is spuriously failing, and not just on my
machine (according to buildbot logs.) Is anyone (Vinay?) looking at that
yet?
--
Thomas Wouters <thomas(a)xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Hi there,
Recently, updates from MoinMoin have started getting quarantined due to sender
verification failing. On investigating the problem, it seems that an assumption
about the webmaster mailbox is incorrect:
220 bag.python.org ESMTP Postfix (Debian/GNU)
MAIL FROM: <>
503 Error: send HELO/EHLO first
HELO argon.maildefence.co.uk
250 bag.python.org
MAIL FROM: <>
250 Ok
RCPT TO: webmaster(a)python.org
553 invalid bounce (address does not send mail)
The MoinMoin instance on Python.org is sending mail as "webmaster(a)python.org".
Can somebody take a look? Or at least tell me who to contact.
Thanks,
David.
PS: Please CC me in replies as I am not currently subscribed.
--
It's never too late to have a happy childhood.
Hello all,
In the past there has been some discussion about a new module to replace
ConfigParser. Most notably at
http://wiki.python.org/moin/ConfigParserShootout
Specific issues that could be addressed include :
* Simpler API
* Nested subsections
* List values
* Storing/converting datatypes
* Config file schema
* Keeps track of order of values
Plus other issues.
I'm the (co-)author of ConfigObj -
http://www.voidspace.org.uk/python/configobj.html
This is a reasonably mature project (now in it's fourth incarnation),
and is being used in projects like `Bazaar <http://www.bazaar-ng.org/>`_
and `PlanetPlus <http://planetplus.python-hosting.com/>`_.
It occurs to me that the ConfigObj API and syntax is *almost* fully
compatible with ConfigParser.
It would be possible to extend to the ConfigObj API to be backwards
compatible with ConfigParser. This would bring the added benefits of
ConfigObj, without needing to add an extra module to the standard library.
Well nearly. ConfigObj supports config file schema with (optional) type
conversion, through a companion module called validate. This could be
included or left as an added option.
Anyway. If this stands a *chance* of acceptance, I'll write the PEP (and
if accepted, do the work - which is not inconsiderable).
Summary of ConfigObj
================
ConfigObj is a Python 2.2 compatible config file parser. It's major
feature is simplicity of use.
It reads (and writes) INI file like config files and presents the
members using a dictionary interface.
The order of keys/sections is preserved, and it allows nested
subsections to any level :
e.g. ::
key = value
[section]
key = value
[[sub-section]]
key = value
It is fully documented with a barrage of doctests.
All comments in the config file are also preserved as attributes of the
object, and will be written back out. This can be useful for including
comments in programatically generated config files.
It is integrated with a powerful validation system.
Difficulties & Differences
=================
A ConfigObj instance is a sub-class of the dictionary datatpe. This
means that the ``get`` method of ConfigParser clashes.
ConfigObj allows values in the root section (why not ?).
ConfigObj doesn't support line continuations (it does all multi-line
values through the use of triple quoted strings).
ConfigObj currently only allows '=' as a valid divider.
Creating ConfigParser (and related classes) compatibility is a big job.
Solution
=====
All of these problems (if deemed necessary) can be resolved. Either
through options, or just by extending the ConfigObj API. I'm happy to
put the work in.
Comments ?
All the best,
Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
