OK, you have me convinced :) My assumption was that the developer
changing these options would take the time to ensure that the database
supports it, but I can see why one might assume that if the API
supports it then the database probably does too. I will do a survey
of the django supported databases to see which support the two cases.
I hope you feel better (from the cold, that is :)).
- Farhan
On Nov 26, 12:09 am, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:
> On Thu, Nov 26, 2009 at 1:52 PM, thebitguru <fah...@gmail.com> wrote:
> > Thanks for the reply, Russ.
>
> > I need to revise the patch, but I need some confirmation. I am not
> > sure if it is worth determining what all the different databases
> > support. I think optional parameters (allow_{inf,nan}=False) that let
> > the user specify that django should allow these two cases would be
> > sufficient. Note that I am suggesting setting these to False, which
> > will break compatibility, but I believe that this is really what the
> > average user is expecting anyways.
>
> How could it break compatibility? From my testing (i.e., running your
> test cases), passing in NaN or Inf raises exceptions at the moment. At
> this point, it's impossible for any patch dealing with Inf and NaN to
> break backwards compatibility, because there is no working baseline
> behavior.
>
> > If I can get a confirmation that this behavior will be acceptable then
> > I will go ahead and submit an updated patch that reflects this
> > change. This time I will ping again in one week :)
>
> Adding a configuration doesn't always solve a problem. More often than
> not, it adds a new problem. This is one of those cases.
>
> Putting a choice in the hands of a user which can come back and bite
> them is not in the style of Django. Defining a DecimalField with
> allow_inf=True will cause errors if you use a Postgres database. I'm
> not about to commit code that will allow you to have a valid Django
> configuration that throws errors in production.
>
> This is why a survey of the current level of support in databases is
> important. If, for example, no database supports Inf, then there is no
> reason to even have an allow_inf setting. If support is varied, then
> we need to have a discussion about the right way to handle the
> variation.
>
> There is also the issue of good API design to consider. From a
> practical standpoint, I'm having difficulty thinking of a reason why
> allow_nan needs to exist - why should an end user be allowed to submit
> as a form value that is, a priori, known to be invalid? Essentially,
> you're allowing the user to submit "divide by zero" as a valid form
> value - what is the use case for this?
>
> In summary, the process goes like this:
> 1. Get the API right
> 2. Implement it.
>
> We're still on step 1. :-)
>
> > Enjoy the thanksgiving,
>
> Thanks, but FYI: Thanksgiving on the last Thursday in November is a
> US-only holiday. It's held on other dates in some countries, and not
> at all in others. Australia doesn't celebrate Thanksgiving at all.
>
> Yours,
> Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
