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

Support Django coding style conventions #77

Open
pawelad opened this issue Feb 8, 2023 · 2 comments
Open

Support Django coding style conventions #77

pawelad opened this issue Feb 8, 2023 · 2 comments

Comments

@pawelad
Copy link

pawelad commented Feb 8, 2023

Hi!

I really like the idea behind this library and think it could complement black, isort (and ruff) really well : )

Unfortunately, I can't use it on any Django projects because the enforced order is not compatible with Django's coding style:

The order of model inner classes and standard methods should be as follows (noting that these are not all required):

  • All database fields
  • Custom manager attributes
  • class Meta
  • def str()
  • def save()
  • def get_absolute_url()
  • Any custom methods

Would you be open to supporting it, either automatically (for example when django usage is found and inheritance from models.Model is detected) or possibly via some kind of --profile argument (similarly to how isort supports black profile)?

@bwhmather
Copy link
Owner

bwhmather commented Feb 10, 2023

Hi Pawel! - Thank you for linking this. My reading is that there are three points of incompatibility:

  1. ssort moves class Meta above database field definitions and custom manager attributes.
  2. ssort splits d'under methods into lifecycle and other, whereas django lumps them all into "Any custom methods".
  3. ssort does not enforce the order of str, save, or get_absolute_url.

(Am I missing anything else?)

I think that we are unlikely to change 2 and 3. I'm quite happy with the current d'under sorting, and hard-coding non-special method names is likely to lead to confusion.

Changing 1 would be a significant break in compatibility, but I agree that putting classes under attributes does look better and it would be consistent with both the django and pydantic docs. I might consider it for the 1.0 release.

@pawelad
Copy link
Author

pawelad commented Mar 28, 2023

Sorry for the late reply!

I think you summed up the problem really well and I agree with all your points.

Would you be open to implementing the "nested classes after attributes" and maybe hiding it behind a feature flag? You could then decide if you want that to be the default from v1 or it it would stay configurable.

Let me know if I can help in any way.

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

No branches or pull requests

2 participants