Add provisional implementation for #1081

[Kentzo]

[minrk]

Sorry for the delay in reviewing this. I've no specific objection, but it doesn't really seem like pyzmq is the right place for it. What's the benefit of this over, say, using the builtin urlparse for parsing URLs, which gives you scheme, port, etc.?

[Kentzo]

The main benefit is to be able to integrate with various libraries that deal with user input such as CLI toolkits, config parsers, ORM etc. urlparse is too abstract to be useful as it can only represent 2 components of a zeromq endpoint: scheme and netloc. In my development experience I often need to access just a port or just an interface of a TCP endpoint. And there are other, more complex transports.

Although it can be developed as an independent package, having it bundled provide the following benefits:

• Native support by pyzmq methods, so one can pass an object into bind / connect etc (implementation only needs to wrap arguments with str or repr)
• Easier to keep it in sync with zeromq API
• More attention would allow to have one "definitive" implementation

[minrk]

is too abstract to be useful as it can only represent 2 components of a zeromq endpoint: scheme and netloc

that's not generally true, urlparse extracts host and port as well:

parsed  = urlparse('tcp://127.0.0.1:5555')
parsed.port # 5555
parsed.hostname # '127.0.0.1'

but that doesn't cover more complex non-url transports, such as the multi-endpoint URLs separated by ;.

This is fine by me. What more do you want to do for this PR? Can you add docs and tests?

[Kentzo]

I would like to see how far it can / should be integrated into pyzmq. I think both connect and bind should be able to accept it, what about last_endpoint?

[minrk]

I don't think we should change the return type of any of the existing methods, but accepting these objects in bind/connect makes sense.

[Kentzo]

Perhaps both Address and Endpoint should subclass UserString? Current __iter__ can be replaced with the as_tuple method.

[minrk]

I think that specifically, no base pyzmq APIs should return anything but basic types. Providing convenient wrappers is okay, but I wouldn't change the types, even if they are subclasses that satisfy isinstance

[Kentzo]

@minrk Ok, but considering that, would it be better to have them as strings or objects?

[minrk]

Objects, I think.

[Kentzo]

UserString would allow to avoid any changes to pyzmq though. Which makes sense, as URL introspection does not make sense there. Not with current API.