具有大量常量的模块的样式 [英] Style for modules with lots of constants
问题描述
Glk API（我在原生Python代码中实现）
定义用户必须使用的120个左右的常量。常量
已经有相当长的名字，例如，gestalt_Version，
evtype_Timer，keycode_PageDown。
因此调用Glk函数丑陋乏味。
scriptref = glk.fileref_create_by_prompt（
glk.fileusage_Transcript | glk.fileusage_TextMode，
glk.filemode_WriteAppend， 0）
请给我一些关于这种情况的好风格建议。
我知道有些模块设计用于''来自XXX导入
*''。由于Glk API受其在
C开始时的影响很大，这可能不是一个大问题。 API中的所有函数
都有glk_ prepended，因为C没有名称空间。我认为这会让glk _'s重新回到功能上，并指示
用户来自'Glk import *''，但我知道它没有不符合
Python的做法，而Python有很多模块，这些模块最初是用C设计的，但不要坚持污染
全局命名空间。
使用字符串会更好吗？一些Python内置函数使用
来避免创建全局常量。
scriptref = glk.fileref_create_by_prompt（''Transcript + TextMode''，
''WriteAppend''，0）
解析可组合的位域内容可能会慢，
虽然。
感谢您花时间考虑我的问题。
-
Neil Cerutti
对于那些有孩子并且不知道的人，楼下有一个
托儿所。 --Church Bulletin Blooper
" Neil Cerutti" < ho ***** @ yahoo.com写了留言
news：sl ******************** @ FIAD06.norwich。 edu ...
Glk API（我在原生Python代码中实现）
定义了120个左右的常量用户必须使用。常量
已经有相当长的名字，例如，gestalt_Version，
evtype_Timer，keycode_PageDown。
因此调用Glk函数丑陋乏味。
scriptref = glk.fileref_create_by_prompt（
glk.fileusage_Transcript | glk.fileusage_TextMode，
glk.filemode_WriteAppend， 0）
请给我一些关于这种情况的好风格建议。
我知道有些模块设计用于''来自XXX导入
*''。由于Glk API受其在
C开始时的影响很大，这可能不是一个大问题。 API中的所有函数
都有glk_ prepended，因为C没有名称空间。我认为这会让glk _'s重新回到功能上，并指示
用户来自'Glk import *''，但我知道它没有不符合
Python的做法，而Python有很多模块，这些模块最初是用C设计的，但不要坚持污染
全局命名空间。
Neil -
我最近不得不为pyparsing添加一些新的常量，代表LEFT并且
RIGHT，但我不想定义这样的通用和
可能与用户代码碰撞的变量名称。
我决定定义我自己的Bag类的味道，我将它命名为
常量，因为它专门定义常量（尽管它是
什么都没有强制执行值的常量。）
类常量（对象）
通过
（我猜值不变性可能是impl使用聪明的
实现了__setattr__等等，但它真的值得吗？
打扰？）。
然后我定义了我的LEFT和RIGHT常量的上下文，用于指定运算符关联性，然后我的常量字段为
该对象的属性：
opAssoc =常数（对象）
opAssoc.RIGHT = 0
opAssoc.LEFT = 1
在客户端模块（即导入您的库的那些）中，不喜欢
来自pyparsing import *，他们只需将opAssoc添加到导入列表中即可。 >
名称（如来自pyparsing import opAssoc中），以及所有相关的
常量定义随之而来。
在你的例子中，这看起来像是：
fileusage =常量（）
fileusage.Transcript = 1
fileusage .TextMode = 2
filemode = Consta nts（）
filemode.Read = 1
filemode.Write = 2
filemode.Append = 4
filemode.WriteAppend = filemode.Write | filemode.Append
等等。在客户端模块中，他们只需输入from glk import
fileusage，filemode。或者，如果它们只是导入glk，则对
常量的引用看起来像glk.filemode.Append，flk.fileusage.TextMode等，
和那些花哨而且不雅观的''_''分隔符减少了很少。
''。's。
我想这个在避免命名空间污染方面是一个合理的妥协，
而不会在模块客户端上造成不合适的文本输入开销。
- Paul
Neil Cerutti：
scriptref = glk.fileref_create_by_prompt（''Transcript + TextMode''，
' 'WriteAppend''，0）
" +标志似乎没用。一个空间对我来说足够了。函数
可以接受与案例无关的字符串并忽略其中的空格。
示例：
（''transcript textmode''，'' writeappend''，0）
解析可组合的位域内容可能会很慢。
我认为你必须测试这是否适合你的情况。管理
的实习字符串可能足够快（与Python解释器完成的其余部分相比）用于多种用途。
再见，
bearophile
在2006-11-01，是************ @ lycos.com < be ********** **@lycos.comwrote：
Neil Cerutti：
> scriptref = glk.fileref_create_by_prompt（ ''Transcript + TextMode''，
''WriteAppend''，0）
&;标志似乎没用。一个空间对我来说足够了。
函数可以接受与大小写无关的字符串并忽略其中的空格
。示例：
（''transcript textmode''，''writeappend''，0）
这很酷。不是很漂亮，但对用户来说更容易，
可能。
>解析可组合的位域内容可能会慢一点，但是。
我认为你必须测试这是否适用于你的情况。
实习字符串的管理可能足够快
（与Python解释器完成的其他工作相比）
用于多种用途。
同意。我的意思是我必须稍后测试它是否足够快。
-
Neil Cerutti
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
"Neil Cerutti" <ho*****@yahoo.comwrote in message
news:sl********************@FIAD06.norwich.edu...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
Neil Cerutti:scriptref = glk.fileref_create_by_prompt(''Transcript+TextMode'' ,
''WriteAppend'', 0)That "+" sign seems useless. A space looks enough to me. The functions
can accept case-agnostic strings and ignore spaces inside them.
Example:
(''transcript textmode '', ''writeappend'', 0)
Parsing the combinable bitfield contants might be slowish, though.I think you have to test if this is true for your situation. Management
of interned strings is probably fast enough (compared to the rest of
things done by the Python interpreter) for many purposes.
Bye,
bearophile
On 2006-11-01, be************@lycos.com <be************@lycos.comwrote:Neil Cerutti:>scriptref = glk.fileref_create_by_prompt(''Transcript+TextMode'' ,
''WriteAppend'', 0)
That "+" sign seems useless. A space looks enough to me. The
functions can accept case-agnostic strings and ignore spaces
inside them. Example:
(''transcript textmode '', ''writeappend'', 0)That''s pretty cool. Not as pretty, but easier for users,
possibly.
>Parsing the combinable bitfield contants might be slowish,
though.
I think you have to test if this is true for your situation.
Management of interned strings is probably fast enough
(compared to the rest of things done by the Python interpreter)
for many purposes.Agreed. I meant I''d have to later test if it''s were fast enough.
--
Neil Cerutti
这篇关于具有大量常量的模块的样式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
