Address third part of 451: Storing Key.parent on instance for future calls

[dhermes]

Making Key.parent return the same instance on return calls.

This is in preparation for adding parent to the constructor.

Addresses third part of #451.

NOTE: This has #458 as a diffbase.

[coveralls]

Coverage remained the same when pulling f4d569c on dhermes:fix-451-part3 into b343acf on GoogleCloudPlatform:master.

[tseaver]

Caching _parent (at least explicitly, rather than via some decorator on the property) seems odd: do we expect that to be a frequently-accessed path?

[tseaver]

Pyramid has a reify decorator used for memoizing the result of a function.

[coveralls]

Coverage remained the same when pulling 9aff877 on dhermes:fix-451-part3 into 8cb41f6 on GoogleCloudPlatform:master.

[dhermes]

I've seen a few ActiveState recipes along those lines as well.

It seems like an unneeded maintenance cost for something we're only using once. As long as the internal attr (_parent) is protected, we don't have any contract with users RE: existence in the future, so can always update if we find Key should have more hidden properties (this doesn't seem likely unless the .proto spec changes).

The underlying reason for memoizing is to allow:

>>> key1 = Key('Foo', 'bar', parent=parent)
>>> key2 = Key('Foo', 'baz', parent=parent)
>>> key1.parent is key2.parent
True

And of course to get tiny gc / constructor speed optimizations (as you mentioned, these seem to be negligible).

[tseaver]

OK, LGTM.