On Thu, Jan 29, 2015 at 11:35 AM, Andrew Stitcher <astitc...@redhat.com> wrote:
> On Thu, 2015-01-29 at 09:56 -0500, Justin Ross wrote: > > ... > > PROTON-805 adds more of the latter to proton/utils.py, and it already had > > BlockingConnection. Having both types of util in one module ends up > making > > imports a mess because it contains at once quite low-level things and > > high-level things. > > If some of the things in the module are for internal library only use > then they should not be exported and to some extent the namespace is > irrelevant. I am aware that python does not do this terribly well, and > that may be a reason in python (and other languages deficient in access > control) to have an "internal" namespace. > Sorry, I should have said *primarily* for internal use. It's more about their place in the dependency stack. They are language-library extensions, not proton-library extensions. I think there are (or might be) legitimate cases where these may be public, such as for a Url class. > Maybe we should have proton/extras.py for stuff like BlockingConnection > and > > SyncRequestResponseHandler and reserve utils.py for the internal utility > > For internal utilities I strongly suggest a name that says - do not use > this internal library use only. > I very much agree that we should do that where we can. Indeed, there's some work to do in the python code to avoid leaking symbols we don't intend for wide use. In python, it's easy to do inadvertently.
