Open yuce opened 3 years ago
A related point, I do think it would be very helpful to explicitly enumerate the client config options instead of accepting everything as **kwargs
.
Or at the very least declare the more common configuration settings (with type annotations).
It makes it much easier when working with modern Python IDE's (Pycharm, VS Code etc.).
I agree, we can do better in discoverability of the configuration options and editor support. Expect more developments about that in the coming days.
Currently both client configuration and other options, such as lifecycle listeners are passed as unnamedkeyword arguments to
HazelcastClient
constructor. This works well ATM, but it may be problematic when we decide to add support for declarative configuration https://github.com/hazelcast/hazelcast-python-client/issues/351Currently following snippet works:
One possible way of resolving this issue is passing non-client configuration-related arguments only as named keyword arguments to
HazelcastClient
constructor and passing cluster configuration in**kwargs
(as currently implemented).Example:
Separating HazelcastClient creation and cluster connection may help with removing options like
lifecyle_listeners
. See: https://github.com/hazelcast/hazelcast-python-client/issues/353