Re: Proposal: Add signals test_setup and test_teardown to Django test suite runner

2010-09-20 Thread Jim D. 
Cool, thanks

On Sep 20, 3:30 pm, Carl Meyer  wrote:

> Thanks for your work on this! The usual Django workflow doesn't
> include patches to the mailing list: rather you can go ahead and open
> a Trac ticket and attach the patch there (even if you aren't sure of
> the approach yet), and reference the ticket number here.

Cool, thank you Carl. I'll go ahead and submit it as a ticket and let
it take its natural course from there.

> So where this would break is if someone is doing a bit too much at
> import time of their tests module (like in the class body of a
> TestCase subclass): for instance, saving something to the database. I
> have to admit (gulp) that I have actually done this before and it
> currently works fine, but it's not really good practice and it's
> certainly not documented anywhere that you can do that, so personally
> I'm not sure it would be a problem to break it.

Yeah, that's what I was thinking too. Maybe other people will have
examples where it might cause some critical issues, I guess we'll see.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Add signals test_setup and test_teardown to Django test suite runner

2010-09-20 Thread Carl Meyer 
Hi Jim,

On Sep 19, 1:19 am, "Jim D."  wrote:
> I found some time this evening to work this out, and have included a
> revised patch for this proposal at the end of this message.

Thanks for your work on this! The usual Django workflow doesn't
include patches to the mailing list: rather you can go ahead and open
a Trac ticket and attach the patch there (even if you aren't sure of
the approach yet), and reference the ticket number here.

> * The addition of this feature required what I imagine to be a
> significant change to test suite runner. Namely, I switched the order
> of the build_suite() and setup_test_environment() methods in
> run_tests().

So where this would break is if someone is doing a bit too much at
import time of their tests module (like in the class body of a
TestCase subclass): for instance, saving something to the database. I
have to admit (gulp) that I have actually done this before and it
currently works fine, but it's not really good practice and it's
certainly not documented anywhere that you can do that, so personally
I'm not sure it would be a problem to break it.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

#14299 Add additional cache.*_many functions

2010-09-20 Thread Michael Manfre 
In an effort to clean up some of my project code and reduce latency
from extra cache calls, I uploaded a patch that allows a cache backend
to implement offset_many (multiple incr/decr) and add_many. Default
implementations are provided.

The patch is ready for review.

http://code.djangoproject.com/ticket/14299

--
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Possible bug discovered

2010-09-20 Thread Hanne Moa 
On 19 September 2010 09:08, Yo-Yo Ma  wrote:
>  File "C:\Python26\Lib\site-packages\django-trunk\django\template
> \__init__.py", line 352, in add_library
>    self.tags.update(lib.tags)
>
> AttributeError: 'NoneType' object has no attribute 'tags'

Check for import loops. I've seen these often. Try peppering the code
with "assert False", check especially whether functions can see
variables outside its own scope, e.g: imports on module level, or must
you import in the inner scope of the function/method to make a name
visible?

Check also that you don't have a namespace collision, that is: a
django app has the same name as something non-django in you
python-path and you import the wrong module.


HM

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #9459 forms.DateTimeField() looses microseconds

2010-09-20 Thread Thomas Guettler 

I uploaded a new patch (against trunk) which works on Python 2.4:

http://code.djangoproject.com/attachment/ticket/9459/datetime-microseconds-py24.patch

I think it is ready for commit.

  Thomas

Tobias McNulty wrote:
> On Thu, Sep 9, 2010 at 5:43 AM, Thomas Guettler  > wrote:
> 
> Here is the patch:
> 
> http://code.djangoproject.com/attachment/ticket/9459/datetime-microseconds-py25.patch
> 
> If the python version is greater-equal than 2.6, it uses %f to parse
> the microseconds,
> for older versions it parses the last integer itself.
> 
> 
> The patch looks reasonable enough to me and I'm excited about getting it
> in.  Have you tested it on Python 2.4, 2.5, and 2.6?
> 
> Cheers,
> Tobias

-- 
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.