I would suggest to make SimpleXMLRPCServer.SimpleXMLRPCServer.register_function a decorator function.
See the attached file for the solution I wrote (l.209-240), which also works with the current syntax:
@server.register_function
@server.register_function('name')
@server.register_function(name='name')
or:
server.register_function(func)
server.register_function(func, name='name')
server.register_function(function=func, name='name')

So as far as I've tested it (py2.6), it is fully backwards compatible and supports decorators in addition.

Can you submit your patch as a unified diff -- it's not easy to tell where you made changes to that file.
Can you also include tests showing how this is used, especially using register_function in both the old way and the new way you propose? Lib/test/test_xmlrpc.py is a good place to put your tests.

I'm not very used to working with bug/issue trackers, is there any tutorial here, where this is explained?

I did the stuff you asked me to do:

diff: http://paste.pocoo.org/compare/169357/169359/
test: http://paste.pocoo.org/show/169360/

http://www.python.org/dev/workflow/ and http://python.org/dev/faq/ should help you get started. The workflow doc will let you know what the process is around here. The FAQ will tell you how to setup Subversion, how to make a diff, etc.

With that said, I think your change could be useful. Being that it's a feature request, it will go into 2.7 if accepted.

OK, thank you for the links!

Do you still want me to do anything (like test cases etc.)?

Once you get a Subversion checkout of the source, have a look in Lib/test/test_xmlrpc.py for examples of how things are currently tested (using unittest). Once you get a feel for it, add new tests for what your changes do. The file you paste'd looks good as an example, you just have to make actual tests out of it now.

OK, will work on it and reply as soon as I have results!

I'm attaching a patch against 2.7 tip for an initial implementation of this decorator feature as well as sample usage in unittest, to get the ball rolling.

The modified function should work as a decorator while preserving backward compatibility to be used in a traditional method call.

Santoso - since this is a feature request it would need to be retargeted to 3.3

I see. Attaching a patch against 3.3 tip, then.

sorry, I totally forgot about this...

Here's some quick review comments:

• xmlrpc_register_decorator_py33.patch doesn't apply cleanly anymore.

• •    serv.register_function(my_function)
    

  + serv.register_function(_my_function, name='my_function')

  We should keep serv.register_function(my_function) as is and add a separate line that uses the new 'name' parameter.

• We can now change set([...]) to {...] in test_introspection1

• •        add_result, pow_result, div_result, \\
    

  + myfunc_result, myfunc2_result = multicall()

  No need to use the \ character.

• The docstring of Lib/xmlrpc/server.py is already too long. It's better not to update it.

• Please use the existing code style (name = None -> name=None)

• We can make register_function act both as a decorator and as a decorator factory without changing its signature.

• We need to add a test to cover TypeError case.

• Documentation is missing. See Doc/library/xmlrpc.server.rst.

• Please add a note to Doc/whatsnew/3.6.rst.

Hi, I've written a patch to accomplish this in Py3.6.

This patch is much cleaner but has one drawback, when used as decorator factory, you have to specify name as a keyword argument. But considering the codes that have to been imported to check arguments, I think it's not bad. (I don't want to check function is a string or not.)

Also one side effect that I can not eliminate is when it is used as a normal function, the function instead of None is returned. I see the former patches get this problem too.

Hope to get feedback.

ping

I don't have an opinion about needing this feature. But for accepting it needs more documenting. The signature should be updated, the new feature should be documented in the main text, not only in the versionchanged note. Needed examples of using egister_function as decorator.

From the old comments from Brian it seems he's willing to accept such a feature. But unfortunately Brian seems not interested in this now. IMHO, this is good feature especially to people familiar with Bottle and Flask. Writing in a decorator way seems more elegant to me. Nevertheless, add more doc.

Also one side effect that I can not eliminate is when it is used as a normal function, the function instead of None is returned. I see the former patches get this problem too.

I think this does not matter after seeing functools.singledispatch. The versionadded tags should be changed to versionchanged in my last patch.

+1 for the decorator idea. It feels very natural.

A little off topic, I do not like the with-statement example that we currently have in the docs. I think it is bad design to put some much code inside with-block. In the micro-webframeworks, we register functions separately from launching the server. The same practice should apply here as well.

Thanks Raymond. I would like to keep the example style another issue, not this one. :-) And I hope someone is willing to review the PR.

Thanks everyone involved!

New changeset 267b9d2 by Xiang Zhang in branch 'master':
bpo-7769: enable xmlrpc.server.SimpleXMLRPCDispatcher.register_function used as decorator (GH-231)
267b9d2