On 1/5/07, James Bennett <[EMAIL PROTECTED]> wrote:
I can't find it now, but I have this odd feeling that somewhere I saw mention that LazyDate was/would be/should be deprecated in favor of just using the appropriate methods from the datetime module (e.g., instead of using a LazyDate object as a default for a DateTimeField, use datetime.datetime.now, and so on). Or am I getting all confused again?
The reference you are probably thinking of is the field_defaults modeltest. It doesn't mention LazyDate - it justs says that you could use datetime.now as a callable default value. The only place 'LazyDate' turns up is in the model API. datetime.now (passed as a callable) isn't a complete solution, though. You can't use a callable in a query argument - at least, not in the current implementation of queries. A similar problem exists for field initial values. I can't see any particular reason that a callable shouldn't be allowed just about anywhere in a model definition or query definition. It's just more work to allow it. But this would allow us to officially deprecate LazyDate (which appeals to me because of the number of times LazyDate has bitten me on the posterior testing bugfixes, etc). Anyone want to volunteer? Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
