What if we would make the 'decimal_places' argument illegal for the new FloatField? That exception would make the change impossible to miss. Hope I'm not missing anything obvious with this idea, it just popped into my head.
On May 14, 11:25 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
