#34778 closed Cleanup/optimization (fixed)

startproject could use find_spec() rather than import_module() to check for conflicts

Reported by: Jacob Walls Owned by: Jacob Walls
Component: Core (Management commands) Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


The startproject command currently depends on calling importlib.import_module() on the intended new project name, which will execute a python module if it happens to find one.

It would be more performant and less intrusive to check the return value of importlib.util.find_spec (docs), which avoids importing anything (so long as the path doesn't include a dot, but that can be checked for first.)

Happy to submit a PR if welcome.

Change History (10)

comment:1 by Natalia Bidart, 11 months ago

Resolution: needsinfo
Status: newclosed

Hello Jacob, thank you for your ticket.

As a general rule, in order to decide about changes that would impact performance, the usual advice is to provide, next to the change, some evidence that the change will actually improve the performance. To do so, one option is to use https://github.com/django/djangobench.

For this specific suggestion, and considering that startproject is used once per project setup, I find it hard to justify to change the code on a script that a django user may run 10? 50? 100? times in their career (I personally have run startproject less than 50 times since 2005). Do you have a use case where the performance of startproject is causing issues?

Cheers, Natalia.

comment:2 by Jacob Walls, 11 months ago

Hi Natalia, thanks for the response.

I shouldn't have used the word peformant (sorry!) as performance was not the real motivation. The motivation was that it's simply less invasive to avoid executing unnecessary modules. If you develop a project called presto and decide to create a project presto-helper without the knowledge that there's someone else's presto-helper already installed in your environment, presto-helper will get executed, which could possibly dump things to the terminal or execute queries (hopefully it wouldn't). It just seems nicer to avoid that if there's a simple workaround.

I understand this is a judgment call since users are responsible for what's installed in their environment, and if they install things that have noisy import-time statements, that's not on Django.

comment:3 by Jacob Walls, 11 months ago

Resolution: needsinfo
Status: closednew

comment:4 by Natalia Bidart, 11 months ago

Resolution: wontfix
Status: newclosed

Right, I agree with your final sentence, in that Django can't account or solve all corner cases. It provides solutions for the general and (common?) case, and then for these situations, we usually prefer to keep the code simple and straightforward.

Having said that, and after reading the docs, it might be a decent idea to switch, though I fear I may be missing potential side effects of this change. Would you consider posting to the Django Internals forum category so more people can chime in? If no one objects in a week or two, we could accept the ticket.

I'll close as wontfix for now to clean up the pending triage queue, but do ping back in a couple of weeks so we revisit this proposal.


comment:5 by Jacob Walls, 11 months ago

Resolution: wontfix
Status: closednew

Suggesting another look after forum discussion.

comment:6 by Jacob Walls, 11 months ago

Owner: changed from nobody to Jacob Walls
Status: newassigned

comment:7 by Jacob Walls, 11 months ago

Has patch: set

comment:8 by Mariusz Felisiak, 11 months ago

Triage Stage: UnreviewedAccepted

Tentatively accepted.

comment:9 by Mariusz Felisiak, 11 months ago

Triage Stage: AcceptedReady for checkin

comment:10 by Mariusz Felisiak <felisiak.mariusz@…>, 11 months ago

Resolution: fixed
Status: assignedclosed

In bcd80de:

Fixed #34778 -- Avoided importing modules in startapp/startproject.

Note: See TracTickets for help on using tickets.
Back to Top