I tested and tried a few XML validators but none of them is able to successfully
validate a string of xml (not a file just a string) to programatically be able
to validate messages of xml that flow in and out of the different systems.
Teh validators I used were XSV, oNVDL and lxml, can we implement a pure python
module for validating strings of xml using XML Schema (not DTD).
lxml is good but not written in python and difficult to install and didn't work
on MacOS X.
XSV very poor documentation and only validates xml files not strings.
oNVDL not writtem in python and only validates xml files not strings.
I ran LLVM's under-development C front-end, clang
(http://clang.llvm.org), against Python today. While a ton of message
crop up thanks to lacking header files, I did come across a handful of
semi-useful warnings (e.g., the change I checked into
One thing it picked up is that on OS X Python/strerror.c disagrees
with the declaration of sys_nerr and such. But then I thought I
remembered strerror() being in C89. I checked configure-in to make
sure that it wasn't special for some reason, it it isn't; only used
when the function is not normally available. Same goes for memmove().
Since both strerror() and memmove() are both in C89 (they are listed
in K&R), can we ditch these files?
A question.... Do you know if OpenSSL's applink.c will be included in
the Windows builds? If so, and I hope it is, great!
If not, I'd like to encourage its inclusion. Doing so will permit
Python to be used with OpenSSL 0.9.8x on Windows platforms without a
user trying to find somebody with the right compiler to rebuild a Python
for him/her. This is needed for M2Crypto, or any other OpenSSL wrapper
for that matter. A lot more can be said here, but in the interest of
applink.c is perhaps two dozen links and some error codes, and is benign
for those not calling these APIs. applink.c may be found in
<openssl_source_dir>/ms and the one line include stmt that would be
added to <py-src>/Modules/python.c is:
And the OpenSSL FAQ: http://www.openssl.org/support/faq.html#PROG2
Along with the release of 2.5.2, I would also like to release
new versions of 2.3 and 2.4. These will be security-only releases,
and include a few security-relevant bug fixes that are still being
As we don't have the infrastructure to produce full releases of 2.3
or 2.4 anymore, this will be a source release only. As such, it
will likely see less testing than other releases, and users will have
more difficulties in obtaining the software for their system - the
releases will be targeted primarily at system vendors who can chose
to include them as security patches in their system updates.
As a consequence, I would like to roll back all changes from the 2.3
and 2.4 branches which aren't security fixes. In specific cases, the
nature of a change might be debatable; clear security fixes are
prevention of memory corruption and interpreter crashes, clear
non-security fixes are documentation and test-suite changes.
For 2.3, there are only few revisions that would be rolled back:
r52798, r52803, r52824, r54342.
For 2.4, the list is longer; all changes on the branch since
r52382 are candidate for roll-back. I would like to prepare
a white-list of patches that should be preserved; if you think
any of the patches committed in the 2.4 branch is a security
fix, please let me know.
I'm going through the motions of getting my newly added build slave in a half decent state. The external.bat and external-amd64.bat files needed the following in order to build db-4.4.20:
--- external.bat (revision 61125)
+++ external.bat (working copy)
@@ -10,7 +10,8 @@
@rem Sleepycat db
if not exist db-4.4.20 svn export http://svn.python.org/projects/external/db-4.4.20
if not exist db-4.4.20\build_win32\debug\libdb44sd.lib (
- vcbuild db-4.4.20\build_win32\Berkeley_DB.sln /build Debug /project db_static
+ devenv /upgrade db-4.4.20\build_win32\Berkeley_DB.sln
+ devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug /project db_static
(This is against trunk, same thing would apply to py3k I guess, given that we're using %VS90COMNTOOLS%vsvars32.bat there too.)
When are you planing to freeze the code of the trunk and branches/py3k
for the upcoming alpha releases? I'll merge the last modifications from
2.6 to 3.0 in a couple of minutes. All tests on Linux are looking good,
except for the two profile tests on 3.0. I'm going to test Windows later.
I want a pdf. The above link says:
"To download an archive containing all the documents for this version of
Python in one of various formats, follow one of links in this table. "
But there are no links.
Christian Heimes wrote:
> Is this documented somewhere? The docs say "See the
> :meth:`__getattribute__` method below for a way to actually get total
> control over attribute access.".
I just checked, and the restriction is now documented in the development
docs in the section on special methods at . It was backported from
the Py3k docs and isn't part of the docs for 2.5 or earlier versions.
The gist is that special methods *must* be defined directly on a
new-style class in order for the interpreter to reliably access them,
but defining them on a new-style instance *may* still affect the
interpreter's behaviour in some cases (but won't necessarily do so).
In composing this response, I also realised why the new tempfile tests
worked for me before I checked them in: I was testing it on the trunk,
where _TemporaryFileWrapper is a classic class. Special method lookup on
classic classes doesn't include the 'direct-to-type' optimisation, so
those tests work with the tempfile module as written on 2.x.
Unfortunately, proxies like _TemporaryFileWrapper that rely on
__getattr__ to provide special methods simply won't work properly when
implemented as new-style classes - for that, they need to spell out the
overridden special methods the way SpooledTemporaryFile does.
I think we may need a -3 warning that detects situations where "__*__"
attributes are retrieved via a __getattr__ implementation on a classic
class - classes being used that way have a very high chance of breaking
when ported to 3.0 and I can't see any possible way for 2to3 to detect them.
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia