I had a patch all ready to commit, doing the long-awaited FloatField ->
DecimalField change and putting in a "real" FloatField. Then I realised
I was about to do something silly.
Renaming FloatField to DecimalField is simple and obvious. The
backwards-incompatible change means people have to do a once-only search
for FloatField and replace it with DecimalField. No problems.
The "new" FloatField is trickier: I'm a strong believer that, as much as
possible, backwards incompatible changes should try hard to break your
code if you are relying on the old behaviour. Usually, this shows up as
a syntax error because you try to call a method or class that no longer
exists.
Introducing a new FloatField with subtly different behaviour to the old
one is a trap for existing code. Your code will still run. You will
still be able to load and save values. However, you may get silent data
loss (trying to insert floats into a fixed-precision field) and if you
recreate your database tables, the underlying field type will have
slightly different behaviour. This may or may not be a big deal -- and
that's my problem: it's a silent killer in the cases where it is a big
deal.
So we have a few options:
(1) Soup-nazi style: "no FloatField for you!" -- just don't
implement it. I think this is a bad choice.
(2) Nike style: "Just do it" -- make the change and let people
who aren't paying attention sort out the problems (if any) when
they discover them.
(3) Find another name for the new, genuine FloatField. Problem
is, "FloatField" is a really good name. All other names I can
think of are longer or non-Pythonic (e.g. NumericField only
makes sense if you think "SQL", not "Python").
(4) Other. [Insert suggestion here]
I'd rather avoid doing any runtime database introspection checking,
because it crosses the barrier between models and backends.
My favourite option at the moment is (2), but it feels a little cruel.
There's lots of evidence to suggest people don't read instructions until
they are forced to (e.g. their code doesn't work) and we know this, so
blissfully ignoring that fact doesn't sit quite right with me.
Anybody with good suggestions for a solution. This change is ready to go
if we can solve this one little problem (and it fixes a bunch of other
decimal problems).
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
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?hl=en
-~----------~----~----~----~------~----~------~--~---
