Steps to Reproduce
==================
-4. Drink two black russians courtesy of @aminusfu.
-3. Narrowly avoid a game of zombies.
-2. Meet @jimbaker.
-1. Decide to get http://aspen.io/ running on Jython yay!
0. Be on Mac OS Snow Leopard w/ XCode version blah blah blah.
1. Install Jython 2.5.2 (also applies to 2.5.3a1, don't see it in the 'Versions' list).
2. Build a jython virtualenv.
3. Install http://aspen.io/ v0.13.6 into it.
4. Run the aspen executable.
Expected Result
===============
Greetings, program! Welcome to port 8080.
Actual Result
=============
Traceback (most recent call last):
File "/Users/whit537/personal/aspen/master/jenv/bin/aspen", line 7, in <module>
sys.exit(
File "/Users/whit537/personal/aspen/master/aspen/server.py", line 98, in main
website.stop()
File "/Users/whit537/personal/aspen/master/aspen/server.py", line 62, in main
website.start()
File "/Users/whit537/personal/aspen/master/aspen/website.py", line 46, in start
self.engine.start()
File "/Users/whit537/personal/aspen/master/aspen/engines/cherrypy_.py", line 16, in start
self.cp_server.start()
File "/Users/whit537/personal/aspen/master/aspen/_cherrypy/wsgiserver.py", line 1767, in start
self.socket.listen(self.request_queue_size)
File "<string>", line 1, in listen
File "/Users/whit537/jython2.5.3b1/Lib/socket.py", line 1084, in listen
self._config()
File "/Users/whit537/jython2.5.3b1/Lib/socket.py", line 1084, in listen
self._config()
File "/Users/whit537/jython2.5.3b1/Lib/socket.py", line 1045, in _config
self.sock_impl.setsockopt(level, optname, self.pending_options[ (level, optname) ])
File "/Users/whit537/jython2.5.3b1/Lib/socket.py", line 330, in setsockopt
raise error(errno.ENOPROTOOPT, "Socket option '%s' (level '%s') not supported on socket(%s)" % (_constant_to_name(option), _constant_to_name(level), str(self.jsocket)))
socket.error: (42, "Socket option 'NI_IDN_USE_STD3_ASCII_RULES' (level 'IPPROTO_TCP') not supported on socket(ServerSocket[addr=/0.0.0.0,localport=8080])")
I hacked jython*/Lib/socket.py and if I skip option=256 in getsockopt I can get service from aspen, which is sweet. IDN is a little esoteric (sadly?), so not sure what to do with this. Maybe a workaround to turn this off from the aspen layer? This is prolly specific to Max OS?

There are a few issues going on here.
First of all is bad reporting from the jython socket module. The option that is causing the error is not called "NI_IDN_USE_STD3_ASCII_RULES", but is actually "TCP_NODELAY". The problem here is that the two options share the same symbolic constant, 256. The reverse lookup process I used for improved error reporting is failing in this case. I need to correct that.
The second problem is that the CherryPy WSGI server is setting the TCP_NODELAY option on a listening socket. Strictly speaking, this option has no meaning for listening sockets, because it affects the way data is sent over the socket. But data is not sent over listening sockets, which are solely used for accepting incoming connections.
But many operating systems nowadays let the user set options on listening sockets: sockets which are accepted from the listening sockets then inherit these options. So if TCP_NODELAY is set on the listening socket, then all socket connections it accepts will inherit the TCP_NODELAY setting.
Jython currently does not support this socket option inheritance, but we have an open request to support socket option inheritance in this way.
Server sockets do not support client options and propagate them to 'accept'ed client sockets.
http://bugs.jython.org/issue1309
So you have two options in this case
1. Drop the use of the TCP_NODELAY socket option. In the CherryPy WSGI server, the "nodelay" option of the HTTPServer class determines this.
2. If you want to still use the TCP_NODELAY option on sockets connected to the client, then set the option directly on those sockets after they have been accept'ed.

> I have updated Aspen's trove classifiers to advertise Jython support.
> Huzzah!
Good job! Well done!
Maybe an announcement to the jython-users list?
Is there an aspen users list?
Leaving this bug open for now, because I have to fix the wrong and misleading error message.