Yury Selivanov added the comment: > I can be convenient to have a single Server object with *all* listening > sockets. So I like the idea of supporting multiple ports. It's very cheap to > support it.
I like the idea too, but I'm not sure how to redesign the function's signature to accept multiple hosts & ports. We have a separate param for 'port', and this patch allows to pass an array of hosts in 'host' argument. Should we allow passing an array of (host, port) tuples in 'host' with 'None' in 'port'? This would be one ugly method... > Since the consensus on python-dev looks more to keep the provisional API for > asyncion in Python 3.5, I propose to even modify Python 3.4 to not add too > many "if python >= 3.5..." checks in asyncio source code. asyncio is provisional in 3.4 (and now in 3.5 too), so we can just keep updating it in bugfix releases. > If you really prefer to keep Python 3.4 unchanged, we should at least add the > feature in Python 3.5.1, having to wait for Python 3.6 is too long, no? This was before we reinstated asyncio as provisional in 3.5. But before committing this change, let's agree if we want this API to accept multiple ports when you specify more than one host. We also need to create a dev branch on github/asyncio, so that it's easier for us to sync PyPI package with CPython releases. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23630> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
