Added the "cleared" method to Path, and updated the path module's documentation.

[pelson]

No description provided.

[mdboom]

Might as well do this in numpydoc format as well, while we're at it.

[pelson]

Ok. Think this is now ready @mdboom.

[mdboom]

Can we keep this as it was -- I know it doesn't really matter, but there are some tricks used to detect the end of paths that are made more obvious when you think of it in hex.

[pelson]

but there are some tricks used to detect the end of paths that are made more obvious when you think of it in hex

For whom? I can see the benefit for developers, but not for everyday users. I'd be happy to add a comment here to jig the readers memory, if that would suffice?

[mdboom]

Ok -- probably simplest to leave it as a (base 10) number, then. A comment here doesn't make sense either.

[mdboom]

I still think we should have cleaned return a Path instance -- we can bypass the constructor to make it nice and fast. It just seems unpythonic this way, to me at least.

[pelson]

I still think we should have cleaned return a Path instance

The two cases I can envisage with cleared both just use the codes and verts. That said, I'm happy enough to compromise and have implemented a fast constructor for Path.

Was that the kind of thing you had in mind?

[mdboom]

Yes -- that's basically what I had in mind. I think that's handy. There may be other cases in there where this should be used instead of the constructor, but that can wait for another PR.

[pelson]

Should add ... here so that those things are set correctly in the result.

Nice. I've added a commit. I expect to have to rebase this PR after the deprecations PR gets merged.

[pelson]

Other than that, I think this PR is good to go... Thanks for being patient with me ;)

No worries. Having your invaluable feedback on this module has been great.

I'll rebase now.

[pelson]

Ok. Once travis does its thing, lets merge 😄

[pelson]

Other than the spurious test failiure from master, the tests are passing with this PR.