On Wed, Jan 11, 2017 at 11:41 PM, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote:
> > On Jan 9, 2017, at 4:13 AM, Jean-Paul Calderone <exar...@twistedmatrix.com> > wrote: > > On Mon, Jan 9, 2017 at 4:52 AM, Glyph Lefkowitz <gl...@twistedmatrix.com> > wrote: > >> On a related note, 'proto_helpers' is in a super awkward place. >> 'twisted.testing', anyone? :) >> > > Yes. I almost suggested this about a week ago when I was preparing to > contribute some testing code but then realized I couldn't contribute the > code after all. :( > > > Well, now it's just a matter of time :). > > Some further thoughts on this... What I've actually been doing elsewhere ( *mostly*) is to put the testing implementations quite near the real implementations. For example, I recently introduced `workproject.subscription_manager.{network_client,memory_client}`. But contrary to this, in txAWS I'm following the pre-existing pattern which is more like `txaws.service.AWSServiceRegion.get_ec2_client` & `txaws.testing.service.FakeAWSServiceRegion.get_ec2_client`. Which I prefer, I'm not really sure yet. Role-named modules are easy to recognize. On the other hand, testing code next to implementation code is easier to stumble across and you don't *have* to recognize a separate testing module to find it. Also, role-named modules tend to pile up and get in each other's way (start working with `twisted.testing`, `txaws.testing`, etc and things start to get confusing quickly). Additionally, a related idea is that often the testing implementation might actually serve as a good starting place for the real implementation. I think the code in txAWS is a good example of this (ie, the real and fake implementations duplicate a lot of logic with some pointless divergences). In the olden days I would have said "the testing implementation is often a good *base class* for the real implementation". But now I'll mumble something about composition. Put another way: - Clock should be the real implementation of all of the time-source independent logic of IReactorTime - FakeAWSServiceRegion should be the real implementation of the "client factory" logic (get_XXX_client) of AWSServiceRegion and so on. Perhaps this also speaks to the idea you mentioned that there should be a stack of thin abstractions but I snipped that content already so I'll try responding to that separately, later. Jean-Paul
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python