"Neil Cerutti" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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. >
Neil - I recently had to add some new constants to pyparsing, representing LEFT and RIGHT, but I didn't want to define such generic and likely-to-collide-with-user-code variable names. I settled on defining my own flavor of the Bag class, which I named Constants since it is there specifically to define constants (although it does nothing to enforce the "constant-ness" of the values). class Constants(object) pass (I guess value immutability could probably be implemented using clever implementations of __setattr__ and such, but is it really worth the bother?). Then I defined the context for my LEFT and RIGHT constants, which are being created to specify operator associativity, and then my constant fields as attributes of that object: opAssoc = Constants(object) opAssoc.RIGHT = 0 opAssoc.LEFT = 1 In client modules (that is, those that import your library) that don't like "from pyparsing import *", they can just add opAssoc to the list of imported names (as in "from pyparsing import opAssoc"), and all of the related constant definitions come along for the ride. In your example, this would look something like: fileusage = Constants() fileusage.Transcript = 1 fileusage.TextMode = 2 filemode = Constants() filemode.Read = 1 filemode.Write = 2 filemode.Append = 4 filemode.WriteAppend = filemode.Write | filemode.Append and so on. In the client modules they would simply enter "from glk import fileusage, filemode". Or if they just "import glk", the references to the constants look like "glk.filemode.Append", "flk.fileusage.TextMode", etc., and those garish and unsightly '_' separators are reduced to svelte little '.'s. I think this is a reasonable compromise in avoiding namespace pollution, without inflicting unseemly text entry overhead on your module clients. -- Paul -- http://mail.python.org/mailman/listinfo/python-list