Re: GSOC2012 Proposal for 'Finishing off the App Refactor'

2012/3/30, Travis Swicegood : > On Thursday, March 29, 2012 at 10:50 AM, Nauho Zen wrote: > I think we should probably stick with one problem domain per-application > just to keep things simple. OK. Then I will enhance my proposal focusing on app-loading stuff and submit it

Re: Dropping django.utils.simplejson

On Thu, Mar 29, 2012 at 10:06 PM, Alex Ogier wrote: > So in the process of removing simplejson I realized it's not strictly > true that we no longer need to bundle it: if someone uses 2.6+ but has > a 'json' module with a different interface sitting in front of the > system

Re: Dropping django.utils.simplejson

So in the process of removing simplejson I realized it's not strictly true that we no longer need to bundle it: if someone uses 2.6+ but has a 'json' module with a different interface sitting in front of the system json on sys.path, then Django currently falls back to bundled simplejson. I don't

Re: Dropping django.utils.simplejson

There's still a ~20x performance gain over 2.6's stdlib by using simplejson even without C-extensions according to http://bugs.python.org/issue6013. Depending on how heavily people depend on the module, removing simplejson may be a "backwards incompatibility" in the sense that performance may

Re: Dropping django.utils.simplejson

Option 2 looks best to me. There's no reason for us to ship JSON any more, but we should still guide people through the transition process. Yours, Russ Magee %-) On 30/03/2012, at 7:07 AM, Łukasz Rekucki wrote: > Alex's comment on ticket #18013 reminded me of this. Is there any > reason not

Re: Dropping django.utils.simplejson

On Thu, Mar 29, 2012 at 6:07 PM, Łukasz Rekucki wrote: > Alex's comment on ticket #18013 reminded me of this. Is there any > reason not to get rid of the Django's version of simplejson now that > Python 2.6 always has the json module? > > I see three options here: > > 1)

Dropping django.utils.simplejson

Alex's comment on ticket #18013 reminded me of this. Is there any reason not to get rid of the Django's version of simplejson now that Python 2.6 always has the json module? I see three options here: 1) Remove Django's copy and only leave the simplejson/json fallback. 2) Above, plus deprecate

Re: Django should not use `force_unicode(..., errors='replace')` when parsing POST data.

I agree that it is not an ideal user experience to raise an exception while decoding POST data. However, I think the alternatives are arguably just as bad, or even worse. I consider silently replacing characters in user data to avoid an exception while decoding to be a silent data loss /

Re: GSOC2012 Proposal for 'Finishing off the App Refactor'

On Thursday, March 29, 2012 at 10:50 AM, Nauho Zen wrote: > > > > All of this said, I'd love for this to be a GSoC project, but I agree > > > Preston that yet-another-GSoC slot spent on this might not be the best use > > > of the project's GSoC slots. > > > > > How about combing the "Test

Re: Django should not use `force_unicode(..., errors='replace')` when parsing POST data.

It should also be noted that it is a terrible user experience to raise an exception in the middle of parsing the multipart parser---a socket error with no error message. Not to say that you can't slurp in the data and raise the exception afterwards, but care has to be given if that strategy is

Re: Django should not use `force_unicode(..., errors='replace')` when parsing POST data.

On Mar 29, 2012 5:43 AM, "Tai Lee" wrote: > > I've just created an essay *cough* I mean ticket about the way Django > silently mangles POST data that is incorrectly encoded, and how this can send > someone (like me) down the rabbit hole trying to debug it, thanks to

Re: Django should not use `force_unicode(..., errors='replace')` when parsing POST data.

Tai, The idea behind errors='replace' is that any chars that cannot be properly decoded as unicode will be replaced with an acceptable unicode char (something like '?'). So, if you want to avoid crashing your program on bad input, this is the only acceptable approach and, I assume, why the

Re: GSOC2012 Proposal for 'Finishing off the App Refactor'

> > All of this said, I'd love for this to be a GSoC project, but I agree > > Preston that yet-another-GSoC slot spent on this might not be the best > use > > of the project's GSoC slots. > > > How about combing the "Test framework cleanup" idea on the SummerOfCode2012 wiki page with "Finishing

Django should not use `force_unicode(..., errors='replace')` when parsing POST data.

I've just created an essay *cough* I mean ticket about the way Django silently mangles POST data that is incorrectly encoded, and how this can send someone (like me) down the rabbit hole trying to debug it, thanks to "current transaction aborted" database errors. This shouldn't normally

Re: #18003: New policy: preserving originating call stacks for exceptions raised in a naked except block.

Le 29 mars 2012 09:51, Glenn Washburn a écrit : > So I feel strongly that django should have as a matter of > policy that originating call stacks should be preserved for raised > exceptions in naked or overly broad except blocks. That's one of the reasons why we have

#18003: New policy: preserving originating call stacks for exceptions raised in a naked except block.

I think the mailing list might be a better place to start/have this discussion on policy. But I've made a ticket (#18003) so it can be officially dealt with an recorded. I've had trouble with debugging exceptions passing through or coming from django on several occasions because exceptions were