Disallow single character arguments

Description of the desired feature

A major usability problem for GMT are the complex and cryptic single character arguments and modifiers. This is why we implemented the entire alias system in GMT/Python (which is making its way back into GMT 6). Our docs all encourage using the long form names and this is not strange in the Python ecosystem. Since we’re actively discouraging the use of B and the like, why are we maintaining the capability of doing so? Hardcore GMT users who value brevity are not our target audience. And if you’re using Jupyter or any modern text editor, tab completion eliminates the hassle of longer names (which we currently can’t use because of the alias system).

I propose getting rid of the single letter arguments all together.

Doing this will allow us to:

• Define functions arguments normally in the Python functions instead of relying on **kwargs.
• Get rid of the use_alias decorator and replace it with a translator function that’s called inside the function body. This functions would be a lot easier than the decorator to maintain (which is an ugly function inside a function inside a function).
• Use tab completion for the long argument names
• Simplify the testing a lot but not needing to test the aliases

The one downside I see that we will have to fully implement all arguments in order for them to be used (like X and Y, etc). But we were gonna have to do this eventually any way.

I’d love to get some feedback on this.

[mjziebarth]

Good idea!

@liamtoney @leouieda Regarding the dict of keywords a small issue highjacking: If classes are autocomplete friendly (I must admit I work using simple text editors), one could also do something like

fig.basemap(frame='af', scale=Scale(location_type='g', location=SCALE_LOC, ...))

That would surely take a lot of work setting up but may be helpful.

[leouieda]

@mjziebarth that was my initial idea but I’d be more prone to using a function instead of a class. The only thing needed is to convert the arguments into a GMT-compatible string, so a class wouldn’t really do much besides store the values and define a __str__ method that does the conversion. The benefit of the class is that the documentation might be more straight-forward (the required value of scale would be either a string or a Scale instance). Another advantage is that we can add them as needed and still allow the normal string input. The only problem with this is that it’s kind of unnatural to require these objects. But I don’t see a good way around it without completely changing the GMT way of doing things.