On Thu, 2007-11-15 at 20:07 -0500, Karen Tracey wrote: > DateFields in model instances pulled from the database appear as > datetime.date objects: > > >>> from crossword.models import Puzzles > >>> p1 = Puzzles.objects.get(pk=2456) > >>> p1 > <Puzzles: NYT Fri 2001-07-13> > >>> p1.Date > datetime.date(2001, 7, 13) > > However, I don't need to pass in a datetime.date object when > creating a new instance, since a properly-formatted date string works fine: > > >>> p2 = Puzzles(AuthorID=p1.AuthorID, PublisherID=p1.PublisherID, > Date='2007-11-15') > >>> p2 > <Puzzles: NYT Thu 2007-11-15> > >>> p2.save() > > That's convenient (and, I gather fairly new -- I think it is new > behavior as of about 2 months ago with the fix for #3146). But now > the type of the Date field in my puzzle instance object differs > depending on whether I pulled it out of the database or created it > using a string date specification: > > >>> p3 = Puzzles.objects.get(pk=p2.pk) > >>> p3 > <Puzzles: NYT Thu 2007-11-15> > >>> p3 == p2 > True > >>> p3.Date > datetime.date(2007, 11, 15) > >>> p2.Date > '2007-11-15' > >>> > > I'm just wondering if this is intentional/desired? I rather expected > the string '2007-11-15' to be turned into a datetime.date object > during the creation of the object p2, so was surprised when I handed > p2 off to some other code that has only ever dealt with puzzle > objects pulled from the database and it fell over since Date was a > string, not a datetime.date. It's easily enough fixed in my own > code, I'm just wondering if it might be better for the Django code to > auto-convert supplied strings to datetime.date objects so that the > object's history doesn't affect the field's type?
Personally, I think if you don't pass a datetime object to a datetime field, it should be an exception, but I seem to be on the outer in asking people to use the right types in their code to keep things clean, so I've lost that battle. What we don't want is the overhead of calling to_python for every single field type, since many of them don't need it and model instance creation is expensive enough as it is. So it would require a __set__/__get__ pair and a change to contribute_to_class for that Field subclass. There is a design trend running through Django's fields that apparently (this is me talking based on reverse-engineering the original thinking) conversion to the "natural" type happens in Field.pre_save(), before doing any database interactions. That's probably not so bad. pre_save() also updates the model attribute. Except this isn't done for DateFields and friends. You already have to handle this slight type mismatch with strings if you initialise from bytestrings (since loading from the db gives unicode), although in that case everything is still a basestring. So you'll either have to convince the right people on django-dev that it's worth making DateField (and related fields) use the descriptor protocol, change pre_save to do the conversion, or just use the right types in the first place (how hard can it be??) if you want consistent types down the line. I'd probably favour fixing pre_save() to be consistent, but, as I mentioned, my personal sense of good style has already been tilted at by the current behaviour, so any middle-ground looks a bit odd. Regards, Malcolm -- I just got lost in thought. It was unfamiliar territory. http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" 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-users?hl=en -~----------~----~----~----~------~----~------~--~---
