"typed" API

[dave-doty]

It seems this package would be much easier to use if it supported "typed" access. Many parts of the Canvas API are only accessible via keyword arguments or passing dictionaries with special keys. For example, to set the question_text of a QuizQuestion requires doing this:

course = canvasutil.get_course(123456)
quiz = course.get_quiz(654321)
question = quiz.get_questions()[0]
question.edit({'question_text': 'new question text'})

which itself requires consulting the (non-Python) Canvas API to determine that question_text is a valid key to use in that dict. (And even then it's not without problems, e.g., #579).

A better way would be if the canvasapi Python package supported this directly with a setter, e.g.,

course = canvasutil.get_course(123456)
quiz = course.get_quiz(654321)
question = quiz.get_questions()[0]
question.question_text = 'new question text'
# or
question.set_question_text('new question text')

which could then be documented (through docstrings on the setter method or property field) directly in the canvasapi Python package API docs at https://canvasapi.readthedocs.io/. It would also (huge win) allow auto-complete in IDEs to help make the API more easily "discoverable".

Is the only issue with this the time it would take to go through the (non-Python) Canvas API and look up all these attributes? Or the fear that it would become out of date if the Canvas API changes?

This isn't merely a matter of convenience; it's really not clear in some cases how to set these attributes, and the error messages when you do it wrong are also not very clear. (If you're lucky enough to get an error message; in some cases getting it wrong just means it silently fails.)

[bennettscience]

A similar question was brought up in #601 because Canvas expects a list of dicts to update quiz questions. It's easy enough to solve - once you know what you're looking for.

The Canvas API is so vast and subject to change that adding all of the attributes to the documentation would be a monumental task. I like the solution posed for #602, where arguments are automatically wrapped on endpoints which require a specific data structure. Maybe that could be an intermediate?