On Mon, 2006-07-03 at 23:33 -0700, jws wrote:
> > (1) It's been closed twice; once each by Jacob and Adrian. Closing it or
> > applying both make some sense to me, so I'm not about to go any further
> > without some clarification.
>
> The discussion regarding the closure and subsequent re-opening are
> documented here-
>
> http://groups.google.com/group/django-developers/browse_thread/thread/741ac793a9bf8459/d9bf516943a2e997?q=jws&rnum=1#d9bf516943a2e997
No need to retype all the information, but that link should be attached
to the ticket, since it provides relevant background. Without that, the
ticket reads very differently.
> > (3) The patch still needs some work. There is neither documentation nor
> > test cases with it, so if I was to sit down and try to resolve this,
> > it's still going to take a bit of time (not sure if documentation is
> > required or not, but that will take some thinking to work out, too).
>
> I think the previous discussion is comprehensive. Would summarizing the
> discussion in the ticket be more helpful?
Does it need any additions to the API documentation was more what I was
wondering about. Maybe it doesn't, but it's always something that needs
considering.
> The lack of test cases is more convincing.
They should be added, since we are bound to get some edge cases wrong
(c.f. initial SQL parsing) and having regression tests will help there.
If you could add those, that would be great. Testing both sorts of
quotes, backslashes, semicolons and percentage signs would be my
suggestion for a start. What other characters might we screw up?
Anything that is dangerous for any database or that we might be using as
a replacement hook is a candidate.
A couple of other things I noticed just reading it through quickly:
(1) Python traditionally uses "!=" rather than "<>" for "not
equals".
(2) NotImplemented is a type, not an exception. You want to
catch the NotImplementedError exception (although I can't see it
being raised anywhere by your additions; is that an omission?).
(3) You could combine the rawchars and cookedchars lists into a
single list of pairs and then just do "for before, after in
new_list:" . That will prevent inadvertently getting the two
lists out of sequence (and make the code quite a bit shorter).
(4) Maybe you should just write escapechars() once and pass in
the list of things to escape. Currently, any change in one has
to be changed in four places. Is that possible without getting
into import loops?
Some of these may have simple answers, I don't know. I'm working on
other things at the moment, so I don't want to stop completely for this.
But since you've brought this up, we might as well keep the momentum
going to help you get it to the point of being easy to apply.
Best wishes,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
