Look at the full collection of Exchange classes#1761
Look at the full collection of Exchange classes#1761shreve wants to merge 4 commits intojupyter:mainfrom
Conversation
In `nbgrader.apps.baseapp.NbGrader.all_configurable_classes`, there was a subtle problem in the way it was deciding whether to include classes from `exchange.default` which meant that none were ever included. The same work to do this check was being done 5 different times in unique blocks of code, one of which being incorrectly implemented. To avoid this type of mistake in the future, I added an inline function to do that check so it's done in a uniform way every time.
|
There is a kind of interesting question about the right way to do this. The way it exists in the PR, we add all the classes from If instead we just included all the classes from It's worth noting that this adds some kind of confusing noise to the generated config file because of the way traitlets works. |
f4c2d33 to
eb8b274
Compare
|
Rebased to get the windows timeout fix |
Would this pull in all the classes from [genuine question - I don't know nearly enough about traitlets, configuration, etc to know...] |
| ex = getattr(exchange, ex_name) | ||
| if hasattr(ex, "class_traits") and ex.class_traits(config=True): | ||
| classes.append(ex) | ||
| _collect_configurables(exchange.default) |
There was a problem hiding this comment.
| _collect_configurables(exchange.default) | |
| _collect_configurables(exchange.default.exchange) |
Do you think we need to catch all the default classes traits if they are similar to the abc ones ?
Since exchange is the only default class with dedicated traits, maybe it can be specified when calling the _collect_configurables function.
This should avoid duplication for most of the exchange classes, but I'm not sure it will not break anything about the functionalities, I don't know well traitlets.
There was a problem hiding this comment.
After digging into this more, I think the duplication is just the nature of the beast. I have a new proposal to make the distinction more clear, which is to actually rename the abc classes.
When they're used in the nbgrader codebase, we already do from exchange.abc import Exchange as ABCExchange, and if you search GitHub, so does everyone else: https://github.com/search?q=from+nbgrader.exchange+import+&type=code
By renaming the actual class, we can get rid of these import aliases without touching the implementation, and create distinction in the generated config file.
No, traitlets only traverses up the inheritance chain, and a custom exchange would be down it. We could instead ask the exchange factory for the configured classes, but this method is used for the task of generating a config file, so it's kind of a chicken and egg situation. |
|
As mentioned in my reply, I want to rename the classes in Traitlets doesn't offer any way to configure the way this config is generated, so the duplication is inescapable for now. The best thing to do IMO is lean into it and make the different classes distinguishable. |
In
nbgrader.apps.baseapp.NbGrader.all_configurable_classes, there was a subtle problem in the way it was deciding whether to include classes fromexchange.defaultwhich meant that none were ever included.The same work to do this check was being done 5 different times in unique blocks of code, one of which being incorrectly implemented. To avoid this type of mistake in the future, I added an inline function to do that check so it's done in a uniform way every time.
Fixes #1724