Provide better abstraction for citations and output classes about duecredit HOT 5 OPEN

at which point? if in collector -- probably not worth it... In the IO -- again not sure since we would need a custom structure from all the references based on desired output: e.g. currently nested hierarchy, but could be more flat (than such separation could be the natural way to re-present)

from duecredit.

so, atm we are storing the citations referenced by the entry key, but this is not optimal because we can have the same entry for different functions/modules/packages (see #30). I think we should refactor the Collector or the citations so that they are referenced according to the path and not to the entry key. What do you think?

EDIT: what I meant is that in DueCreditCollector we store everything referenced by the path, and we store a set of citations for each path

from duecredit.

you are 100% correct. indeed storing by entry key leads to collisions. But the same by path alone -- multiple citations per each path would collide. May be by a tuple (entry_key, path) then? ;) or citations could be a dict (by key) of dicts (by path). This way we could still quickly determine the correct citation, either it was hit before etc. May be the simplest just to make compound key (entry, path) and see how implementation holds and if you feel that dict of dicts would be better -- reimplement that way

from duecredit.

I was thinking of implementing __eq__ for the Citation class, so that we can use sets on those, and store for each path key a set of citations, so we automatically avoid any duplicate. But a tuple as key seems good to me too.

from duecredit.

On Fri, 31 Jul 2015, Matteo Visconti di Oleggio Castello wrote:

I was thinking of implementing eq for the Citation class, so that we
can use sets on those, and store for each path key a set of citations, so
we automatically avoid any duplicate. But a tuple as key seems good to me
too.

sets operate only on immutable hashable objects, so even with
eq I think that would not work. that immutable aspect might be the
one which would forbid us to make sets of them etc

Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Research Scientist, Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik

from duecredit.