-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Structure of v2.0 public API #42
Comments
As usual, API will be reflected both in docs and in what |
@jayvdb The more I think about this, the more it seems like everything should be private/implementation-detail except Do you think that users would frequently want to use Separately, if I read your intent correctly based on your ideas in #4, the logic/implementation of the content teeing may change appreciably in the future anyways. To my mind, all this argues for an aggressive expansion of what's considered private. |
Hm. Though, if users may want to be checking types of the mocked streams, then it I guess it makes more sense for those types to be part of the public API, with the corresponding promise that they won't be renamed/etc. in a breaking way without some notice coming from a major version bump... |
(Continued from this discussion on #64.) I'm still coming to grips with the scope and granularity of what you're working towards, @jayvdb, so I suspect my vision on things is pretty incomplete. But, hazily, it seems like it would be nice to have a 'dual-level' (or 'multi-level'?) API, where, e.g., for simple cases users would just tee one/both stdin and stderr over to stdout and do direct string comparisons on actual/expect; but for complex cases, things like #65 and all of the |
Im also working it out as I go ;-), trying to incorporate the functionality needed by various existing similar implementations, especially those which are currently limited because of the lack of proper TextIOWrapper streams (which is usually the case, including pytest's capture). I knew about coala-utils before starting this of course, but that hasnt been a driver as it is already stable. I am now using it only as a sample re-implementation, to see where the pain points are. Beyond the simple case, I think we need an reasonably easy solution for selecting a mix of streams to be mocked as that will be a common case. I suspect the advanced users need to be using composition rather than simply inheritance and instantiation arguments, so that people can use our bases but extend them and implement their own 'manager' classes which has the features they need. I expect like coala-utils and the pytest plugin, they will have already built fairly advanced testing features (even though the streams are very basic StringIO) and they dont want to loose them, and don't have a reason for trying to push their features into a future stdio-mgr v3 - their existing test rig is working -- why would they invest in someone elses test rigging. To bring them into the fold, we need multiple levels, so they find a way to add the features they already have. I do want a release soon-ish, so we cant get all the features done, but my soonish needs are all really basic usage, like the |
For now, this assumes that
stdio_mgr
will remain a@contextmanager
-decorated function, rather than a fullStdioMgr
class.stdio_mgr
must be public.IIUC the main other consideration is whether to make
RandomTextIO
andTeeStdin
themselves public; or, to make them private but provide a public means for users to identify whether they are in use, or whether a givenstdio
stream is (most likely) the real one fromsys
.The latter could be achieved by, e.g., a public stub superclass.
@bskinn best stab at a summary of the options:
TeeStdin
was implicitly public in v1.0.xRandomTextIO
/TeeStdin
if anything other than optional keyword arguments are needed.isinstance
check on a single public class, rather than having to remember both classesTeeStdin
out of ~public API, a break from v1.0.xThe text was updated successfully, but these errors were encountered: