On Mar 17, 2012, at 8:53 PM, Itamar Turner-Trauring wrote:

Apparently this was removed as part of deprecating the old strports syntax, but:

1) "twistd web --port=9000" never gave a deprecation warnings.

This is a problem for future user-visible feature deprecations: Python won't show you deprecation warnings any more unless you ask, so if a feature is deprecated in the user interface of something, we need a separate mechanism to alert the user of it. The idea with most features is that trial will always show you all deprecation warnings, so you'll notice while running your tests :). Somebody needs to go through and look at currently deprecated command-line features to ensure that this won't happen in the future - any volunteers?.

itamar@blake:~$ twistd --version twistd (the Twisted daemon) 11.0.0 Copyright (c) 2001-2011 Twisted Matrix Laboratories. See LICENSE for details.

itamar@blake:~$ twistd -n web --port=9000 --path=/ 2012-03-17 20:50:21-0400 [-] Log opened. 2012-03-17 20:50:21-0400 [-] twistd 11.0.0 (/usr/bin/python 2.7.2) starting up. 2012-03-17 20:50:21-0400 [-] reactor class: twisted.internet.selectreactor.SelectReactor. 2012-03-17 20:50:21-0400 [-] twisted.web.server.Site starting on 9000 2012-03-17 20:50:21-0400 [-] Starting factory <twisted.web.server.Site instance at 0x180bd40>

2) The current --help just says " -p, --port= strports description of the port to start the server on." It'll be completely unclear to users what that means.

There should be a new ticket: --help-strports or something, and every option that takes one should refer to it, similar to --help-auth-types for cred plugins.

I am tempted to revert the ticket that removed this functionality - can anyone tell me why we shouldn't?

In particular, before the removal should be re-merged again, the original syntax should be restored, along with decent --help. We should always support just giving the port number and defaulting to TCP. As it is, we've gone from a straightforward command line option that also had some sophisticated features to something that will break in a mysterious, hard to debug manner.

I am inclined to agree, sort of. Currently, the plain integer will default to just IPv4. An un-decorated integer really should (eventually) default to listening on all available interfaces, IPv4 and IPv6 together. Jean-Paul managed to convince me in the review for http://twistedmatrix.com/trac/ticket/4473 that supporting raw integers made the implementation ugly, but reflecting upon this experience I think I was wrong, and that clarity of the user experience here is more important than clarity of the implementation. I do still think that examples should move towards using 'tcp:80', though, so users might realize there's something other than 'tcp' that could go there. I'm glad you noticed it: please go ahead and revert the removal. -glyph