DOCTEST==argv[0] 作为约定？
我正在用一点Python编写（一个命令行和过滤器测试工具：claft）我想要一种简单的方法来调用内置测试套件（doctest），并且我决定如下：
if 'DOCTEST' in os.environ and os.environ['DOCTEST']==sys.argv[0]:
_runDocTests()
sys.exit()
因此，如果为其他程序设置了 DOCTEST 变量，我将忽略它即可。 事实上，我对此的测试只是： DOCTEST=./claft ./claft 或者如果我想详细一点，我可以使用： DOCTEST=./claft VERBOSE=1 ./claft 所以即使我将 DOCTEST=./claft 留在在我的环境中，测试代码仅当我从其自己的目录中调用我的程序时才会运行。 如果我切换到我的测试套件之一并使用相对路径调用它，那么我就可以安全地避免无意中触发此函数。
还有其他人使用过这种约定吗？
避免环境变量名称冲突的其他建议或最佳实践是什么？ 为了提供对测试工具功能的“隐藏”访问？
（另外，如果有人想玩claft，请随意尝试一下。目前它的代码相当丑陋，几乎不是一个概念证明。但它的功能很少。它也被这是自学如何使用 Mercurial 和 bitbucket 的好方法。 wiki 和问题跟踪是发布有关 craft 的反馈的最佳场所。
In a bit of Python I'm writing (a command line and filter testing tool: claft) I wanted a simple way to invoke the built-in test suite (doctest) and I decided on the following:
if 'DOCTEST' in os.environ and os.environ['DOCTEST']==sys.argv[0]:
_runDocTests()
sys.exit()
Thus if the DOCTEST variable is set for some other program I'll just ignore it. In fact my test for this is just: DOCTEST=./claft ./claft or if I want to be verbose I can use: DOCTEST=./claft VERBOSE=1 ./claft So even if I leave DOCTEST=./claft in my environment the test code will only run when I invoke my program from within its own directory. If I switch to one of my test suites and invoke it using a relative PATH then I'm safe from inadvertently triggering this function.
Has anyone else used this sort of convention?
What are other suggestions or best practices for avoiding conflicts among environment variable names? For providing "hidden" access to test harness functionality?
(Also, if anyone wants to play with claft please feel free to give it a spin. It's pretty ugly code for now, and is barely a proof of concept. But it is minimally functional. It's also been a nice way to teach myself how to use Mercurial and bitbucket. The wiki and issue tracking are the best places to post feedback about claft).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
既然您已经在进行命令行解析，为什么不添加一个
--selftest选项呢？ 这样您就不必担心任何冲突，并且调用会更容易。Since you're already doing command-line parsing, why not just add a
--selftestoption? You won't have to worry about any conflicts that way, and invocation will be easier.另一种避免名称空间与环境冲突的黑客方法：查找 myprogname_DEBUG 等。
Another hackish way to avoid namespace conflicts with the environment: looks for myprogname_DEBUG or the like.