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

Remove Magical Import System #2

Closed
mitsuhiko opened this issue Oct 18, 2010 · 7 comments · Fixed by #1640 or #1644

Comments

@mitsuhiko
Copy link
Member

commented Oct 18, 2010

Currently Werkzeug provides a magical import system which causes some troubles on GAE and other python implementations. This really shouldn't be necessary.

This can't be done for 0.7 but we can certainly aim for that for 1.0

untitaker pushed a commit to untitaker/werkzeug that referenced this issue Mar 10, 2013
depassp referenced this issue in depassp/werkzeug Apr 14, 2013
untitaker pushed a commit to untitaker/werkzeug that referenced this issue May 25, 2013
@untitaker untitaker added this to the 1.0 milestone Aug 24, 2014
@untitaker untitaker added discussion/long-term and removed 1.0 labels Aug 24, 2014
@untitaker

This comment has been minimized.

Copy link
Member

commented Aug 25, 2014

I think we still could autogenerate __all__ from globals(). The repetition is otherwise just too heavy IMO.

@davidism

This comment has been minimized.

Copy link
Member

commented Mar 29, 2019

@mitsuhiko this issue only mentions removing the magic, and I'm assuming leaving the top-level imports. However, the docs have said for quite some time that the top-level imports will be removed completely and users should use specific imports: http://werkzeug.palletsprojects.com/en/0.15.x/transition/#automatically-rewriting-imports

I think using specific imports is preferable, and would like to phase out the top-level, but this has been open for 8.5 years now. Any opinion on what should happen? Basically, do we just remove the magic, or do we also remove the top-level imports?

@davidism

This comment has been minimized.

Copy link
Member

commented Mar 29, 2019

With the current magic, PyCharm (and possibly other IDEs) has no idea what's going on and so it always uses specific imports. Removing the magic will make it more likely that users will import from the top-level because it will become more discoverable.

The top-level imports are somewhat haphazard as well. Perhaps a compromise would be a reduced set of just the common entry points into Werkzeug (Request, Response, Client, run_simple, etc.)

@mitsuhiko

This comment has been minimized.

Copy link
Member Author

commented Mar 30, 2019

I somehow feel like changing this now will be super frustrating to users. I think at least we should not remove it with 1.0 but we could deprecate them with 1.0 (with a warning) and then remove them with 2.0.

@davidism

This comment has been minimized.

Copy link
Member

commented Mar 31, 2019

The only problem with putting off removal until 2.0 is that there's no definite time when that happens. The deprecation warning would be around for a long time. We had this issue with Flask-SQLAlchemy, where a deprecation warning has been bugging people for years, although admittedly I handled that less well by making it visible by default instead of only during tests.

@mitsuhiko

This comment has been minimized.

Copy link
Member Author

commented Mar 31, 2019

@aenglander

This comment has been minimized.

Copy link
Contributor

commented May 6, 2019

I think it would be reasonable to warn about deprecation in 0.x and deprecate in 1.0 as long as it's done well and an upgrade guide for 0.x to 1.0 is provided.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.