[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

Changes by Louie Lu : -- pull_requests: +1598 ___ Python tracker ___ ___ Python-bugs-list

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

Changes by Dominic Mayers : Removed file: http://bugs.python.org/file46775/Issue29947_for_discussion_03.patch ___ Python tracker ___

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

Dominic Mayers added the comment: An improved version of the patch, I hope. I will remove the old patch, because it's really does not help to see the old versions. -- Added file: http://bugs.python.org/file46781/Issue29947_for_discussion_04.patch

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

Changes by Dominic Mayers : Added file: http://bugs.python.org/file46775/Issue29947_for_discussion_03.patch ___ Python tracker ___

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

Changes by Dominic Mayers : Removed file: http://bugs.python.org/file46774/Issue29947_for_discussion_02.patch ___ Python tracker ___

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

Changes by Dominic Mayers : Removed file: http://bugs.python.org/file46770/Issue29947_for_discussion.patch ___ Python tracker ___

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

Dominic Mayers added the comment: I simplified the patch. Using a class as a factory function is the simplest case, so I took advantage of this. I also give one way to pass extra parameters to the handler in the factory function, because it's the main reason why we cannot always use a class.

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

Dominic Mayers added the comment: The key point, IMHO, is that the BaseRequestHandler class is just provided as an option and its API (setup, handle and finish) is ignored by the code that we support. Some applications may have used the API, but these are details in applications. Simply, we

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

Dominic Mayers added the comment: I started to look at the documentation to see what would need to be changed, assuming that we agree for a change in the API. Just for the purpose of this discussion, I created a patch that only change the comments in socketserver.py. --

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

Changes by Dominic Mayers : -- keywords: +patch Added file: http://bugs.python.org/file46770/Issue29947_for_discussion.patch ___ Python tracker

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

Changes by Dominic Mayers : Removed file: http://bugs.python.org/file46768/factorymixinclass ___ Python tracker ___

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

R. David Murray added the comment: Yes, the difficulty in renaming the parameter was why I suggested a doc change only. I'm not sure it it is worth it to go through a deprecation cycle for socketserver to change the name, though it certainly would be nice. Martin and I could make that

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

Dominic Mayers added the comment: I did not think very far when said that renaming the parameter could not possibly break the code ! Oh well ! But, renaming the parameter was not important in itself. It was to make the situation clearer and easier for those who write the documentation.

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

Martin Panter added the comment: By “factory instance”, I presume you just mean a function (or class or method) that returns an appropriate object when called. (I think these are normally called “factory functions”. Instances are objects, the things that class constructors and factories

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

Dominic Mayers added the comment: Oops, I did not realize that David was one of the developers. Well, may be this needs the attention of more than one developer. -- ___ Python tracker

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

Dominic Mayers added the comment: The reason why I feel we should not make it immediately a documentation issue is that I don't know how a person working on documentation could proceed ahead without a clear go ahead signal from developers. In that sense, having a documentation that says that

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

R. David Murray added the comment: Given how old socket server is, and that it doesn't actually require that API, we should probably just reword the documentation so that it is clear that RequestHandlerClass is the default Handler implementation (and that you can work with setup/handle/finish

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

R. David Murray added the comment: Well, we could document it as a factory argument, and explain that the argument name is an historical artifact. -- ___ Python tracker

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

Dominic Mayers added the comment: To sum up, David clarified that we can in fact easily pass an arbitrary factory method that creates and starts a request handler, instead of a request handler class with setup, handle and finish in its API. This could indeed be a valid reason to consider this

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

Dominic Mayers added the comment: Perhaps I should raise a separate issue, but it is related, because the current code "requires" that we define an handler class with `setup()`, `handle()` and `finish()` in its API. If you look at the actual code, there is no such requirement. We only have to

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

Dominic Mayers added the comment: I am a bit ashamed that I missed that. Still, the intent in the current code, the name of the parameter, the examples, etc. is that we pass the handler class. This is more than its __init__ function and less than a generic factory method. An important

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

R. David Murray added the comment: I think I'm missing something here. What prevents one from passing a factory function as the RequestHandlerClass argument? In Python, a class name *is* a factory function for class instances. -- nosy: +r.david.murray

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

Dominic Mayers added the comment: On the other hand, it occurs to me that this seems way more flexible than passing the object through the server, because you share the factory with the server, not only the object. This means that you could even change the type of the handler while the server

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

Changes by Dominic Mayers : -- resolution: wont fix -> status: closed -> open ___ Python tracker ___

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

Dominic Mayers added the comment: Finally, I looked around and people just use the server to pass any extra parameter. I do find it awkward, but it works and it is simple, in fact simpler than having to define a factory object. I don't close it, because I will be happy to see another opinion.

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

Dominic Mayers added the comment: One way to make the factory optional is to offer a MixIn. I attached a file with a FactoryMixIn. It's just that I find it awkward that the proposed approach is to pass the extra parameters in a subclassed server. More modern approaches should also be offered.

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

Eric V. Smith added the comment: Just a guess, but it's because this code was written at a time when subclassing was the preferred way to extend code. Now we know better :), but it's not possible to change history, unfortunately. Lots of code depends on the current behavior. If you find a

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

New submission from Dominic Mayers: I am just curious to know if someone considered the idea of passing a factory instance that returns RequestHandlerClass instances instead of directly passing the class? It may affect existing handlers that read non local variables, but there should be a way