Before, passing an empty suds object as an optional parameter value was treated
the same as not passing that parameter's value or passing it None - the value
would not get marshalled into the constructed SOAP request at all.
Now, user can still not have the value marshalled by passing nothing or None,
but passing an empty object will get marshalled as an actual SOAP request XML
element.
This seems correct as passing an empty object and not passing an object are two
distinct use-cases and there are web-services out there (e.g.
`https://ads.google.com/apis/ads/publisher/v201502/LineItemService?wsdl`) that
do differentiate between the two.
Fixes issue filed on BitBucket under:
`https://bitbucket.org/jurko/suds/issues/81/suds-should-support-an-empty-object`
Kudos to Nicholas Chen (nicholaschen at BitBucket) & Mark Saniscalchi
(msaniscalchi at BitBucket) for reporting the issue and preparing the initial
fix.
All code paths that could potentially lead to this class getting used convert
any encountered dictionaries to ``suds.sudsobject.Object`` instances and report
an error in case a corresponding XSD type can not be found.
This function was never actually getting used as it is overridden in all
non-abstract mashaller classes, i.e. in both `Encoded` & `Literal`.
Its description also seemed to contain some content incorrectly copy/pasted from
suds.mx.core.Core.suspend().
Fixes an infinite recursion bug encountered when looking for an XSD type in an
XSD schema that does not contain it but itself defines a type referencing a
recursively defined type from an imported XSD schema. Kudos to Kevin Pors
(krpors on BitBucket) for detecting, analysing & reporting the issue, plus
preparing a working quick-fix.
Updated README.rst.
Now XSD import does not attempt to refetch XSD schemas already constructed
during the same XSD load operation.
Updated todo list.
Updated project release notes.
A reference XSD element's 'form' value is now correctly read from its referenced
element.
This fix:
* fixes all tests in test_xsd_element.py previously marked as xfail,
* corrects buggy test data in test_request_construction.py and
* resolves project issue #49 on BitBucket.
Updated release notes.
Updated todo list.
Renamed the suds.xsd.deplist module to suds.xsd.depsort.
Removed the DepList class and replaced its main/only functionality with a single
dependency_sort() function taking a dependency dictionary and returning the same
list that used to be returned by the DepList.sort() method.
The returned list's contents matches the items returned by the dependency
dictionary's items() method, but sorted so that dependencies come first.
Updated project release notes.
Additional included changes:
* cleaned up the test_dependency_sort.py test module - cleanly separated
basic tests, test utilities and test utility tests
* added a test to make sure dependency_sort() does not modify its input data
* documented that any entries found listed as dependencies, but that do not
have their own dependencies listed as well, are logged & ignored
The 'history' list was being excessively copied at every recursion level when
it was actually only used as an extra stack. Now the extra elements are simply
pushed/popped to/from the end of the stack instead of copying the whole stack
content every time. This brings the operation down to O(n) instead of O(n*n)
algorithmic complexity.
Updated related release notes.
Many thanks to Bouke Haarsma (bouke at BitBucket) & Ezequiel Ruiz (emruiz81 at
BitBucket) for detecting and reporting the issue as well as to Bouke Haarsma for
preparing a suitable test case and the initial patch.
The test suite is no longer installed together with the project and can now be
run from the project's source distribution. This resolves the issue of the suds
test suite confusing users by getting installed as a top level tests package in
their Python environment.
Project to be tested now need to be explicitly installed prior to running its
tests using pytest, except in case of Python 2 tests being run from the top
level project folder. This requires the user to install the project (suggested
way is to install it in editable mode using 'pip install -e') but also allows
him to run the tests on other non-sandbox project versions, e.g. an externally
installed version.
Project testing now requires the six Python 2/3 compatibility support package
(installed automatically, together with other test requirements).
Test support code now moved to a separate testutils package located under the
tests folder.
Updated project README.rst & HACKING.rst docs.
Minor stylistic changes.
Installs packages into multiple Python environments so they can be used for
testing this project. This automates all the previously manually done work on
setting up those environments.
The script contains a multitude of open TODO comments and should still be
considered 'work in progress', but successfully gets the work done at least on
one Windows 7 x64 SP1 machine with 17 different parallel Python installations.
Updated relevant HACKING.rst docs.
Relevant configuration added to the main project Python configuration file
'setup.cfg'.
All Python modules indended for use in different project development utility
scripts have been placed under the suds_devel package folder located under the
tools project folder.
The new scripts:
- are included in the project's source distribution,
- are not installed with the project
- do not need py2to3 processing
- do not have any tests of their own yet
tools/__* folders get created and used as local caches by the new
tools/setup_base_environments.py development script and so must not included in
the project's source distribution.
Note that setting up some of the supported older Python environments requires
manual tweaking that has not yet been automated anywhere or described in detail
in the project's HACKING docs.
When using a pip to install our product into a Python environment with an
existing setuptools installation older than the one used in our project - the
installation will fail and require that the user manually upgrade the existing
setuptools installation.
The issue has already been fixed in the current development version by no longer
requiring a specific setuptools version.
Now using setuptools 1.4.2 with Python 2.4 & 2.5, and using setuptools 3.3 with
later Python versions. This should help avoid installation issues in different
exotic use cases that were once not being handled by setuptools but have since
been corrected.
Now tested using:
* Python 2.4.3 x86
* Python 2.4.4 x86
* Python 2.7.6 x64
* Python 3.2.5 x64
* Python 3.3.3 x86
* Python 3.3.3 x64
* Python 3.3.5 x64
* Python 3.4.0 x86
* Python 3.4.0 x64
Minor stylistic run_all_tests.cmd script changes:
* Renamed several internal constants.
* Reordered tests to make those expected to fail more often run sooner.
This avoids issues with pytest xdist plugin collecting tests differently in
different test processes when running them using multiple parallal test
processes.
Kudos to Bruno Oliveira (nicoddemus at BitBucket) for researching related pytest
xdist usage problems, discovering & explaining the underlying issue as well as
providing an initial project patch for it.
Introduced a new 'Project implementation note #xxx' concept for documenting
unintuitive code without duplicating embedded explanation comments. Such
implementation notes now documented in the HACKING.rst project document.
Updated how suds constructs its cached WSDL & XML identifiers to allow cached
data reuse between different processes with Python's hash randomization feature
enabled.
Previously constructed using the built-in Python hash() function, while now it
gets constructed using md5 hash.
Python's hash randomization (implemented since Python 2.6.8, enabled by default
since Python 3.3) was causing different processes to mangle their cached data
names differently.
Many thanks to Eugene Yakubovich for reporting the issue as well as providing
the initial fix & tests.
This is the exception message constructed when attempting to construct a
suds.sax.element.Element with a non-Element parent. It seems like someone forgot
to apply % string formatting in its construction.
All such block replaced with blocks catching Exception subclasses only so they
no longer eat up internal Python exceptions like SystemExit or
KeyboardInterrupt.
Invalid or unrecognized SOAP headers given using the suds soapheaders option are
still simply ignored, the same as in the original suds library implementation.
For some input data types, if a non-Exception based exception (e.g.
KeyboardInterrupt or SystemExit) was raised while constructing the given
value's unicode representation, it would get silently ignored and the value's
byte string representation built instead. Now this handling applies only to
regular Exception based exceptions while internal non-Exception based ones are
propageted.
suds.transport.Request now allows specifying its URL input as either a byte or
a unicode string with any Python version. Internally that URL information is
always converted to the used Python interpreter's native str data type (byte
string for Python versions prior to 3.0, or unicode string for later ones).
Given URLs must not contain any non-ASCII characters and any attempt to create
a suds.transport.Request with such an invalid URL is reported as a UnicodeError
(either UnicodeDecodeError or UnicodeEncodeError depending on the exact Python
version and the given URL data type used).
suds.transport.Reply & suds.transport.Request string representation cleaned up
and no longer raise an error when their message data contains non-ASCII
characters.
Updated related class & method doctrings.
Updated related unit tests.
Updated todo list.
This affects the published FileCache interface by making it take standard
datetime.timedelta duration related keyword arguments instead of just 'weeks',
'days', 'hours', 'minutes' & 'seconds'. More to the point, it now also supports
'milliseconds' & 'microseconds' keyword arguments.
Corrected FileCache docstring stating that it accepted a `months` keyword
argument when that argument would actually have caused a failure when passed to
a datetime.timedelta initializer internally.
You may now specify multiple duration keyword arguments in FileCache
construction and they will all get summed up when constructing the internal
datetime.timedelta duration representation. Before, you could specify such
multiple arguments, but that would only make the FileCache silently use duration
0, i.e. its cache entries would never expire.
Before, negative durations would have been automatically treated as 'infinite'.
Now they are treated as any other duration value, but that should not cause any
visible side-effects as long as the computer time does not get moved in reverse.
Added related unit tests.
DocumentCache & ObjectCache now correctly remove their files on failed file read
operations or failing to process data read from the cached file. Before the
file purge operation would fail because suds still held an open file handle to
the same cached file.
Updated related project release notes.
Such values now modeled using Python's decimal.Decimal class. Original suds
implementation represented them using Python's float type which could result in
both precision loss and incorrectly constructed SOAP request XML documents.
The bug was cased by the internal __inject argument getting passed onto regular
argument parsing.
This fixes the failing test_resolving_builtin_types() test in
'test_xsd_builtins.py'.
Jurko Gospodnetić