correct create_personality function params to reflect usage

[bgerrity]

The names of the positions args used in the docs don't reflect usage; this leads to a TypeError. This change address that issue.

  File ".../gateway#link-tree/kernel_gateway/gatewayapp.py", line 447, in init_configurables
    self.personality = func(parent=self, log=self.log)
TypeError: create_personality() got an unexpected keyword argument 'log'

[bgerrity]

Broken tests appear unrelated. Local build of docs succeeds.

[kevin-bates]

Good catch!

Should the signature be: def create_personality(*args, **kwargs): and we document two required kwargs are: parent and log? This will then fit the existing declarations that reside for the websocket and http personalities while allowing for other parameters to be added in the future.

[bgerrity]

I'm unsure about the usage of *args, **kwargs here or in the existing declarations: Based on init_configurables, I'm not I'm not seeing how any additional args could be passed to create_personality via configuration.

[kevin-bates]

In the future, we may find the need to convey other information to a "personality", at which time we'd add a parameter (e.g., foo=bar) in init_configurables. Personalities that don't know about the parameter could still be called (and ignore it), while those that know what foo is for would use it via kwargs["foo"], for example.

This, coupled with the idea that signatures for "custom personalities" should match that of the two existing personalities, leads me to argue for using *args, **kwargs due to precedent.

One of the things that makes this confusing is the lack of initializers with "Configurable" classes - on which most of Jupyter is based. Both parent and log are "well-known" parameters within the LoggingConfigurable class hierarchy. (Not sure if this helps or not.)

[bgerrity]

Makes sense to use that for convention and extensibility.

[kevin-bates]

LGTM - sorry about the CI. This project needs substantial maintenance!