When called with parameter nobuiltin=True on a node whose type is a builtin, the
original implementation cached the builtin type as the result so a repeated
resolve() call returned an incorrect value.
Added related test case. Refactored the resolve() implementation into an
external function dealing with result caching and in internal worker function
doing the actual type resolution. Updated todo list.
There is no need for a recursive implementation here since a node can reference
an external type node but there is no way using WSDL to then make that type node
actually be a reference to a different type node.
Added more resolve() related test cases and refactored existing ones. Updated
todo list.
Base SchemaObject class held the resolve 'cache' object but it was never used
except in the TypedContent subclass. Support for such caching now implemented
directly in the TypedContent subclass. Renamed the cache object to resolve_cache
to make it more 'grep friendly'.
Updated todo list.
This function was used only once, undocumented and it is unclear when it should
be used and when the regular suds.wsdl.Types constructor should be used
directly.
Before this failed because the printing code too eagerly attempted to access
the object's __metadata__ member, actually needed only for printing out
suds.sudsobject.Facade objects. Bug initially introduced in the original 'suds'
project Subversion repository trunk revision 639.
Added related test code. Updated todo list.
Changed the way suds.client.Client to-string conversion outputs build info. This
fixes a bug in the original '0.4.1 jurko 1' forked project release causing
printing out a suds.client.Client object to raise an exception due to the code
in question making some undocumented assumptions on how the build information
string should be formatted. Added a related test. Updated todo list.
* Renamed internal HACKING, LICENSE, README & TODO documentation files to use
the .txt extension and thus be easier to use on Windows.
* Renamed the forked project name to 'suds_jurko' to differentiate it from the
original 'suds' project on PyPI.
* Added a MANIFEST.in project configuration file listing the forked project's
source distribution content (needed since we are using the Mercurial version
control system and our installation packager does not know how to
automatically collect 'all files under Mercurial version control' the way it
does for CVS or SVN).
* Improved project documentation.
* More detailed 'setup.py' usage documentation notes (HACKING.txt).
* Documented the forked project's release procedure (HACKING.txt).
* Documented the forked project's release download locations (README.txt).
* Documented the forked project's installation procedure (README.txt).
* Preparing source distributions ('setup.py sdist') now configured to be use the
.tar.bz2 format by default as it takes the least space.
* Updated the forked project's meta data used when preparing distribution
packages (description, long_description, keywords, url, download_url, ...).
* Project's built distribution no longer contains test.* subpackages.
* Updated todo list.
Python 3 support based on patches integrated from a Hg patch queue maintained by
Bernhard Leiner at 'https://bitbucket.org/bernh/suds-python-3-patches'. Last
collected patch series commit: '96ffba978d5c74df28846b4273252cf1f94f7c78'.
Request & Reply 'message' member contains binary & not unicode-string data. When
a string is needed (e.g. when logging SOAP request or reply content) we now use
Python's internal and non-ambiguous representation for this data.
Optionally, we could 'assume the data is actually an utf-8 encoded unicode
string', decode it and get a bit nicer string output, i.e. without the "b''"
wrapper and without having non-ASCII characters displayed as escaped hexadecimal
character codes, but that would require much more detailed usage research to
make sure our assumption holds.
We teach Python's lib2to3 urllib fixer to correctly recognize the
'urllib2.__version__' data member usage and update it to
'urllib.request.__version__'.
This adds a dependency on the Python 3 version of setuptools when running under
Python 3. This should not be a problem since the Python 2 version also depends
on setuptools.
Jurko Gospodnetić