Pyramid 2.0 possible feature list

[mmerickel]

I'm starting here a little 2.0 wishlist. I have no idea if an issue will be a good medium for the discussion but here goes. None of these are guaranteed to make the cut. There is no timeline for this yet. Personally I'm interested in MINOR incompatibilities that are large enough that we have refused to do until now (i.e. nothing that will require a fundamental redesign of a Pyramid app for a user).

Please keep the discussion away from here and in separate issues. Let's focus on simply compiling a list of possibilities.

likely

• Drop Python 2 support. Drop support for Python 2 #2903
• Switch the ISession contract from pickleable objects to something more secure and portable like json. 2.0 feature request: Require that sessions are JSON serializable #2709
• Remove check_csrf view predicate in favor of require_csrf (already deprecated).
• Remove custom_predicates from config.add_view and view_config (already deprecated).
• Remove config.set_request_property (already deprecated).
• Remove pcreate and default scaffolds. deprecate pcreate and update scaffolds to cookiecutter #2384

interesting, let's open an issue and talk about it

• Separate CSRF tokens from the ISession into something else implementable without a session. Improve CSRF Support for Safety, REST, and Decoupling #1573
• Something to do with route prefixes so that it's possible to use config.include without the base url inside having a / suffix. route_prefix doesn't allow the prefix pattern to match without a trailing slash #406, Added support for a prefixed base url that does not contain a trailing slash #1639
• Drop PasteDeploy in favor of a better loading system. improve config file support #2419
• Fix predicate factories to accept a standardized info object instead of config. Currently the only purpose of this argument is for config.maybe_dotted but it's poor practice to pass the ephemeral config object around. define a new IPredicateInfo to mirror IDeriverInfo #2535
• Drop the use_tweens argument to request.invoke_subrequest in order to make the nested request pipeline more sane. add first class transaction manager support #2606

interesting but unlikely without a champion to start the discussion

• Deprecate remember/forget APIs in favor of a pattern that fits better with non-cookie workflows.
• Something to do with identity and auth-api post mortem?
• Add a public API at the top-level pyramid namespace. For example pyramid.view_config, pyramid.Configurator, etc. This would greatly assist in maintainability of the public API for people using IDEs like pycharm where they may not be checking the docs to ensure an API is public. Probably use a lazy-instantiator like apipkg for this. add a top-level public api #2387
• Re-work view_config to namespace arguments to be more clear about options versus predicates.
• Re-work config.add_view, config.add_forbidden_view, config.add_notfound_view to accept only kwargs. Almost all of the parameters are indistinguishable from user-defined view options, so they could be treated all the same.
• Separate NotFound and Forbidden exceptions from HTTPNotFound and HTTPForbidden. This would undo previous work to merge them in order to make exception views more understandable.

other proposals

• Restrict the request methods on add_view by default to GET and POST. Pyramid 2.0 could restrict the request methods by default in add_view, view_config. #2796

[digitalresistor]

I'd like to see the CSRF token stuff separated from the session, and become it's own stand-alone thing.

[mmerickel]

Sure! I think it'd be helpful to open a different issue and link to it from your idea where we can talk about that particular API if you'd like.

[digitalresistor]

Re-work @view_config and friends to possibly be multiple stacked decorators instead of sharing a single namespace so that it is easier to see what is a predicate versus what is used by the view machinery, or even view derivations.

[jvanasco]

I'd like to be be able to access the currently expected "renderer" (and various other @view_config or add_view arguments) for the current request within the view's code. Currently, the only accessible data point within the view is the request.matched_route.name; and the template can get the current renderer... but that's all that I know of.

[mmerickel]

@jvanasco These features are not a breaking change thus not on the roadmap for pyramid 2.0. In fact everything you requested will be available in 1.7 with the new view derivers feature.

[jvanasco]

well that's pretty wonderful!

[ztane]

I am currently testing how the auth-api postmortem works. However so far I've concluded that permits and authorized_userid perhaps shouldn't be in the same interface, but all in all, I'd really wish to see this change. Additionally, all the authz methods should have the request passed in.

[jvanasco]

Have the ISession stop requiring an explicit call to 'changed()' for mutable objects by automatically detecting changes. [http://docs.pylonsproject.org/projects/pyramid/en/latest/api/interfaces.html#pyramid.interfaces.ISession.changed]

I did not realize Pyramid required this (or perhaps I forgot) and had some session manipulations that did not persist. This was awkward, as most other session systems do not require this.

I handled this in our fork of a session library by hashing the serialized version of a session on creation, and comparing that to a second fingerprint on cleanup [if the session did not otherwise have a reason to persist].

This sort of change would likely not break any apps, but it could likely break session libraries.

[mmerickel]

Have the ISession stop requiring an explicit call to 'changed()' for mutable objects by automatically detecting changes.

What? This is up to the session whether this is required. Under normal scenarios it is only required if you perform a deep change on a mutable collection stored in the session, for obvious reasons.

The bundled session impl from pyramid does not require you to ever call changed unless you do what I described.

request.session['foo']['bar']['baz'] = 1
request.session.changed()
# versus
obj = copy.deepcopy(request.session['foo'])
obj['foo']['bar']['baz'] = 1
request.session['foo'] = obj

[mmerickel]

@jvanasco please open a specific issue instead of trying to talk about these things in the 2.0 feature list. It's really supposed to just be an aggregate of these various issues with their own discussion elsewhere.

[ergo]

I would love to see an asyncio support/integration out of the box if pyramid would be 3.5+ only - that would be a killer feature in my opinion.

[digitalresistor]

What does asyncio support/integration mean within the Pyramid framework? What integration are you looking for Pyramid to provide?

[ergo]

I was thinking about core integration or package maintenance of something that would make sense that build on top of these projects where it makes sense:

https://pypi.python.org/pypi/aiopyramid
https://github.com/mardiros/pyramid_asyncio
https://github.com/etianen/aiohttp-wsgi

So far my personal experience includes using pyramid + gevent (which doesn't require anything special on pyramids end), but asyncio seems to be the next logical step here.

[ergo]

Another feature, incorporate @wichert s https://github.com/wichert/pyramid_authstack - its 40 something lines of code but i strongly believe this should be part of standard API.

[rach]

Allow to configure pserve (and others commands) via some hooks to make config_uri ( passing a file) not required. I think that's a frustration that will help some people to adopt pyramid. I know #2419 Try to improve the flexibility of this but it's really something that I would like to see improved in 2.0

[nek4life]

One point of confusion I've had is the permission argument on view_config and the fact that it only accepts one permission. Suppose I have editor and moderator groups right now I think the solve for not adding more than one permission is to make a new group called editormoderator and use that instead. It seemed really counter intuitive to me to do so. Perhaps there is a good reason for this that I'm unaware of, but I wanted to bring it up for 2.0 if there is a chance to revisit this.

[digitalresistor]

@nek4life The permission should be "edit", and then on your context you have an acl that grants both the group:moderator and group:editor the permission edit.

For example:

class MyContext(object):
    __acl__ = [
        (Allow, 'group:moderators', 'edit'),
        (Allow, 'group:editors', 'edit'),
        (Allow, 'group:administrators', 'edit'),
    ]

Then your view_config would be:

@view_config(context=MyContext, permission='edit')
def myview(context, request):
    pass

And now anyone that has in their list of principals one of the following:

• group:moderators
• group:administrators
• group:editors

Will have the edit permission.

[vanguard737]

Late to the party here...The above link to the auth-api post-mortem has gone dead. (Which is a shame, since I've seen the same doc linked in a few SO responses.) Is this document available anyplace else?

[merwok]

Here http://web.archive.org/web/20170201093432/plope.com/pyramid_auth_design_api_postmortem

[ztane]

I've said it elsewhere, the auth postmortem would make things much better, but the authz policy should really get a reference to the request too - now people write their own wrapper classes to contain the actual context classes just to pass the request implicitly into the authorization policy.

[robinharms]

Hi all,
On that same note, auth does some funky stuff when checking roles ("groupfinder") during traversal in another tree.

Kotti solved this nicely:
https://github.com/Kotti/Kotti/blob/master/kotti/security.py

tl;dr: Consider a request in this structure:

/users/me
/users/someone_else

If I'm at 'me', request.context will be me.
If i check permission on something and i use request.has_permission('Edit', SomeOneElseObj) effective_principals will fetch principals from request.context and probably grant me something that isn't right :/

Passing along context to effective_principals might do the trick too?
What are your thoughts on this?

[mmerickel]

@robinharms Please open a separate issue if you wish to discuss this. The intricacies of a particular issue don't belong in this roadmap thread. I will mention that the principals do not come from the context at all - only the request - and so something smells a little bit about your analysis so far.

[robinharms]

@mmerickel OK I'll do that. Regarding principals, that's exactly the problem :)

[stevepiercy]

Two items for documentation consideration:

• Support poetry, flit, pipenv (whatever) in our documentation Support poetry, flit, pipenv, or ...? #3270
• Keep install and setup instructions for Unix and Windows, but remove Windows commands from all other places in the documentation, per Tutorial instructions for windows may not work correctly in Powershell #3260 (comment)

[mcdonc]

I'd be willing to make a call on what to do about #2607 (make append_slash_notfound_view use a subrequest) and to do the work that falls out for 2.0.

[stevepiercy]

A couple more to the list above:

• Add Python 3.7 support Support Python 3.7 #3312
• Add Python 3.8 if released, at least in Travis/Appveyor

[ergo]

I was thinking that first class out-of-the-box mixing sync and async requests from separate thread would be a killer feature for pyramid 2.x.

[wichert]

async view functions certainly would be really useful.

[digitalresistor]

Gonna link to this discussion: #3391 on why async support in Pyramid is a lot more fraught with issues than anyone is willing to admit at the moment.

[kpinc]

How about dropping the "path", alternate name for "pattern", argument from Configurator.add_route()?

Let me know if you want an issue opened.

So long as I'm commenting, here is a list of what I can find that's depreciated, or could be.
This is pretty much from grepping for "backward" and "b/w".

All the .ini file keys which have 2 names. The names that don't begin with
"pyramid." could be dropped. (Really, the addition of the "pyramid." prefix
is a kludge which works-around the lamity of .ini files. It might be nice to
retain the prefixless config keys for use in alternate config file formats
which allow more in the way of nesting. Can't say whether this makes
sense.)

PYRAMID_RELOAD_RESOURCES (envvar) and pyramid.reload_resources (config file)
(replaced by  PYRAMID_RELOAD_ASSETS, pyramid.reload_assets)

URLMethodsMixin.model_url() is replaced by request.resource_url()
URLMethodsMixin.route_url() is replaced by request.route_url()
URLMethodsMixin.route_path() is replaced by request.route_path()
URLMethodsMixiin.resource_url() is replaced by request.resource_url()
URLMethodsMixiin.static_url() is replaced by request.static_url()
URLMethodsMixiin.static_path() is replaced by request.static_path()
URLMethodsMixiin.current_route_url() is replaced by request.current_route_url()
URLMethodsMixiin.current_route_path() is replaced by request.current_route_path()

pyramid.interfaces.IAfterTraversal replaced by pyramid.interfaces.IContextFound
pyramid.interfaces.IWSGIApplicationCreatedEvent replaced by IApplicationCreated

pyramid.events.AfterTraversal replaced by ContextFound
pyramid.events.WSGIApplicationCreatedEvent replaced by ApplicationCreated

pyramid.view.bfg_view replaced by pyramid.view.view_config

All of src/pyramid/resource.py
from pyramid.asset import *  # noqa b/w compat
resolve_resource_spec = resolve_asset_spec  # noqa
resource_spec_from_abspath = asset_spec_from_abspath  # noqa
abspath_from_resource_spec = abspath_from_asset_spec  # noqa

TestingConfiguratorMixin.testing_models replaced by testing_resources

Router.root_policy replaced by root_factory

traversal.find_model() replaced by find_resource()

Configurator.absolute_resource_spec replaced by absolute_asset_spec
    (But the comment says to keep this forever)

pyramid.testing.DummyModel replaced by DummyResource

ViewsConfiguratorMixin.request_type appears obsolete but
I don't know what replaces it.  Likewise the custom_predicates.
I suspect these are mentioned above.

ViewsConfiguratorMixin._derive_view() replaced by derive_view()

Something with DummyTemplateRenderer.__getattr()

There is something backwards compatibility related involving
registery.getutility(ISettings)

Also something backwards compatibility related in
httpexceptions.default_exceptionresponse_view()

Something might be going on in authentication.calculate_digest()

There are notes in config/adapters.py indicating that there's
backwards compatibility stuff that probably would cause too much
breakage to change.

[mmerickel]

Things are pretty close to finalized for Pyramid 2.0 - I'll point people at the changelog/whatsnew documents for what made the cut. There's actually no major backward incompatibilities. We'll be doing a 1.10.5 release that adds at least one or two deprecations to help people upgrade in important spots.