Re: DecimalField with no max_digits and decimal_places

On Sunday, June 21, 2015 at 11:17:25 AM UTC+2, Aymeric Augustin wrote: > > (...) > I think we should provide the best API for our users and deal with the > code. > I’m in favor of not introducing another class and figuring out the least > awful > way to arrange the code paths in DecimalField.

Re: DecimalField with no max_digits and decimal_places

“Unlimited” precision is a natural semantic DecimalField(). Likewise, if we ever make max_length optional in CharField(), now providing it will mean “unlimited” length. (Scare quotes because storage is never really unlimited.) I think we should provide the best API for our users and deal with the

Re: DecimalField model validation

On 07/10/2011 06:29, Tai Lee wrote: Why is ROUND_HALF_EVEN superior? Perhaps for statistics, where rounding all halves up would skew results, but I guess not for most other cases. If the default rounding behaviour produces different results than a regular calculator, common spreadsheet and accou

Re: DecimalField model validation

On Oct 6, 2011, at 9:29 PM, Tai Lee wrote: > Why is ROUND_HALF_EVEN superior? ROUND_HALF_EVEN is the standard when doing financial calculations, an extremely common use of DecimalField. -- -- Christophe Pettus x...@thebuild.com -- You received this message because you are subscribed to th

Re: DecimalField model validation

Why is ROUND_HALF_EVEN superior? Perhaps for statistics, where rounding all halves up would skew results, but I guess not for most other cases. If the default rounding behaviour produces different results than a regular calculator, common spreadsheet and accounting software or even human (mentally

Re: DecimalField model validation

On 06/10/2011 02:45, Paul McMillan wrote: .. (A) silent rounding issue: when a decimal value is saved in db its decimal digits exceeding decimal_places are rounded off using .quantize(). Rounding defaults to ROUND_HALF_EVEN (python default). There is no mention of this behavior in

Re: DecimalField model validation

> .. (A) silent rounding issue: >    when a decimal value is saved in db >    its decimal digits exceeding decimal_places are rounded off using >    .quantize(). Rounding defaults to ROUND_HALF_EVEN (python default). >    There is no mention of this behavior in docs. Docs patches welcomed. This rou

Re: DecimalField allows float value as 'default'.

http://code.djangoproject.com/ticket/16015 I've uploaded a patch, but changed the status to 'Design Decision Needed' from 'Accepted.' The problem is that although my patch follows the existing convention and results in passing tests in Python 2.6, the Python core developers have made an import

Re: DecimalField allows float value as 'default'.

On 05/12/2011 08:04 PM, Russell Keith-Magee wrote: I suspect the answer will lie somewhere between get_prep_value() and to_python() on DecimalField, but you'll need to do some code path tracing to confirm. Looking at the code, I'm a little surprised that it doesn't work as is... Yours, Russ Mag

Re: DecimalField allows float value as 'default'.

On Fri, May 13, 2011 at 12:08 AM, Shawn Milochik wrote: > On 05/11/2011 08:00 PM, Russell Keith-Magee wrote: >> >> On Thu, May 12, 2011 at 3:35 AM, Shawn Milochik >>  wrote: >>> >>> Someone on django-users just commented that they set a default value on a >>> DecimalField as a float, and were surp

Re: DecimalField allows float value as 'default'.

On 05/11/2011 08:00 PM, Russell Keith-Magee wrote: On Thu, May 12, 2011 at 3:35 AM, Shawn Milochik wrote: Someone on django-users just commented that they set a default value on a DecimalField as a float, and were surprised when they were unable to create a queryset using a float to find record

Re: DecimalField allows float value as 'default'.

On Thu, May 12, 2011 at 3:35 AM, Shawn Milochik wrote: > Someone on django-users just commented that they set a default value on a > DecimalField as a float, and were surprised when they were unable to create > a queryset using a float to find records. > > I searched Trac for the terms 'DecimalFie

Re: DecimalField returns default value as unicode string.

[EMAIL PROTECTED] said the following: > Not sure why, but when I tried to submit a ticked for this it was > rejected repeatedly as suspected spam. If you register for a trac account it should avoid that issue. -- Collin Grady Academic politics is the most vicious and bitter form of politics, b

Re: DecimalField and 'decimal' module.

> "Curriculum" use psycopg1 or 2? > > seems like that was part of your point. > > Carl K Yeah I didn't mention this post that *now* Curriculum is using psycopg2 and Santa Cruz is using psycopg1, with no apparent problems (sorry, I did mention it earlier but forgot to clarify). But as Graham says,

Re: DecimalField and 'decimal' module.

oggie rob wrote: > - Application "Santa Cruz" built with 0.91 using psycopg1. Running > for just under a couple of years and accessed regularly. > - Application "Curriculum" built with trunk using psycopg1. Added > about 2 weeks ago & accessed infrequently. > Are you sure this would happen? If

Re: DecimalField and 'decimal' module.

On Jul 24, 12:15 pm, oggie rob <[EMAIL PROTECTED]> wrote: > > One problem that could arise is if, even in different sub interpreters, > > two Django instances separately tried to use version 1 and 2 of pyscopg. > > This is because the Python wrappers for one wouldn't match the loaded > > C extensi

Re: DecimalField and 'decimal' module.

> Hmmm, I'm not sure how psycopg1 in isolation could be a cause of > problems as it doesn't anywhere in its source code support the new > 'decimal.Decimal' type. Thus, the exact same problem as identified so > far with pyscopg2 couldn't be what was being encountered with > psycopg1. I'm sorry, I

Re: DecimalField and 'decimal' module.

On Jul 24, 12:26 am, oggie rob <[EMAIL PROTECTED]> wrote: > > > does this also affect psycopg1? > > > Looking at psycopg1 code, the answer would appear to be that it is not > > affected. Changes to support Decimal appear to be psycopg2 specific. > > > Graham > > The problems I was seeing the other

Re: DecimalField and 'decimal' module.

> are you sure this is the same issue? > > from what i saw in the tickethttp://www.initd.org/tracker/psycopg/ticket/192, > > it seems that it can fail even when both sub-interpreters run the same > version of python/django... > > gabor Sorry, gabor I didn't see this earlier. Yes, I'm pretty certa

Re: DecimalField and 'decimal' module.

> The recommendation I would make for now is that applications using new > Django builds should use psycopg2 and applications using older builds > should use psycopg1. This way there are two executables that don't > clash in any way. I have done this myself and it eliminated all the > problems I h

Re: DecimalField and 'decimal' module.

oggie rob wrote: >>> does this also affect psycopg1? >> Looking at psycopg1 code, the answer would appear to be that it is not >> affected. Changes to support Decimal appear to be psycopg2 specific. >> >> Graham > > The problems I was seeing the other day were repeatable both using > strictly psy

Re: DecimalField and 'decimal' module.

> > does this also affect psycopg1? > > Looking at psycopg1 code, the answer would appear to be that it is not > affected. Changes to support Decimal appear to be psycopg2 specific. > > Graham The problems I was seeing the other day were repeatable both using strictly psycopg1 (in fact, that was

Re: DecimalField and 'decimal' module.

On Jul 23, 7:33 pm, Gábor Farkas <[EMAIL PROTECTED]> wrote: > Graham Dumpleton wrote: > > > The reason I am asking is that there were recently problems found with > > pyscopg2 module and its support for use of decimal.Decimal type. In > > practice this only affects people who use mod_python or mod

Re: DecimalField and 'decimal' module.

Graham Dumpleton wrote: > > The reason I am asking is that there were recently problems found with > pyscopg2 module and its support for use of decimal.Decimal type. In > practice this only affects people who use mod_python or mod_wsgi and > run two different Django application instances in two d

Re: DecimalField and 'decimal' module.

On Jul 23, 5:03 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On 7/23/07, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > > > > > Rather obscure question here. I noted a comment over on the user list > > about SVN version of Django supporting a DecimalField database type. > > What is the re

Re: DecimalField and 'decimal' module.

On 7/23/07, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > > Rather obscure question here. I noted a comment over on the user list > about SVN version of Django supporting a DecimalField database type. > What is the relationship between this database field type and any > particular database adapter

Re: DecimalField

Jacob Kaplan-Moss wrote: > On 10/26/06 2:49 AM, Christopher Lenz wrote: > > Oh come on, just let Python 2.3 users install the decimal module from > > SF: > > > > > group_id=104148&package_id=130611&release_id=291663> > > > > I'd also suggest keep

Re: DecimalField

On 10/26/06 2:49 AM, Christopher Lenz wrote: > Oh come on, just let Python 2.3 users install the decimal module from > SF: > > group_id=104148&package_id=130611&release_id=291663> > > I'd also suggest keeping FloatField as it is (i.e. half-b

Re: DecimalField

Am 25.10.2006 um 00:25 schrieb Jason Davies: > I am working on an application which deals with monetary values and it > *really* needs proper support for decimal, fixed-point (as opposed to > floating-point) values. > > See: http://code.djangoproject.com/ticket/2365 > > Could someone take a look a

Re: DecimalField

On 10/25/06 4:52 PM, Jason Davies wrote: > It's definitely GPL-compatible (see > http://www.python.org/doc/Copyright.html) - but I don't think that > necessarily means it's compatible with Django's license. I am not a > lawyer :-( Nor am I, but figuring out the legality of distributing decimal.p

Re: Re: DecimalField

On 10/25/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > On 10/24/06 5:25 PM, Jason Davies wrote: > > I think we should just distribute decimal.py to maintain Python 2.3 > > compatibility. > > I'm +1 on the patch if someone can resolve two things: > > * Is the license for decimal.py compatibl

Re: Re: DecimalField

On 10/25/06, Jason Davies <[EMAIL PROTECTED]> wrote: > It's definitely GPL-compatible (see > http://www.python.org/doc/Copyright.html) - but I don't think that > necessarily means it's compatible with Django's license. I am not a > lawyer :-( Django is BSD-licensed. -- "May the forces of evil

Re: DecimalField

Jacob Kaplan-Moss wrote: > On 10/24/06 5:25 PM, Jason Davies wrote: > > I think we should just distribute decimal.py to maintain Python 2.3 > > compatibility. > > I'm +1 on the patch if someone can resolve two things: > > * Is the license for decimal.py compatible with Django's BSD license? It's

Re: DecimalField

On 10/24/06 5:25 PM, Jason Davies wrote: > I think we should just distribute decimal.py to maintain Python 2.3 > compatibility. I'm +1 on the patch if someone can resolve two things: * Is the license for decimal.py compatible with Django's BSD license? * Are the developers of decimal.py (is tha

Re: DecimalField

Jason Davies schrieb: > Hi, > > I am working on an application which deals with monetary values and it > *really* needs proper support for decimal, fixed-point (as opposed to > floating-point) values. > > See: http://code.djangoproject.com/ticket/2365 > > Could someone take a look and get this