Terry J. Reedy <tjre...@udel.edu> added the comment: (I have not used socketserver so my response is somewhat theoretical.)
.__running seems partly if not completely redundant as the negation of .__is_shutdown. However, I do not see that exposed. I suspect that this was not thought to be needed because the api design is that the user tells the server what state to be in without worrying about what state it is in. File objects have a .closed attribute, but they cannot be reopened when they are, to make sure that they are. A .shutdown attribute might be added. Is the server status actually trivalent? new (never started), running, shutdown? If so, perhaps there should be one trivalent status attribute. I disagree that telling the server to be in the state it is already in *is* an error. Whether or not to make it an error is a design philosophy and an api choice. For instance, closing a closed file is not an error. In any case, changing the api design is a change, one that could break code. So it would require a compelling reason, a deprecation warning, and a deprecation period. Without a compelling reason stronger than 'IMO', I think that part of the request should be rejected. Making an exception part of the api of .server_activate, which explicitly 'May be overridden.', would impose a requirement on overriding methods in subclasses, including those already written. The doc for RuntimeError says "(This exception is mostly a relic from a previous version of the interpreter; it is not used very much any more.)". I believe the usual practice is to define a module-specific exception subclass. There is not one now because the current api philosophy does not need one. The representation of a file does not include is open/closed status. On the other hand, there is the .closed attribute. So if no attribute is added, putting something in the representation might be done. ---------- nosy: +terry.reedy _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14375> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
