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.

(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.

what's the status of this issue ?

Some responses to the issues raised by Terry would be helpful, especially the incompatibility by adding the RuntimeError. It looks like it forces a race on the normal usage of shutdown(). See also Issue 12463: it seems different people have different ideas about what this method should do.

Without understanding the motivation(s), I can’t really suggest anything better.