Proposal: Use decorator instead of get_classes to mark classes extensible

While struggling with the pain that is get_classes statements spanning across multiple lines, I wished for a cleaner way to handle Oscar’s dynamic class loading

Proposal

Introduce a class decorator that mimics get_class. If a customised version of the decorated class exists, return that one instead of the decorated class.

# catalogue/forms.py
from oscar.core.loading import extensible

class ProductForm(forms.Form):
    ...

@extensible
class ExtensibleProductForm(ProductForm):
    pass

# catalogue/views.py

from .forms import ExtensibleProductForm

Pro & Con

Pro:

• more readable import statements
• IDE support for importing, and detecting unused or wrong imports
• avoids accidentally using a direct import, class will always be extensible
• a lot DRYer than the current solution

Cons:

• It’s not really “decorating”, it’s a straight-out monkey patch.
• Makes class names longer

One could also just decorate all extensible classes, but then it’s not immediately obvious from other code if the used class is extensible or not. And it makes it harder to access the core Oscar class.

[craigloftus]

I agree that the current approach is more explicit and therefore better than the proposal.

If it were to change I’d rather it went the other way and became more explicit, i.e., as well as using get_class, using a registry pattern rather than using magic paths.

[solarissmoke]

Closing this on the basis that the consensus seems to be to make overriding more explicit, not less. I think the solution will be related to #2544.