On Mon, 2010-12-20 at 13:47 +0000, Floris Bruynooghe wrote:
> On 20 December 2010 09:56, Virgil Dupras <hs...@hardcoded.net> wrote:
> >
> > On 2010-12-20, at 10:41 AM, Ronny Pfannschmidt wrote:
> >> On Mon, 2010-12-20 at 09:22 +0100, Virgil Dupras wrote:
> >>> On 2010-12-19, at 3:38 PM, Floris Bruynooghe wrote:
> >>>>
> >>>> Looking at the patch_osstat() it seems to me that it just fakes
> >>>> os.stat() for one specific path but uses the original in place
> >>>> otherwise. This sounds like it could be just a specialised object
> >>>> used to patch with. I can imagine the monkeypatch plugin to provide a
> >>>> funcarg which provides this functionality, e.g.:
> >>>>
> >>>> def test_foo(monkeypatch, monkey_osstat):
> >>>> monkeypatch.setattr(monkey_ossstat('/tmp/some_file'))
> >>>> ...
> >>>>
> >>>
> >>> This would kind of work, but it would become complicated to patch
> >>> os.stat() for two or more files, wouldn't it?
> >> there could be a monkey_stat object that controlls the set of
> >> files/subtrees under control
> >>
> >
> > Yes, of course, but keeping the proposed API would make it unintuitive for
> > multiple files. Example:
> >
> > monkeypatch.setattr(os, 'stat', monkey_osstat('some_file'))
> > monkeypatch.setattr(os, 'stat', monkey_osstat('some_other_file'))
> >
> > We're not sure what happens there, as os.stat is patched twice. Are we
> > overwriting our old monkeypatch, or is there some magic caching inside
> > monkey_osstat() making it work for both files? That's the kind of question
> > the developer will wonder about.
>
> I was thinking of something slightly different when I said this:
>
> def test_foo(monkeypatch, monkey_osstat):
> stat = monkey_ossstat('file1', 'file2')
> stat.add_file('file3')
> monkeypatch.setattr(os, 'stat', stat)
> stat.add_file('file4', st_size=123)
i was thinking more along the lines of::
def test_foo(osstat_patch):
stat.add_file(...) #setup single files
stat.add_callback(root, somefunction) # hand off a whole tree
i suppose better function names are possible
also im wondering if this should integrate with py.path more deeply
(having a virtual view on the whole fs seems neat)
>
> That makes it very clear what happens (at least to me).
>
> But as Ronny said it's probably best to try out the various approaches
> in an external plugin to get past the bikeshedding. If that results
> in a stable api which is getting used it could be merged with the
> core. This is what is happening to the capturelog plugin too I think.
>
> As for the patch_time() I've never needed it but I understand now why
> you want it. Doing this via a funcarg which you then use in one of
> the normal monkeypatch methods will probably be very cumbersome so a
> funcarg that does the patching directly is probably the way to go
> (which could eventually become something like
> "monkeypatch.patch_time(...)" I guess)
>
> Regards
> Floris
>
> PS: I speak with no authority to the development of py.test, I'm just
> another user.
>
>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
