Closed mwerezak closed 3 years ago
PEP8 does actually touch on this specific case, to my surprise:
Class Names
Class names should normally use the CapWords convention.
The naming convention for functions may be used instead in cases where the interface is documented and used primarily as a callable.
Despite that though, I'm going to go with the principle of least surprise here. I think there's a good chance that people discovering the object library for the first time would be surprised that names like text
, button
, or input_float
would name a type.
So even though you can use them like callables (not storing the result in a variable, just causing a side effect in the underlying C++ gui engine), I guess CapsCase is the way to go
Widget objects are different from many typical objects in Python, in that instantiating them has the side-effect of creating a widget in Dear PyGui. It's a bit strange thing to do in an OOP language, but IMO it makes the most sense for the situation. Having widget objects not create the underlying widget right away would introduce a ton of complexity to handle "headless" widgets - something that is completely avoided with the current design. Beyond just having to store and manage the widget config until the widget does get added, it would also mean that every method that retrieves data about a widget would have to branch, since the underlying widget might not yet exist.
But it is odd that creating a widget object has a side effect:
Lowercasing all of the types might help communicate their in-between nature of being both like an object type and constructor function.
Lowercase type names is not new to python. For example some types in the standard library like
namedtuple
ordatetime
are lowercased.It's sort of a superficial non-critical thing, so I'm not sure if it's really needed. It is also a bit of an oddball solution - by sticking to convention and using CamelCase it does make it clear that the widget types are classes.
Leaving this open until I make up my mind.