deprecate view arguments in add_route

[mmerickel]

Pretty please? The idea was nice but I think has 2 problems:

• It hurts newcomers who need to learn that routes are not views, hiding the fact that you may have multiple views per route, where if the option wasn't there they would be forced to use add_view or @view_config.
• People who understand the separation are very unlikely to use it, as they're probably creating multiple views per route using either @view_config or add_view.

Pyramid could deprecate the usage of those arguments, possibly by removing them from the documentation (or putting a nice big warning in the docs) and issuing a warning when they are used.

[bbangert]

I'll admit that I'm actually somewhat in favor of this, as I've seen people add a dozen add_route statements with the same route_name and url segment, and they're using it to actually add additional views with different predicates for the same route.

While at first I thought maybe just the documentation should show add_route followed by an add_view, it then seems odd to explain, "and now to confuse you, lets mix one of the views for this route into the add_route statement, but keep all the additional views for this route in separate statements....".

Such docs has me agreeing more with you on documenting them separately to help emphasize that adding a view for a route_name with some predicates (or not) is separate from setting up the routes. The current method of using add_route to add the route and view clearly has people believing there's a closer binding between the route+view than actually exists thus the repeat add_route calls with the same name+path but different view args.

[mcdonc]

raydeo's fork was merged into master via 1612fe7