classification
Title: Add socketserver running property
Type: enhancement Stage: patch review
Components: Versions: Python 3.3
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: giampaolo.rodola, pitrou, terry.reedy
Priority: normal Keywords: needs review

Created on 2012-03-20 16:53 by giampaolo.rodola, last changed 2012-03-27 15:58 by terry.reedy.

Files
File name Uploaded Description Edit
socketserver.patch giampaolo.rodola, 2012-03-20 16:53 review
Messages (2)
msg156432 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2012-03-20 16:53
Patch in attachment adds a "running" property to figure out whether the server is running or not.

Also it raises an exception in case the server has already been started or stopped. IMO such an event should be prevented beforehand as it signals an application error.

Finally, __repr__ has been modified in order to reflect the current server status.
msg156937 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2012-03-27 15:58
(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.
History
Date User Action Args
2012-03-27 15:58:28terry.reedysetnosy: + terry.reedy
messages: + msg156937
2012-03-20 18:24:28r.david.murraysettype: enhancement
2012-03-20 16:55:26giampaolo.rodolasetkeywords: + needs review, - patch
2012-03-20 16:54:54giampaolo.rodolasettitle: Add socketserver.running property -> Add socketserver running property
2012-03-20 16:53:10giampaolo.rodolacreate