Thanks Steve for your great reply! In my use case, the "users" will (likely) not be using it as a platform as a service, but executing the pyramid application locally. My users will be comfortable with writing python and seeing stack traces.
You're right that I will have to write documentation and teach them caveats. A lot of this stuff does "just work" though. Many people will learn from example code, which won't teach them that you have to be certain you can't ever raise a KeyError in the wrong place. In addition, I'm not sure _as an experienced python developer_ how to write code which guarantees it doesn't raise a KeyError. You've reminded me that I'm stuck at a microscopic level looking at one problem when there exist other things to worry about - especially once you throw other users writing code into the mix. However, I complain about this one behaviour for a specific reason: it's hell to debug. It's silent error passing. It's "that's funny, why is my data subtly wrong?" and a violation of the assumption that "if it's an exception, I'll get a stack trace (or error e-mail, or whatever), like I always do whenever there is an exception". I've spent a lot of time going "that's funny, why does it give me resource not found, this should definitely exist.." Brief thoughts inline. On 6 March 2013 16:05, Steve Schmechel <[email protected]> wrote: > In essence, you stated that you want to have "inexperienced users" writing > "untested code" that simply works. That is a very ambitious goal and you > probably have a great deal of work to do beyond getting traversal to > function, in order to have any hope of having system that can be stable and > maintainable by inexperienced users. > Indeed. It's ambitious, it might not work, it might be stupid. It works really well so far except for this one thing which has been a recurring issue for me. Are any exception messages going to be clear enough for them to know how to > take corrective action to fix an unforeseen problem in their own code, > without understanding the Pyramid internals? You probably need a whole > layer of code checking/introspection with custom feedback to guide the > users - *before* they deploy their code into the live system. > In this case I'm worried about the user using a dictionary (something they're likely to do) and just fat fingering something such that they cause a KeyError somewhere in the traversal. A stack trace telling them exactly what dictionary had a KeyError, and what the missing key is would be extremely helpful. It would at least not mean hours of trying to figure out why traversal appears not to be working at all. > If someone wants to select the color of their car at a dealership, they > don't hand them the manual for the painting robot at the assembly plant, > even if it is "the best painting robot manual ever written". > :D, I like this analogy. I will use it as I hand them the pyramid manual. If you don't handle all the possible problems in your code, it seems you > are simply delaying the point where your users must become Pyramid > developers, to when they experience their first bug and have to crack open > the Pyramid documentation to figure out how to fix it. > Yup. Except that this caveat isn't really explained anywhere that I've seen, so becoming a Pyramid developer won't help, to first order. That's one of my biggest problems with this, that I see there might well be bugs lurking in existing applications, since I managed to write a lot of code before I encountered this problem. And then I managed to use my application and encounter weird issues for quite some time before I understood the root cause. > For most people building stuff on top of Pyramid, the fact that it is > simple, stable, and thoroughly tested is of greater importance then the > ease of integrating it into every conceivable use case. I really do not > need or want a bunch of framework-specific exceptions thrust upon me to add > to my learning curve. And if I someday want some, I will override what I > need to in order to add them. > I think that is probably what you are going too need to do. > I very much appreciate this and I'm quite happy to be told "no changes to pyramid, go away". I haven't seen any other discussion on this matter though, so I thought it was worth having an exhaustive discussion. I read what I've written and I hate the whiny tone, so I should probably stop talking now. If you read this far, thanks. Again, I love the way the project is and by no means am I saying "my way is right" (I don't even have a way..), I just would love to see a clean solution to this. Maybe copying the existing traverser and excising the catch is it. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
