Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Public introspection API for fields and checked types #47

Open
itamarst opened this issue Aug 11, 2015 · 4 comments
Open

Public introspection API for fields and checked types #47

itamarst opened this issue Aug 11, 2015 · 4 comments

Comments

@itamarst
Copy link
Contributor

We're about to add some code that introspects pyrsistent classes - in particular PRecord/PClass and the checked data structures - in order to detect changes to our pyrsistent-based configuration model. You can see a sketch of this code here: https://github.com/ClusterHQ/flocker/pull/1836/files#diff-c03885f8c4e64651ea9a499e99090a83R28

Unfortunately this currently requires using private pyrsistent APIs. It would be good to have a public API for finding this information. As a first pass it seems that adding this as extra methods to the classes themselves is problematic, insofar as it means subclasses get extra methods they weren't expecting. So maybe there should be a set of public external functions that extract information from the private implementation details.

@tobgu
Copy link
Owner

tobgu commented Aug 12, 2015

Sounds like a good idea!

I'm thinking along the lines of a public function (introspect?) taking the class as argument and calling a private method (introspect?) that does the actual introspection. It would return a dict/pmap with information about the class. Eg:

class Foo(PRecord):
     __invariant__ = lambda r: (r.y >= r.x, 'Blam!')
     x = field(type=int)
     y = field(type=int)

>>> introspect(Foo)
pmap({'__invariant__': ..., 'fields': pmap({'x': pmap({'type': (int,), ...}), ...})})

That's pretty much how I interpret your thoughts. Am I right?

@itamarst
Copy link
Contributor Author

Something like that, yeah. Possibly the field info could be represented by a PRecord or PClass, to make it simpler to use, but yeah.

@tobgu
Copy link
Owner

tobgu commented Aug 13, 2015

OK, I'll see what I can come up with unless you have something you want to contribute with. Perhaps this weekend if I can find some time.

@itamarst
Copy link
Contributor Author

Probably won't have time, but I can show you what I ended up using: https://github.com/ClusterHQ/flocker/pull/1842/files#diff-c03885f8c4e64651ea9a499e99090a83R30

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants