Gábor Farkas wrote:
>> Thoughts, criticisms? The only part I'm sketchy on is the side effect
>> of converting the values to their Python data types. The
>> cleanliness/consistency is quite nice, but it's slightly not something
>> a developer might expect. However, we can solve the latter through
>> clear documentation.
>
> >>> p1 = Person(name='Joe', birthday='2005-1-3', favorite_number='foo')
> >>> p2 = Person(name='Jack', birthday = datetime.date(2005,1,3),
> favorite_number='foo')
> >>> p1.birthday == p2.birthday
> False
>
> i don't know. i understand that this would make life easier, but on the
> other hand, it does not feel good for me :) some points:
>
> - explicit is better than implicit
> - we're removing the magic there or adding it back? :-)
> - does this not tie too much the web-layer to the db-layer?
>
> basically.. what does the developer win with the auto-conversion?
> perharps some use-case scenarios would help to explain it to us...
>
> summary:
> it's a very cool change. i'm just not sure about the auto-conversion part.
I'm going to agree with this. At the very least I think a developer
should *always* expect a field on field __get__ to return the Pythonic
type. Under the proposal this would probably mean an implicit
``to_python`` call and half-verification on field __get__, which sounds
un-Pythonic.
Here's a suggestion: abstract the string->python into a field function.
Consistently require Python types, but allow the string unmarshalling
through something like:
>>> p1.birthday.from_string('2005-1-3')
This is clear and explicit, albeit potentially wordy. It would not
allow complete stringified Constructors, but you could easily enough
create a "shortcut" tool. I think this may actually be more suitable
for the Manager class:
>>> p1 = Person(name='Jack', birthday=datetime.date(2005,1,3),
favorite_number='foo')
>>> p2 = Person.objects.html_unmarshal(name='Joe', birthday='2005-1-3',
favorite_number='foo') # convert strings to Python types
>>> p1.birthday == p2.birthday
True
This then makes it possible to change things like locale-based
unmarshalling (or other unmarshal situations, such as importing from
object-db systems or what have you) by overriding the system-wide
default Manager.
--
--Max Battcher--
http://www.worldmaker.net/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers
-~----------~----~----~----~------~----~------~--~---
