RF File's namedtuple to reflect 1-to-1 File's attributes (path, filename, dirname) #84
Conversation
Original reason - to make https://github.com/bids-standard/pybids/blob/master/examples/pybids%20tutorial.ipynb great again. ATM was crashing since returned by search File named tuples (BTW confusing/overlapping with File class in the actual File class) had no .path which File has
|
The tutorial hasn't been updated yet to reflect the changes in master (and that will be released in 0.7). There's an issue for this: bids-standard/pybids#259. With respect to this particular issue, there's never been a |
|
In 0.7.0, the default return type is object, and tuple is deprecated. So I think we no longer need this, as people shouldn't be using the tuple at all (though typing this is making me realize that I forgot to include a deprecation warning in 0.7.0—will do that). Safe to close? |
Initially ran into the problem while trying to go through pybids's tutorial which would fail now since there is no .path in the "File" (tuple) provided to
getcallFile.pathstored as.pathof namedtuple, and then filename and dirname in corresponding fields as wellBoth changes are questionable (feel welcome to fix some other way) since I am not exactly sure on the "life span" of the namedtuple here and either other ways (make
Filehashable) for intended use (using as dict keys?) were considered... if it was intended to be used later to "reinstantiate"Fileobject, then it would fail since that one needs only "filename" which gets assigned to "path" (khe khe) and the other two are recomputed. Probably if that was intended, namedtuple would need to store also initial class.Obviously that this change does brake pybids, but the point is that there seems to be this inconsistency and pybids seems to be broken anyways already according to that example failures. With this change and master of grabbit I am getting "9 failed, 101 passed, 10 warnings, 1 error" in pybids (with 111 passed without).