Updated append method to keep an "_end" hint. Purpose is to address …

[hsolbrig]

…performance problems for large lists

[coveralls]

Coverage increased (+0.005%) to 63.991% when pulling 4e41256 on hsolbrig:master into d7013fb on RDFLib:master.

[gromgull]

I prefer (self._end, RDF.rest, RDF.nil) in graph, which may also be slightly faster?

[gromgull]

My gut feeling tells me there are some "cache invalidation" issues here, but since the code actually checks if (_end, rest, NIL) is in the graph the only thing I can think of is:

• Make a list, the Collection's 'end' points to the end.
• Make another list, move (outside the collection api) the tail of the first list to the end of this.
• Now the first Collection has end pointing to the end of the wrong list.

BUT - anyone who does this probably deserves everything coming to them :)

Still, it would be a nightmarish bug to debug.

[gromgull]

Actually, thinking about it - another, easier way to mess up is to create two objects for managing the same collection.

This raises the question - why don't we have a utility function on the graph objects for creating collections? Like we do for Resource? Then that could have had an internal registry of the collection objects and returned the same if requested again.

[joernhees]

PR for #609

[joernhees]

yupp, i see the same issues... #609 was about the constructor, while this PR in general tries to improve subsequent append calls by giving Collection a state, which might cause problems later on.

What about giving append an optional arg _end? It would be a private arg to indicate that its use is potentially dangerous if you don't know what you're doing. If set it, append would trust it to be the end-pointer and we could use it to provide an O(n) extend method, which we could also use in the ctor?

[gromgull]

As detailed in the ticket, I fixed this with a safer addition of an __iadd__ method.