Martin v. Löwis a écrit :
Imbaud Pierre schrieb:
- how do I spot the version of a given library? There is a __version__
attribute of the module, is that it?
Contrary to what others have said: for modules included in the standard
library (and if using these modules, rather than using
Imbaud Pierre schrieb:
- how do I spot the version of a given library? There is a __version__
attribute of the module, is that it?
Contrary to what others have said: for modules included in the standard
library (and if using these modules, rather than using PyXML), you
should use
Imbaud Pierre schrieb:
But python.org was the right entry point, it sent me to the bug
tracker: http://sourceforge.net/tracker/?group_id=5470atid=105470
Its a bit short on explanations... And I found unsolved issues,
3 years old!
That's true, and likely to grow. Contributions are welcome!
I am using the standard xml library to create another library able to
read, and maybe write,
xmp files.
Then an xml library bug popped out:
xml.dom.minidom was unable to parse an xml file that came from an
example provided by an official organism.(http://www.iptc.org/IPTC4XMP)
The parsed file
Imbaud Pierre [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Now my points are:
- how do I spot the version of a given library? There is a __version__
attribute of the module, is that it?
Yes, the module maintainer should be incrementing this version for each new
release and so
Erik Johnson a écrit :
Imbaud Pierre [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Now my points are:
- how do I spot the version of a given library? There is a __version__
attribute of the module, is that it?
Yes, the module maintainer should be incrementing this version
At Thursday 28/12/2006 15:58, Imbaud Pierre wrote:
The offending part is the one that goes: xmpPLUS=''
it triggers an exception: ValueError: too many values to unpack,
in _parse_ns_name. Some debugging showed an obvious mistake
in the scanning of the name argument, that goes beyond the
