#pyramid

the doc, that is

cdunklau: thanks, yeah, i found that yesterday myself

the problem with route overriding in ordering sensitivity

Zart: my gist example only has one route and i still can't override it

that's the somewhat perplexing part

because you havent commited config

ah, ok

call config.commit() after config.include

and it will work

otherwise you're trying to define route twice inside the same transaction

thanks, will try

didn't mean to interrupt you on the ordering point though.... what were you going to say there?

say, you have add_route('/foo') and add_route('/foobar')

if they added in this order, then /foobar route wont ever match

because /foo will match any /foobar as well

so in the overriding scenario using includme, third-parties that want to add more routes might get hosed because includeme added "/foo" and they are then trying to add "/foobar"

yes

hmm

ok, that's good to know

i need to be thinking of this like iptables

;-)

it's possible to compose routes, but you will have to deal with ordering somehow

for example implementing priorities, like tweens do

or defining variables like pyramid.includes

i'll have to familiarize myself with that stuff

Zart: thanks for the pointers! is there any source code that you can think of that implements a capability for setting default routes via includeme that can than be overridden? I was hoping to find such a thing in cornice but i can't quite understand what it's doing under the hood

hm

https://github.com/mozilla-services/cornice/blo... and #L186

basically service name = route

yeah, i seems like cornice is adding the routes at the application level and not at the includeme level

which makes sense given what you're saying about the importance of ordering

might be fun to define both foo and foobar service...

hmmm... yeah

http://blog.notmyidea.org/refactoring-cornice.html seems they're going to remove routing registration

or already did

"The resulting branch is not merged yet."

this is super useful for me insofar as it's a nice case study in what NOT to do

still not entirely clear that the new branch solves the foo/foobar problem

add_route is now explicit and separate

ah, i see. so the Services defined in views.py get added to the config in main(..) using the new register_service_views(...)

which presumably also adds the routes

"Please customise your source code for us". "Sure, if you'll pay me". SILENCE

how is the pyramid leadership thinking about async? deferring to other libs like aiohttp or building that support in?

pyramid is a wsgi framework

wsgi doesnt play well with async by design

NotreDev: aiopyramid does work though if its something you are interesting. Using async stuff isn't as big of a win as people think because its usually not the webframework blocking you, its your DB driver and majority of those aren't async aware

NotreDev: I frequently use pyramid with Twisted (via hendrix) and it works well for async tasks.

sontek: NotreDev aiopg + SQLA's expression syntax works well if your DB is postgresql, but you don't get to use the ORM

[redacted]

[redacted]

[redacted]

[redacted]

python got a new toy so now people want to try it out.. not surprising

dowwie: ha get out of here

[redacted]

[redacted]

[redacted]