#pyramid

406 ;)

That darn well better end in a 406 at some point :\

Well, if a user has a view without accept=

then we can't implicitly esend a 406

so the user has to handle it themselves.

views can return whatever content-type they damn well please

Never do it, so never think about it

even if the browser didn't ask for it.

views return content... renderers render that content

Yes, sorry

render is usually coupled to the accept registration

renderer*

Even if the browser only asks for text/html, I can still send application/json in a response

well, a view/renderer pair

yeah perhaps... a footgun

look how many frameworks actually care about accept at all

at least in my experience

That's because content negotiation is fucked... I really want to write an RFC to make the ordering more explicitly well defined, and update the various RFC's related to it.

Then built a new content-negotiation RFC that actually describes an algorithm that everyone can implement.

I look forward to using it in 20 years

Explicitly codify left -> right, it's practically a standard anyway since Apache has been doing it since mod_negotiation was introduced.

Explicitly state that the server should try to cater to the client rather than the other way around, and remove all of the edge cases.

it's not like there's any fallback if the client receives a 406, which is why no one returns it

But I also want a unicorn and a million dollars

while your at it x58 go for https://en.wikipedia.org/wiki/HTTPRange-14 too ;)

Well, you are supposed to give the client a list of alternate resources when you reply with a single resource if multiple resources match for the Accept header

gavinc: Ugh, another one I am unhappy with.

x58: I'm off dying on the URL parsing hill still. Accept isn't that broken ;)

raydeo: So the RFC actually does specify that if you can't find a good enough resource, you are supposed to tell the client what resources you do have and their content-types and let it retry the request with one from the list :P

raydeo: Or you pick one, send back 200 OK, but provide a list of alternates just in case the client wants to retry the request and pick an alternate from the list of offered suggestions.

Then add language negotiation to the list...

and encoding

and all that other shit

and it's a cluster fuck.

no thank you

bcp47 is where it all goes to hell :D

There's an open bug against WebOb and I really don't want to tackle it...

ok so going back to accept... can we turn this into an actual fix?

do you want to ship best_client_match? settled on that?

Yep, settled on that.

add weighting to accept= and sort based upon the weight.

any thoughts on how to handle this on the pyramid side? the weighting was one idea

make it 0 -> 100 or something like that, and the default should be 50.

I also proposed just a full knob where users can provide their own sorter instead

IAcceptSorter

config.set_accept_resolver()

their own sorter or even their own resolver

(request, offers) -> offer

Let's ship with weighted first... see if that solves 90% of the problems, can always add the custom resolver path later.

well I would've gone the opposite direction and shipped the more general solution first

the thing with the resolver proposal is that you could even raise a 406 there

If we fix it to use sorted weights, it will solve the problem for 90% of the issues we've seen on the GH issue tracker

That being said, I am not opposed to the resolver solution.

I agree with both comments

I feel like the weighted solution is a simpler fix, the resolver is going to have a bunch of bikeshedding.

it's a pretty limited api, I don't actually see much bike shedding there but curious what you think

I like that it gives a path forward for 406 errors

maybe

config.set_default_view_accept('text/plain', 50)

then you can have a path forward for 406 errors

That way there are no views in the system without accept= set.

Otherwise if there is one view without accept=, you can no longer do 406 because of the way the view machinery works.

only if accept becomes a predicate?

(it's not right?)

it's not a predicate

sort of

It's not a predicate at all.

it is a predicate at all

YEs

trust me, it's sort of

I'm aware of your documentation fix and such but that doesn't change the weird things you can do with it in the code

That predicate is never fired though as a predicate.

accept gets pulled out of the predicate fix IIRC.

s/fix/list/

pretty sure that's false

it's actually in the predicate change and you can sort predicates above it in weight

s/change/chain

You are right, because ovals contains accept=

I'm pretty sure it even evaluates the predicate

after the view was selected

I could never get it to fire when I was testing a while back, maybe I missed something else.

the accept stuff is dealt wtih in the multiview code

yes, but it's also a real predicate registered on the view

the multiview just checks it *also*

Really the predicate should go away

It's unnecessary

I don't see any reason that wouldn't be happening

It may have been missed when accept become a non-predicate.

sure, it's just done atm because it was easier to implement a lot of the book-keeping as a predicate

at least that's my guess

it gets introspectables, etc automatically

Also introspection

Yeah.

Ugh, it's a mess.

well fortunately monokrome will fix it this weekend (I hope)

ok I'm out for a while... I'll chew on the pyramid api a bit in the meantime

I'll try -.-

raydeo i'm not experienced with interpreting why tests fail, and i think i'm going about it all wrong

i'm obviously missing some required knowledge or experience, some unknown unknown...

taking that one test as an example, for which i restored the slice, (and which happened to fix several other tests), how would i isolate the problem?

first clue is looking at the stack trace

so i looked in there, and found that argparse was displeased

that gave me a hint, that i messed up the args

now onto the next failing test, TestPCreateCommand.test_no_project_name, i see a similar pattern, but i'm spinning my wheels trying to figure out what next?

i gotta take Boogy for a walk, bbiab, but any tips or strategy to follow would be greatly appreciated

stevepiercy: Link to the errors?

x58 http://paste.ofcode.org/FiVcM4NvAMQ3z4LiuNqx69

i read that as cmd could not successfully call the method _makeOne() with its two args, correct?

why it fails evades me. i've been reading the tests over and over, and it's not sinking in

FWIW, i'm focusing on _makeOne

stevepiercy: looks like it expects -s, the scaffold name, and an output directory, but you’re only proving the first two

(but I don’t have much context)

yeah, here's more context

i'm working on this branch: https://github.com/Pylons/pyramid/pull/2842

er, the branch for that PR

with the ultimate purpose of documenting the p* scripts via Sphinx

and to do that, i had to replace optparse with argparse

here's pscript.py as an example of the diff: https://github.com/Pylons/pyramid/pull/2842/fil... (github's diff implies more changes than what i actually did)

the diff between line 82 old and line 86 new is what i think is gumming up the works

last week, i know nothing about argparse and optparse, and now i know slightly more than zero

stevepiercy: argparse is calling _sys.exit and quitting the ptest run.

Where is your full test?

optparse doesn't quit on bad input

argparse does