Roadmap?

[jsma]

Is this meant for public use or is this an internal project at the moment? If it's meant for the public, there appear to be a few things hindering adoption of this library. It would be great to have some clarity on the future of this project.

Test failures

There are many test failures related to pyxb contracts, which I'm not familiar with. There are lots of references to "C:\Users\krgupta\Desktop", so I'm assuming this is part of the problem? I submitted #55 to at least correct the README, so the test instructions will actually run the tests, but the tests fail even on master so my changes don't appear to be the culprit (tested under Python 2.7.11).

Python 3 Support

The README says "We'll be ensuring this SDK is compatible with Python 2.6+, 3.2+ and PyPy". However, this library is not compatible with Python 3.x. I've submitted #54 to fix usages of print as a statement (rather than a function) but there appears to be many other significant issues standing in the way of full Python 3 support. #56 is my attempt to start adding support for Python 3.4+ (3.2 is no longer supported as of February 2016 and 3.3 is only supported until September 2017, so it's questionable whether to support that version now).

JSON API

Are there any plans to introduce support for the JSON API?

[tweekmonster]

I've been watching this repo for a little while. It feels likes a side project at the moment, particularly because of the print statements. But, also because it seems a little Java-y.

Python 3 Support

Adding to your points:

• Python 3.2 is a bad test target. It was the version where some over confident changes were introduced, like not recognizing unicode literals.
• I think supporting Python 2.6 is the biggest issue as far as version support is concerned. I don't think existing customers on old distros will be jumping to use a different library if their setup has been working for this long. Additionally, it could cause development to be slower since there's significant differences between 2.6 and 2.7. Aside from some module rearrangements and unicode strings, 2.7 and 3.3+ are mostly source compatible if newer language features are avoided.
• Supporting 3.3 should still be a goal. Python's support schedule isn't the same as distro support schedules.
• The source should be actively developed for 3.4+, then fixing the lower versions when tests fail for them.

Are there any plans to introduce support for the JSON API?

I think it would be nice if there was a RESTful API. It would remove the need to maintain several SDKs for the same service. XML transport is the absolute worst for a public API if the goal is to onboard developers quickly.

[brianmc]

Hi @jsma and @tweekmonster.

We're looking at the test failures, the project just recently came out of beta however it became apparent that pyxb was not optimal for API response processing as it is really intended for strict schema validation and that obviously hampers backward compatibility. We have switched to objectify for response handling and we have some tests flux for sure, never a good thing. You have probably now realized why it seems a little "java-y", it's because we generate the classes from our XSD and hence the programming model is more or less the same across all languages. Definitely we lose some language efficiencies and style but we felt we made up for that by having very low maintenance SDKs.
RE Python 3 support, great feedback, we're going to revisit our strategy there.

Finally, REST APIs are coming and we'll be providing a new Python SDK at that time. We'll still try to drive maintenance efficiencies by using swagger to generate the SDK but all the trials we've done so far indicate this will yield a much better outcome than XML/XSD.

We're going to review and merge the PRs, thanks for those and look out for further updates.

Brian

[tweekmonster]

@brianmc Thanks for the update.

To be clear about Python 3.2: If you look at open source Python projects that have automated testing, you'll notice that a lot of them skip 3.2 as a test target. The primary reason is explained here: https://www.python.org/dev/peps/pep-0414/

My comment about the java-ness of the current code has more to do with the verbosity of the API and camelCase variables. The parenthetical if statement in the README as well, but that's nitpicking 😏

Have you looked at existing modules?

• https://github.com/drewisme/authorizesauce
• https://github.com/vcatalano/py-authorize
• https://github.com/zen4ever/django-authorizenet

py-authorize seems to be pretty feature-complete. Perhaps you could throw in support for py-authorize or borrow ideas from it.