Re: GSoC 2014 proposal [Improving error reporting]

On Wednesday, February 26, 2014 7:43:49 PM UTC-8, Russell Keith-Magee wrote: > > Hi Anubhav, > > Please keep in mind that this is a global mailing list, and if you want > considered feedback, it's going to take time. Posting two "Please give me > feedback" pings in 6 hours isn't especially help

[GSOC] Shifting to Py.Test and Improving the Test Suite

Sorry for starting a new thread but I thought a proposal should begin with a new thread. (Please refer to the previous thread @ https://groups.google.com/forum/#!topic/django-developers/GO65Qndw4Hg ) I'm writing in points, for easier readability. This is a very brief summary I actually wrote d

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

Hi Akshay, On Thursday, February 27, 2014 8:50:32 PM UTC+1, Akshay Jaggi wrote: > > *Why Py.Test?* (http://pytest.org) > >1. Widely Used > > So is nose and unittest, you'll need to add a bit more info to such statements. > >1. Better reporting > > Better how exactly? > >1. Distrib

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

> > >>1. Distributed testing (speed up, especially on multi-core machines), >>Line Coverage, etc using plugins >> >> How would this work? We still have shared resources like the database > where you can't just run 10 Test against in parallel. > There is django plugin for py.test

Re: GSoC 2014 proposal [Improving error reporting]

Here is another issue that I have analysed. *When the autogenerated field name is too long, there is no proper displaying of errors, many a time silent failures for some database.* Written a fix, although some thinking is required in writing the tests. @classmethod def _check_long_column_name(cl

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

Personally I'm a big fan of Py.test, simply because it's so simple and Pythonic to use. Simple functions with simple assert statements. That's all. For me this significantly lowers the threshold to write tests and requires less effort, which in the end results in way more tests written in Py.te

Re: GSoC 2014 proposal [Improving error reporting]

I think it'll be better to put your analysis of each ticket on the ticket itself. Then when you're finished with that, put together a more high level overview of the analysis you've done. I think it will be easier to give feedback if you structure your thoughts in this way. Thanks! On Thursday,

Re: GSoC 2014 proposal [Improving error reporting]

On Friday, February 28, 2014 2:03:10 AM UTC+5:30, Tim Graham wrote: > > I think it'll be better to put your analysis of each ticket on the ticket > itself. Then when you're finished with that, put together a more high level > overview of the analysis you've done. I think it will be easier to gi

Re: GSoC 2014 proposal [Improving error reporting]

I believe if your tickets are enough work to fill 12 weeks, someone is not going to come along and complete a majority of them in the meantime. You can also add something like "I hope to work on this ticket for GSoC 2014." On Thursday, February 27, 2014 3:57:45 PM UTC-5, anubhav joshi wrote: > >

Re: GSoC 2014 proposal [Improving error reporting]

As suggested by Tim Graham, I am going to put my analysis on respective tickets. Also it is possible that some issues are directly mentioned on wiki page(there is no ticket for them), so its a humble request to please go through it once here. Regards, Anubhav Joshi IIT Patna -- You received t

Re: GSoC 2014 proposal [Improving error reporting]

As suggested by Tim Graham, I am going to post my analysis on respective tickets. But there are some issues where I need help in analysing, I have mentioned those in my above posts. Also there may be issues for which ticket have not been opened, they are only mentioned in the wiki page. Hence, i

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

On Fri, Feb 28, 2014 at 4:17 AM, Gwildor Sok wrote: > Personally I'm a big fan of Py.test, simply because it's so simple and > Pythonic to use. Simple functions with simple assert statements. That's > all. For me this significantly lowers the threshold to write tests and > requires less effort, w

Re: #20824 - Email-based auth contrib module; some help required

normalize_email will indeed allow both u...@example.com and u...@example.com to be different entities. From the user perspective, this is an error. Most probably the user enters some day their email in all upper case because he pressed the CapsLock key, or copy pasted a transcript of his email,

Re: The restricted usage of auth.User model when using custom AUTH_USER_MODEL

OK, I give up. Actually I asked another question related to this topic before developing the application but the answers were similar to yours. (https://groups.google.com/forum/#!topic/django-developers/EnMn9_hU5g0) I had to use monkey-patching to allow dynamic AUTH_USER_MODEL but it wasn't a g

Re: #20824 - Email-based auth contrib module; some help required

On Thursday, February 27, 2014 6:50:38 PM UTC-5, Camilo Torres wrote: > > normalize_email will indeed allow both us...@example.com and > us...@example.com to be different entities. From the user > perspective, this is an error. Most probably the user enters some day their > email in all upper c

Re: #20824 - Email-based auth contrib module; some help required

On Friday, February 28, 2014 12:55:31 PM UTC+10:30, waylan wrote: > > On Thursday, February 27, 2014 6:50:38 PM UTC-5, Camilo Torres wrote: >> >> normalize_email will indeed allow both us...@example.com and >> us...@example.com to be different entities. From the user perspective, >> this is an