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

Deprecate debug parameter from app.make_hander() #1121

Closed
asvetlov opened this issue Aug 25, 2016 · 4 comments
Closed

Deprecate debug parameter from app.make_hander() #1121

asvetlov opened this issue Aug 25, 2016 · 4 comments
Labels
Milestone

Comments

@asvetlov
Copy link
Member

Use app.debug as a value.
If app.debug conflicts with explicitly passes debug param -- raise ValueError.

The change is backward incompatible a little but it worth to be applied.

@asvetlov asvetlov added the good first issue Good for newcomers label Aug 25, 2016
@asvetlov asvetlov added this to the 1.0 milestone Aug 25, 2016
@f0t0n
Copy link
Contributor

f0t0n commented Aug 26, 2016

And what about the same story for loop parameter?
Currently we pass application's loop to the RequestHandlerFactory's constructor:

self._handler_factory(self, self.router, debug=self.debug, loop=self.loop, **kwargs)

But user reads in the documentation:

    kwargs –
            additional parameters for RequestHandlerFactory
            constructor.

So user could decide to pass a loop within kwargs that will cause a TypeError: got multiple values for keyword arg....

So my idea is, if we always pass application's loop as a parameter to the RequestHandlerFactory's constructor we should not allow user to do pass own loop as we did with debug.

Makes sense?

But the code of the make_handler will become ugly with all those checks for different parameters... :/

@asvetlov
Copy link
Member Author

TypeError: got multiple values is clean and obvious to me.
Let's keep it as is.

@asvetlov
Copy link
Member Author

Fixed by #1123

@lock
Copy link

lock bot commented Oct 29, 2019

This thread has been automatically locked since there has not been
any recent activity after it was closed. Please open a new issue for
related bugs.

If you feel like there's important points made in this discussion,
please include those exceprts into that new issue.

@lock lock bot added the outdated label Oct 29, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 29, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants