wolframalpha before 3.0 does not handle the params kwarg to Client.query(), which means the changes to fix #14 will fail on older library versions. Implementing #16 is also impossible on older library versions.
Because of this, release v0.3.2 has been unpublished everywhere. It was completely broken—passing params to wolframalpha 2.4 fails the query with a TypeError due to the unexpected kwarg. Testing procedures will have to change so this sort of thing doesn't happen again. (The test Sopel instance uses a git checkout to work around Sopel's inability to properly reload pip-installed modules during development, but that means requirements.txt isn't respected—which means the dependency versions can be out of sync with the code and mask issues like this.)
Moving forward, the simplest solution to maintain backward compatibility is to catch TypeError when calling the query method and try again without the unsupported options. This would mean behavioral differences between 2.x and 3.0, though. (The Unicode bug described in #14 wouldn't be fixed when using outdated wolframalpha, for example.) Emulating the params kwarg might prove to be far more trouble than it's worth, though.
Plans for 0.4.0 might change back to dropping support for wolframalpha < 3.0. It's worth investigating whether feature parity can be maintained somehow between library versions through some trickery to pass the params some other way, but I rather doubt it will be worth the effort (or even possible—the wolframalpha module's older query API is quite limited and has no apparent way to pass options).
I'm moving up the milestone deadline for v0.4.0 because of this critical issue with the last release; it's now aimed for mid-July at the latest—within the next 10 days.
wolframalphabefore 3.0 does not handle theparamskwarg toClient.query(), which means the changes to fix #14 will fail on older library versions. Implementing #16 is also impossible on older library versions.Because of this, release v0.3.2 has been unpublished everywhere. It was completely broken—passing
paramstowolframalpha2.4 fails the query with aTypeErrordue to the unexpected kwarg. Testing procedures will have to change so this sort of thing doesn't happen again. (The test Sopel instance uses a git checkout to work around Sopel's inability to properly reload pip-installed modules during development, but that meansrequirements.txtisn't respected—which means the dependency versions can be out of sync with the code and mask issues like this.)Moving forward, the simplest solution to maintain backward compatibility is to catch
TypeErrorwhen calling the query method and try again without the unsupported options. This would mean behavioral differences between 2.x and 3.0, though. (The Unicode bug described in #14 wouldn't be fixed when using outdatedwolframalpha, for example.) Emulating theparamskwarg might prove to be far more trouble than it's worth, though.Plans for 0.4.0 might change back to dropping support for
wolframalpha< 3.0. It's worth investigating whether feature parity can be maintained somehow between library versions through some trickery to pass theparamssome other way, but I rather doubt it will be worth the effort (or even possible—thewolframalphamodule's older query API is quite limited and has no apparent way to pass options).I'm moving up the milestone deadline for v0.4.0 because of this critical issue with the last release; it's now aimed for mid-July at the latest—within the next 10 days.