-
Notifications
You must be signed in to change notification settings - Fork 35
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
Add automatic generation of metadata accessors #23
Conversation
Wow, this is a lot more (and sooner) than I expected! Thank you! This is not easy to soak in, to be honest, but I'll do my best to work through this code to appreciate the beauty of it. It would definitely help if you could briefly demonstrate all of the magic the parser does in terms of (meta)data access, though, especially with path parsing. I want to document it so others can enjoy it as well. One question that I've already had since the previous discussion is this: do we want to collect lists of metadata from all base classes? That way no subclasses can ever remove any metadata, is that right? I do realize that having to repeat the list in subclasses would be undesirable. |
Thank you for extending the documentation. Apparently I misunderstood the code yesterday and thought that I'm ready to merge as is, but I'm curious about one thing: if we traverse all base classes to collect metadata specifications, does it mean that there is no straightforward way to remove any metadata in subclasses? This is not a practical concern, though. |
I've added a bit more documentation to the metaclass and added explicit override support. To prevent a metadata property from being added, you can explicitly set the name to some value or define a method/property with the same name. class MyMzTab(mztab.MzTab):
title = "foo" This will not get a The path parsing is something I'm not quite satisfied with since I implemented it to deal with complex collections in table headings e.g. Furthermore, outside of using the tables in "raw" mode, nobody will get that behavior, just the existing |
Indeed, categorizing some data as lists and perhaps even some rich parsing, like for modifications, would be a significant enhancement. I don't have any specific applications for this, though. I guess we can keep it in mind as a direction for future development. Thank you again for the work. Should I merge now? |
I was distracted and didn't document the new raft of properties. This has been added by automatically setting the I wasn't sure how to add this to All set to merge. Probably should have made this a draft. |
The |
I thought I had tested that option with Sphinx 3.2.1 and it worked locally. It doesn't matter though. Thank you for adding the changelog entry. All set to merge. |
Implements the metaclass-based property generator and collection folding logic.
There are almost enough properties generated to justify the amount of extra metaprogramming code added.