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

Defer sqlalchemy import #1070

Open
adamchainz opened this issue Mar 29, 2024 · 1 comment · May be fixed by #1071
Open

Defer sqlalchemy import #1070

adamchainz opened this issue Mar 29, 2024 · 1 comment · May be fixed by #1071

Comments

@adamchainz
Copy link

The problem

factory_boy/__init__.py uses this pattern for its optional sub-packages:

try:
    from . import alchemy
except ImportError:
    pass

I have a Django project that uses factory_boy a lot, and imports it even in view code. It also happens that the project has sqlalchemy installed for another tool, but it doesn’t use it directly.

On a importtime-waterfall profile, I noticed that importing factory_boy.alchemy takes ~300ms, nearly all in sqlalchemy and its submodules.

It would be great if importing factory_boy didn’t automatically import sqlalchemy.

Proposed solution

Defer the few sqlalchemy imports in factory.alchemy to the functions that use them. Drop the except ImportError pattern in factory_boy since it should then work regardless of whether sqlalchemy is installed.

Extra notes

None.

@adamchainz adamchainz changed the title Defer imports of optional submodules Defer sqlalchemy import Mar 29, 2024
@adamchainz adamchainz linked a pull request Mar 29, 2024 that will close this issue
@rbarrois
Copy link
Member

rbarrois commented Apr 9, 2024

I do agree that import factory should not have imported factory.django or factory.alchemy dynamically.
Unfortunately, I'm afraid this ship has sailed :/

Changing this is bound to break lots of existing code — a quick, non refined Github code search yields about 11k files:
https://github.com/search?q=%2F%5Eimport+factory%24%2F+%2F%5C%28factory%5C.django%2F+language%3APython&type=code

Any change on that topic would have to be non-breaking to the thousands of users of the existing, documented import style.
I do not wish to provoke large amount of code churn for users of the library unless that brings some improvements to them.

Before working on pull requests, I'd like to have a high-level agreement on an approach that wouldn't break the code for lots of people.

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

Successfully merging a pull request may close this issue.

2 participants