answering question to #44 (comment) (which is now closed) here

@yarikoptic So what should #58 do about resolving path attributes when decorating methods?

I am thinking about something along the lines of abstracting away "fingerprinters" so we could generalize to not only path and not only the first arg of the function, but also to attributes etc. Inspection of signature to figure out which arguments we need to deal with is to be only once so it should not have notable performance hit IMHO.

Define base class Fingerprinter which will be subclassed for File and Directory and where to _get_file_fingerprint and _get_dir_fingerprint would fold into along with the modified_in_window to be called at the end of them to return None if "too early"
PathFingerprinter adapter will switch between file and dir fingerprinter depending on what the value (path) is (directory or not)
generalize memoize_path into memoize_params (or any other name you like) which would also take an option (so more of functions nesting, uff) e.g. params: dict[str, Fingerprinter] to specify which fingerprinter to use for the args needing special handling. And add ability to specify access to class instance attributes

    params={
      "path": PathFingerprinter,
      "self.path": PathFingerprinter,  # here due to `self.` take corresponding attribute of the bound instance 
    }

edit 1: or make it more explicit by separate two options: args and params of the same kind.
4. arguments (not self. attributes) which went through "transformation" will be ignored in the calls to joblib like we did for the path. Their Fingerprinter should provide desired value as part of the returned fingerprint (e.g. resolved path as you @jwodder did in #45 IIRC)

Uh oh!

Support decorating instance methods of classes with path attributes #58

Description

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions