Pyramid 1.2a1 released

[Chris McDonough]

Pyramid 1.2a1 has been released. This is the first alpha release in
the 1.2 series.

A "What's New In Pyramid 1.2" document exists at
http://docs.pylonsproject.org/projects/pyramid/1.2/whatsnew-1.2.html
describing the differences between 1.1 and 1.2.

You will be able to see the 1.2 release documentation (across all
alphas and betas, as well as when it eventually gets to final release)
at http://docs.pylonsproject.org/projects/pyramid/1.2/ .

You can install it via PyPI:

easy_install Pyramid==1.2a1

Enjoy, and please report any issues you find to the issue tracker at
https://github.com/Pylons/pyramid/issues

Particular thanks to Michael Merickel for this release; much of the
code and design in 1.2 is his. Also thanks to Blaise Laflamme, and
Casey Duncan for their work on the new pyramid_debugtoolbar feature.

Thanks!

- C

[Robert Forkel]

just a quick feedback: i upgraded my app from 1.1.2 to 1.2a1 and now
am getting ConfigurationConflictError s for the following statements:
config.add_renderer(".mako", "pyramid.mako_templating.renderer_factory")
config.add_renderer("json", "msp.renderers.json_renderer_factory")

I didn't see anything seemingly relevant mentioned in the what's new doc.
regards,
robert

> --
> You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
> To post to this group, send email to pylons-...@googlegroups.com.
> To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
>
>

[Chris McDonough]

On Wed, 2011-08-24 at 09:52 +0200, Robert Forkel wrote:
> just a quick feedback: i upgraded my app from 1.1.2 to 1.2a1 and now
> am getting ConfigurationConflictError s for the following statements:
> config.add_renderer(".mako", "pyramid.mako_templating.renderer_factory")
> config.add_renderer("json", "msp.renderers.json_renderer_factory")
>
> I didn't see anything seemingly relevant mentioned in the what's new doc.
> regards,
> robert

Thanks for the report.

If you add a "config.commit()" before you execute those add_renderer
statements, it will work again.

I was trying to treat all default arguments to the Configurator as if
the equivalent action was done imperatively (e.g. passing
authentication_policy to the Configurator constructor is equivalent to
calling the new config.set_authentication_policy method). What's
happening is that the default renderers are getting registered as if you
called "add_renderer" with those too in the same configuration session.
It's as if you'd done:

config.add_renderer('.mako', 'pyramid.mako_templating.renderer_factory')

config.add_renderer('json', 'pyramid.renderers.json_renderer_factory')

config.add_renderer('.mako', 'pyramid.mako_templating.renderer_factory')
config.add_renderer('json', 'msp.renderers.json_renderer_factory')

And this will cause a conflict, because the same renderer factory name
is registered for two different renderer factories.

This is not desirable. I will revert back to the old behavior of
autocommitting the default renderers in 1.2a2. The workaround of
committing before any other actions is forward compatible, so you can
just do that in the meantime.

- C

[Robert Forkel]

another thing i just realized: I use config.get_routes_mapper() (to
pass information about routes to my javascript). With 1.2a1 this
requires a config.commit() before the call, otherwise an empty mapping
dict will be returned.

[Chris McDonough]

On Wed, 2011-08-24 at 10:42 +0200, Robert Forkel wrote:
> another thing i just realized: I use config.get_routes_mapper() (to
> pass information about routes to my javascript). With 1.2a1 this
> requires a config.commit() before the call, otherwise an empty mapping
> dict will be returned.

config.get_routes_mapper() will return a routes mapper unconditionally,
but yes, routes wont actually be added to the route mapper until a
commit. This is intentional and will not change in the next release.
I'll add a note to the changes about it.

- C

[Graham Higgins]

Particular thanks to Michael Merickel for this release; much of the
code and design in 1.2 is his.

Hats off to MM for the solid contrib. I've been following progress on the #pyramid

irc log (my TZ=GMT so I'm generally obliged to follow the discussions using the irclog)

... and my attention was drawn to a remark that Michael recently made on #pyramid:

Q: Are using Handlers kinda frowned upon? Coming from Pylons and 

sorta at a fork-in-the-road of whether I should just abandon my old habits or not

raydeo:  they are fine.. you don't gain a lot by using them though, especially if 

             you don't care about dispatching to a view based on {action} patterns

raydeo:  and in 1.2 that will be solved more directly using just regular views

raydeo:  in general I would describe handlers as a crutch :-)

okay, I note the smiley but I'd also be interested in a more detailed explanation of 

the programming / software engineering rationale that underpins a view of handlers

as a crutch as this doesn't seem to be explored anywhere in the narrative docs.

Cheers,

Graham

[Michael Merickel]

It's funny you should ask. :-)

http://michael.merickel.org/2011/8/23/outgrowing-pyramid-handlers/

> --
> You received this message because you are subscribed to the Google Groups "pylons-discuss" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/pylons-discuss/-/hJvW4DMsP_AJ.

[Michael Merickel]

On Wed, Aug 24, 2011 at 12:42 PM, Michael Merickel <mic...@merickel.org> wrote:

It's funny you should ask. :-)

http://michael.merickel.org/2011/8/23/outgrowing-pyramid-handlers/

On Aug 24, 2011 6:24 AM, "Graham Higgins" <gjhi...@gmail.com> wrote:
> Q: Are using Handlers kinda frowned upon? Coming from Pylons and
> sorta at a fork-in-the-road of whether I should just abandon my old habits
> or not
>
> raydeo: they are fine.. you don't gain a lot by using them though,
> especially if
> you don't care about dispatching to a view based on {action}
> patterns
> raydeo: and in 1.2 that will be solved more directly using just regular
> views
> raydeo: in general I would describe handlers as a crutch :-)

To clarify on that point, I wasn't knocking the concept of controllers/handlers as much as I was talking about the usefulness of the pyramid_handlers package versus doing the class-based views directly in Pyramid.

--

Michael

[Mike Orr]

On Wed, Aug 24, 2011 at 4:24 AM, Graham Higgins <gjhi...@gmail.com> wrote:
> Q: Are using Handlers kinda frowned upon? Coming from Pylons and
> sorta at a fork-in-the-road of whether I should just abandon my old habits
> or not
> raydeo:  they are fine.. you don't gain a lot by using them though,
> especially if
>              you don't care about dispatching to a view based on {action}
> patterns

There are two things you lose with @view_config. One, routing details
are pushed into the view modules, while Handlers and Pylons try to
make a complete separation between the functionality of the actions
and which URL they're called by. Although in this new format, the
commonality is the route name rather than the URL pattern, so that
maintains some independence from the URL.

If you use 'match_param='action=logout'', that puts more routing
detail into the view method than I'm comfortable with at first glance,
but I guess it's essentially the same as having multiple @action's on
the same view method, with the advantage that the match variable is
called by its own proper name ('action') rather than 'name'.

The other disadvantage of @view_config is you have to use
Config.scan(), which, while it has been working fine in Pyramid 1,
still seems a bit magical to me.

I don't think I'll change Akhet since its purpose remains to be
Pylons-like, but I'll add "something" to the manual that suggests this
new structure should also be considered.

The debug toolbar sounds interesting; I'll have to check it out.

--
Mike Orr <slugg...@gmail.com>

[Sebastien Douche]

On Wed, Aug 24, 2011 at 06:55, Chris McDonough <chr...@plope.com> wrote:
> A "What's New In Pyramid 1.2" document exists at
> http://docs.pylonsproject.org/projects/pyramid/1.2/whatsnew-1.2.html
> describing the differences between 1.1 and 1.2.

Yeah \o/. Well I admit I skimmed over the doc but I don't fully
understand Tweens. Can you explain a bit more (with some real
examples)?

--
Sebastien Douche <sdo...@gmail.com>
Twitter : @sdouche

[Chris McDonough]

On Wed, 2011-08-24 at 22:07 +0200, Sebastien Douche wrote:
> On Wed, Aug 24, 2011 at 06:55, Chris McDonough <chr...@plope.com> wrote:
> > A "What's New In Pyramid 1.2" document exists at
> > http://docs.pylonsproject.org/projects/pyramid/1.2/whatsnew-1.2.html
> > describing the differences between 1.1 and 1.2.
>
> Yeah \o/. Well I admit I skimmed over the doc but I don't fully
> understand Tweens. Can you explain a bit more (with some real
> examples)?

If you know how WSGI middleware works (a functional composition that
accepts a request and returns a response), you know very generally how
tweens work. If you don't know how WSGI middleware works, though, you
might take a look at
http://docs.repoze.org/moonshining/pep333.html#middleware first.

The best real-world examples of tweens are in the code of the following
packages:

- https://github.com/Pylons/pyramid_debugtoolbar

- https://github.com/Pylons/pyramid_exclog

- https://github.com/Pylons/pyramid_tm (master only)

Each defines a tween and registers it into the Pyramid tween chain.

- C

[Alexandre Conrad]

2011/8/23 Chris McDonough <chr...@plope.com>

Pyramid 1.2a1 has been released.  This is the first alpha release in
the 1.2 series.

Congrats!
 

A "What's New In Pyramid 1.2" document exists at
http://docs.pylonsproject.org/projects/pyramid/1.2/whatsnew-1.2.html
describing the differences between 1.1 and 1.2.

So tweens. It sounds like applying a decorator to each of my views, right?

--
Alex | twitter.com/alexconrad

[Michael Merickel]

Tweens are "Pyramid-specific middleware". They go between the WSGI stack and the main Pyramid application, effectively wrapping your app.

--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.

To post to this group, send email to pylons-...@googlegroups.com.
To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.

--

Michael

[Graham Higgins]

Ah right... looks like misunderstandings all round.

I shall reply privately. If there's a resulting fruitful discussion, I'll post a summary.

[cd34]

Word of note:

config.commit()
config.include('packagename')
config.scan()

If scan is executed prior to include, and your include modifies the
root factory or authnauth, auth won't actually work.

[Chris McDonough]

Sorry, cannot repeat with 1.2a1. If you put the following in app.py:

# app.py

from paste.httpserver import serve
from pyramid.config import Configurator
from pyramid.view import view_config

@view_config(permission='view', renderer='string')
def myview(request):
return 'OK'

if __name__ == '__main__':
config = Configurator()
config.commit()
config.include('submodule')
config.scan('__main__')
serve(config.make_wsgi_app())

And this in submodule.py:

# submodule.py

from pyramid.authorization import ACLAuthorizationPolicy
from pyramid.authentication import AuthTktAuthenticationPolicy
from pyramid.security import Deny, Everyone, ALL_PERMISSIONS

class Root(object):
__acl__ = [(Deny, Everyone, ALL_PERMISSIONS)]
def __init__(self, request):
pass

def includeme(config):
config.set_authorization_policy(
ACLAuthorizationPolicy())
config.set_authentication_policy(
AuthTktAuthenticationPolicy('seekri1'))
config.set_root_factory(Root)

And try to visit '/' in a browser, it 403's, which is correct.

- C

[Chris McDonough]

On Thu, 2011-08-25 at 18:09 -0700, cd34 wrote:

Tracking this at https://github.com/Pylons/pyramid/issues/256

- C

[Ben Bangert]

On Aug 24, 2011, at 11:48 AM, Mike Orr wrote:

> There are two things you lose with @view_config. One, routing details
> are pushed into the view modules, while Handlers and Pylons try to
> make a complete separation between the functionality of the actions
> and which URL they're called by. Although in this new format, the
> commonality is the route name rather than the URL pattern, so that
> maintains some independence from the URL.
>
> If you use 'match_param='action=logout'', that puts more routing
> detail into the view method than I'm comfortable with at first glance,
> but I guess it's essentially the same as having multiple @action's on
> the same view method, with the advantage that the match variable is
> called by its own proper name ('action') rather than 'name'.
>
> The other disadvantage of @view_config is you have to use
> Config.scan(), which, while it has been working fine in Pyramid 1,
> still seems a bit magical to me.
>
> I don't think I'll change Akhet since its purpose remains to be
> Pylons-like, but I'll add "something" to the manual that suggests this
> new structure should also be considered.
>
> The debug toolbar sounds interesting; I'll have to check it out.

I should note this is the exact reasoning for having pyramid_handlers in the first place. Part of it was conveinence and avoiding boiler-plate, but the more major reason was an architecture decision about *where* the information about URL's and the code they dispatch to actually belongs.

Using @view_config inherently pushes the code hookup throughout the app, while add_handler is specifically arranged so that you can tell from a single location both the URL's *and* the handler that will be handling them (without having to grep your entire project, or use paster pview to see what is going where).

I'm looking forward to Michael's route groups feature, which will make things much easier for URL generation. :)

Cheers,
Ben