Skip to content

API documentation is barely useable #516

@bordenc

Description

@bordenc

I'm trying to write some scripts using the Dropbox Python API to automate common tasks. I have read through the tutorials, and I am trying to decipher the documentation. I'm finding the documentation almost unusable. Specifically:

  • The documentation references classes, like dropbox.team_log.TimeRange, which don't exist (referenced in team_log_get_events). In other places, it provides deprecation notices without suggesting alternatives (such as team_reports_get_activity - which is exactly the function I needed had it not been removed 4 years ago)
  • The tutorial, at least, explains how to create an entry point into Dropbox. Where to go from there, though, is very difficult to figure out. There's no method grouping or guidance on which set of functions solve which problems. The documentation is just a laundry list of methods, and I have to try to figure out from the names which function does which.
  • There is clearly a nomenclature in functions/methods, but it's never explained what that is. That would probably help with grouping and finding methods to use. For example, what's the difference between functions that use "file" v. functions that use "files"?
  • Further to above, the modules don't summarise what they do and why/if you would want to call them. I'm assuming for anything that isn't Dropbox or DropboxTeams objects, one shouldn't create them directly, but use them when functions return them.

This is leading me to wonder whether Dropbox is still supporting this API, and whether there are plans to write documentation similar to what Python has that explains how to use each module and how the pieces fit together.

On the API design in general, it seems that C programmers created it, not Python programmers. It baffles me why just about every object derives from Structure, Union or some other C-inspired structure, and forces the programmer to check for various flags. Python has plenty of built-in syntax and objects that it seems this API ignores. Am I missing a greater design philosophy?

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions