Code

Opened 3 years ago

Closed 13 months ago

#16675 closed Cleanup/optimization (duplicate)

Refactor the class/function loading code to use common API

Reported by: jezdez Owned by: nobody
Component: Core (Other) Version: 1.3
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

There are countless code snippets in Django that load a particular callback or backend and each handle the possible exceptions differently.

I think for the most of those examples we can use a common API which would lower the chance of breakage as well be useful to users.

Jonas Obrist implemented this kind of thing in his django-load app (http://readthedocs.org/docs/django-load/en/latest/).

Attachments (1)

importutils.diff (5.8 KB) - added by jezdez 3 years ago.
diff from https://github.com/jezdez/django/compare/feature/importutils

Download all attachments as: .zip

Change History (5)

comment:1 Changed 3 years ago by jezdez

I've updated Jonas' code slightly and added it to the django.utils.importlib module.

https://github.com/jezdez/django/compare/feature/importutils

If accepted, this would require more work on the actual code parts where imports are done.

comment:2 Changed 3 years ago by russellm

  • Component changed from Uncategorized to Core (Other)
  • Triage Stage changed from Unreviewed to Accepted

I'll accept this in principle -- the "load a backend" pattern is something that we've reimplemented far too many times. If we can pull this back to a common API without losing all the edge cases, it seems like a no-brainer to me.

From a first inspection, this snippet from Jonas looks like a good approach to me -- I'd just need to see it in use for a couple of actual use cases to be 100% convinced.

comment:3 Changed 13 months ago by aaugustin

Wasn't this fixed by 7c5b2448?

I'm not sure I understand correctly the scope of this ticket.

comment:4 Changed 13 months ago by claudep

  • Resolution set to duplicate
  • Status changed from new to closed

I wasn't aware of this ticket when I committed [7c5b2448] (#17061). If the possibility to customize the raised exception is needed somewhere in Django, we can always add it at a later stage.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.