我应该将参数转发为 *args & **夸格斯？
我有一个类，它使用 python 的 optparse 模块处理程序中的命令行参数。它也被多个类继承以创建参数子集。为了封装选项解析机制，我只想向继承类展示一个函数 add_option 。该函数的作用是调用optparse.make_option。
让我的 add_option 方法接受与文档中的 optparse.make_option 相同的参数，并将参数转发为 *args 是一个好习惯吗？ 和**kwargs？
我应该事先做一些参数检查吗？在某种程度上，我想避免这种情况，以将该段代码与特定版本的 optparse 解耦。
I have a class that handles command line arguments in my program using python's optparse module. It is also inherited by several classes to create subsets of parameters. To encapsulate the option parsing mechanism I want to reveal only a function add_option to inheriting classes. What this function does is then call optparse.make_option.
Is it a good practice to simply have my add_option method say that it accepts the same arguments as optparse.make_option in the documentation, and forward the arguments as *args and **kwargs?
Should I do some parameter checking beforehand? In a way I want to avoid this to decouple that piece of code as much from a specific version of optparse.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
似乎您希望您的子类了解命令行内容，这通常不是一个好主意。
您想要封装程序的整个配置输入部分，以便可以使用命令行、配置文件、其他 python 程序等来驱动它。
因此，我将从您的子类中删除对 add_option 的任何调用。
如果您想了解运行时的配置要求，我只需将该数据添加到您的子类中即可；让每个人都有一个成员或方法，可用于确定它需要哪种输入。
然后，您可以让输入管理器类遍历它们，提取这些数据，并使用它来驱动命令行、配置文件或您拥有的其他内容。
但老实说，我从来不需要在运行时这样做。我通常将所有配置内容提取到它自己的单独的东西中，以回答“用户需要告诉工具什么？”的问题，然后子类在配置数据结构中查找它们需要的内容。
It seems that you want your subclasses to have awareness of the command line stuff, which is often not a good idea.
You want to encapsulate the whole config input portion of your program so that you can drive it with a command line, config file, other python program, whatever.
So, I would remove any call to add_option from your subclasses.
If you want to discover what your config requirements look like at runtime, I would simply add that data to your subclasses; let each one have a member or method that can be used to figure out what kind of inputs it needs.
Then, you can have an input organizer class walk over them, pull this data out, and use it to drive a command line, config file, or what have you.
But honestly, I've never needed to do this at run time. I usually pull all that config stuff out to it's own separate thing which answers the question "What does the user need to tell the tool?", and then the subclasses go looking in the config data structure for what they need.
您确定子类化是您想要做的吗？您的首要行为可以在函数中实现。
Are you sure that subclassing is what you want to do? Your overriding behavior could just be implemented in a function.