#pyramid

Charlie_X: haha... we really should start PyFarts :)

See if Felix can whip up a logo.

It would be nice to have the SubstanceD logo in it somewhere.

pills makes you fart!

certainly seems to work for stevepiercy_away

We could have our own code of conduct: you have to fart before you can talk

sure we need a CoC

Given Charlie_X's declaration of bromance above, I hope that is not a typo.

nomen est omen

We love CoC's

A nice juicy CoC shows you mean business.

CoCs always let me feel like this http://cl.ly/image/322e2q3U2m0a

but thats just between you and me :P

how true

[redacted]

[redacted]

Can we have the link without the tracker code? ;-)

Hi there!

To use adapters or not to use adapters? That is my question.

adapters are great, use them and love them

:-D

but you must be part of the PyFarts group

1 - A pyramid app A use an addon X.

2- X provides BasicAuthentication

3- X Basic auth deserialize username: username == "{consumer_type__consumer_id}"

(reason for having an addon used by lots of services)

lots = 2 ;-P

4- A provides verification on DB

So I though, we adapt A and X

Does that make sense?

@deuxpi I am ambitious

deuxpi: ^

hadr: it doesn't really make sense.

:'(

Adapters work at the object level

Charlie_X: sure, I meant:

Just like putting an adapter on a headphone plug.

pastebin might make more sense

Charlie_X: not the full file: https://gist.github.com/hadrien/3634ce50e73f5b2...

but you get the idea

(or not) :-/

Strictly, that's a service rather than a straight adapter but looks okay except for the return None's

As usual raydeo has a gist on using an authentication service

Charlie_X: note that there are 3 other adapter queries for the 3 others consumer types but, I removed them for clarity

I don't really see the problem you're attempting to solve.

Charlie_X: Keep the addon unaware of db when verifying API consumers credentials.

That's the whole point of a service.

i was wondering, wouldn't it make sense for the request.json_body to raise something like JsonNotFound(ValueError) instead raising just ValueError?

I guess I just don't understand the add-on thing.

seems to make sense for writing rest api's

Ergo: why a more specific exception if it is a ValueError?

Charlie_X: in my case for example is you have empty forms in angular - it will make "empty" post, without values

Charlie_X: Thank you for your support, will you be at PyCon?

so you will end up with exception instead getting your json validated

hadr: yes, but I'm not really the guy to ask about this.

Charlie_X: which is a bit annoying

Then NotFound

I find you very rarely need to invent new exceptions

Charlie_X: yeah but you have to handle this in every place you use that

and with custom exception you could handle globally

Paste some code

i guess i could make a property in request object instead

Charlie_X: if we ever meet at pyramid booth, I can advice for good microbreweries in town ;-)

hadr: you'll have to whisper so the other's don't here.

ehh.... im not coming this year, and i wanted too

we would have a beer together

We would even have 2

We spent a whole afternoon and evening in one fine place on Shrewsbury? last yeart.

Shrewsbury?

Do you mean Sherbrooke?

yeah

-> http://brasseriebenelux.com/sherbrooke

That's the one.

Montreal Python Headquarters