Wolfram|Alpha specialized API support

[Zenohm]

Hello again!

Background I was browsing around the MycroftAI core requirements and I noticed your project listed as one of the requirements, most probably being the foundation for their interaction with Wolfram|Alpha. Since I've worked on integrating Wolfram|Alpha into a pet-project before, and I wondered if there was any easier way to get a response that could be spoken aloud by a virtual assistant.

Unused Features These are features that would be useful to be able to access, mostly because they simplify tasks that are already being performed. I list them because the two main Python-based interfaces to the Wolfram|Alpha API (This and Tungsten) do not have support for, or even seem to be aware of these features. Here are some of the notable ones.

• Spoken Results API built into Wolfram|Alpha, a feature that would be extremely useful to the MycroftAI team (Who use this library) and hobbyists like myself.
• Returning the main/primary response to a query, something that is currently being done programmatically.
• Formatting the response as JSON (Note the Formats section), something that is currently being done programmatically.
• Classifying inputs, which is useful for determining when you want certain inputs to be handled.
• Returning an image with the full, customized results of a query. Note that this resulting image can be themed and is extremely useful as it would allow for complex results to be easily displayed.

Question So my question is whether you plan on implementing support for querying this and other features?

[jaraco]

Thanks for your interest in this project and for your thoughtful and nicely-referenced description of your request.

The short answer to your question is no. There's no active development on this project.

However, that doesn't mean this project is abandoned. On the contrary, this project is open to contributions from anyone willing to contribute, and I'd like to offer help to make the barrier as low as possible.

What I recommend. First, I'm a big fan of abstraction layers and decoupling. Therefore, for some of these features (like spoken results), it may make sense to create a separate library built on this library that provides that higher-level functionality and depends on this (or another low-level) library. This approach would allow you to create your own package and iterate fast and maintain that project independently. I'd happily endorse that approach and link to that project from the readme/docs of this project to help advertise it.

For other features, like response formatting or classifying inputs, those features feel more integrated and might not make sense in a third party library. For those, I recommend drafting and testing a solution in a fork of this project and then submitting a pull request. I'll be inclined to accept any pull request that doesn't break compatibility for existing users and enthusiastic about a request that includes tests and documentation.

I hope that helps and I'm eager to see what you develop. Thanks again for the interest.