Drop kwargs from Application ctor

[asvetlov]

I propose to just remove **kwargs from Application.__init__ signature.

The problem is: we are likely want to add new parameters to the constructor in future.

But they are will clash with params used by customers, sure (we both will use simple and short parameter names).

To avoid the problem I would like to just forbid the case.

Application is not a dict in our philosophy, it's just a MutableMapping.

If you need to store extra data in the app please do it explicitly:

app = Application()
app['key'] = data

[fafhrd91]

ok

[asvetlov]

Please pay attention: we have used wrong code even in own tests without any error reports.

[ludovic-gasc]

OK for me.

BTW, do you see an issue to use app.ah_container instead of app['ah_container'] ?

[asvetlov]

@GMLudo sorry, no. Please provide a link

[asvetlov]

@GMLudo if you are talking about hypothetical problem on processing Application keys as attributes also via __getattr__ -- this will never happen in aiohttp and I strongly do not recommend the way in any aiohttp derived libraries.

[ludovic-gasc]

@asvetlov: Don't worry about that, I also dislike to have values accessible via attributes, because you can't use some characters like - where with a dict, it's freedom.
No, with my example, I'm talking about this.
I use app.ah_container to keep a reference of Container in aiohttp.web Application.
Do you recommend to use app['ah_container'] instead of app.ah_container, or it's the same ?

[asvetlov]

@GMLudo Yes, sure.
If you make your own app class by inheriting from web.Application -- you are free to add new attributes (but I recommend to make it semi-private by using _attr notation starting from underscore.

But Application is not intended to be subclassed, BTW -- in other languages it should be implemented as final but Python has no the Java final or C# sealed equivalent.

On asyncio development Guido van Rossum pronounced the inheritance rule for libraries:

1. We should split all library classes to intended to be subclassed and others.
2. The first ones should have no attributes: they are pure interfaces like asyncio.Protocol.
3. The seconds may be inherited internally by the library but end user should never have a need to subclass those ones.

I've found the design the very useful and very important.

You can find a lot of libs which breaks the rule of thumb but please don't add your own into the list without the strict reason.

On development of your application (not a generic library) you are free -- use the inheritance without any restrictions: your code will show the way to keep it simple.

[ludovic-gasc]

Ok, thanks a lot about tips, especially about Guido tip.
If you have a link where he discuss about this architecture design, I'm interested in.

[asvetlov]

Sorry, I cannot recall the topic (not talking about the exact email
message).

asyncio was discussed in python-dev, python-ideas and tulip, you can dig
into.

Personally I've heard the rule from Guido when we worked on tulip together
at US PyCon 2013 sprints.

BTW he called Nikolay Kim "the crazy Russian" -- at winter 2013 tulip has
only two active developers -- Guido itself and Kim.

On Thu, Jan 15, 2015 at 12:42 AM, Ludovic Gasc [email protected]
wrote:

Ok, thanks a lot about tips, especially about Guido tip.
If you have a link where he discuss about this architecture design, I'm
interested in.

—
Reply to this email directly or view it on GitHub
#243 (comment).

Thanks,
Andrew Svetlov

[lock]

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.