Style for modules with lots of constants

[Paddy]

Neil Cerutti wrote:
> The Glk API (which I'm implementing in native Python code)
> defines 120 or so constants that users must use. The constants
> already have fairly long names, e.g., gestalt_Version,
> evtype_Timer, keycode_PageDown.
>
> Calls to Glk functions are thus ugly and tedious.
>
>     scriptref = glk.fileref_create_by_prompt(
>             glk.fileusage_Transcript | glk.fileusage_TextMode,
>             glk.filemode_WriteAppend, 0)
>
> Please give me some good style advice for this situation.
>
> I know some modules are designed to be used as 'from XXX import
> *'. Since the Glk API is heavily influenced by its inception in
> C this might not be a huge problem. All the functions in the API
> have glk_ prepended, since C has no namespaces. I think it makes
> sense to stick the glk_'s back on the functions and instruct
> users to 'from Glk import *', but I know it doesn't conform with
> Python practice, and Python has plenty of modules that were
> originally designed in C, but don't insist on polluting the
> global namespace.
>
> Would it better to use strings instead? Some Python builtins use
> them as a way to avoid creating of global constants.
>
>     scriptref = glk.fileref_create_by_prompt('Transcript+TextMode',
>             'WriteAppend', 0)
>
> Parsing the combinable bitfield contants might be slowish,
> though.
>
> Thanks for taking the time to consider my question.
>
> --
> Neil Cerutti
> For those of you who have children and don't know it, we have a
> nursery downstairs. --Church Bulletin Blooper

I'd check the C code to first see if I could extract the C constant
definitions and automatically   convert them into Python names vvia a
short program. That way, I'd remove any transcription errors.

I favour the constants class mentioned by others , but would not mess
with any of the long constant names as it helps those who know the
original C, and also helps when users need to rely on original C
documentation.

- Pad.