Remove Magical Import System

[mitsuhiko]

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]

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

[davidism]

@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]

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]

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]

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]

1.0 releases shouldbe about stabilization and not breaking the world though. We can set a time window when 2.0 happens and then people can prepare for it.

…

On Sun, Mar 31, 2019 at 4:49 PM David Lord ***@***.***> wrote: 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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAc5NItgqyvYHE-Q42JMSB50Cq5mg6hks5vcMregaJpZM4Ca0YL> .