Re: Proposal to add attribute 'step' to FloatField and DecimalField

I do something similar to what math.isclose() provides. Can anyone please review this PR:- https://github.com/django/django/pull/14162 On Mon, Mar 22, 2021, 4:53 PM James Bennett wrote: > There are ways to check "close enough" equality for floats. There's > even the math.isclose() function which

Re: Proposal to add attribute 'step' to FloatField and DecimalField

There are ways to check "close enough" equality for floats. There's even the math.isclose() function which is arbitrarily tune-able: https://docs.python.org/3/library/math.html#math.isclose -- You received this message because you are subscribed to the Google Groups "Django developers (Contrib

Re: Proposal to add attribute 'step' to FloatField and DecimalField

The problem with modulo on floats is, that due to rounding errors it often created weird results, for instance in Python-3.8 this happens: 3.5 % 0.1 = 0.09981 This btw. also applies to the builtin divmod and math.fmod functions. Therefore I proposed to do it via classic division and ch

Re: Proposal to add attribute 'step' to FloatField and DecimalField

Use the modulo operator In [1]: 4.5 % 1.5 Out[1]: 0.0 https://en.wikipedia.org/wiki/Modulo_operation https://docs.python.org/3/reference/expressions.html?highlight=modulo#binary-arithmetic-operations On Sun, 21 Mar 2021 at 23:47, Jacob Rief wrote: > Say, you have a value and step, both are flo

Re: Proposal to add attribute 'step' to FloatField and DecimalField

Say, you have a value and step, both are floats, then if value / step is can be represented integer, the validation is fulfilled. Otherwise if the result has to be rounded to become an integer, a ValidationError shall be raised. Be aware of rounding errors. On Sunday, March 21, 2021 at 9:53:43 P

Re: Proposal to add attribute 'step' to FloatField and DecimalField

: > Great News! > So please accept ticket #32559 > <https://code.djangoproject.com/ticket/32559>. I then will assign myself > to it and implement it. > So I add step (or would you prefer step_value?) to IntegerField and > FloatField, but not to DecimalField (because th

Re: Proposal to add attribute 'step' to FloatField and DecimalField

Great News! So please accept ticket #32559 <https://code.djangoproject.com/ticket/32559>. I then will assign myself to it and implement it. So I add step (or would you prefer step_value?) to IntegerField and FloatField, but not to DecimalField (because there it's handled through dec

Re: Proposal to add attribute 'step' to FloatField and DecimalField

I agree that it makes sense to add the argument to FloatField so we can add the server-side validation logic. I would also like to see it on IntegerField for consistency, and since IntegerField also maps to a NumberInput. I'd also be against the widget_attributes proposal - there are already too m

Re: Proposal to add attribute 'step' to FloatField and DecimalField

> On 17 Mar 2021, at 15:34, Jacob Rief wrote: > > But FloatField also offers a min_value and max_value. When rendered as a > widget, they are used as attributes min and max in their input > field. In addition to that, the field value is validated against a value in > that range. To be consist

Re: Proposal to add attribute 'step' to FloatField and DecimalField

ield to validate against a multiple of that step value. Such a feature currently has to be implemented on the project level. I agree with Carlton that in the DecimalField this is handled by the attribute decimal_places. – Jacob -- You received this message because you are subscribed to th

Re: Proposal to add attribute 'step' to FloatField and DecimalField

Hiya, DecimalField already sets step based on the number of decimal places def test_decimalfield_widget_attrs(self): f = DecimalField(max_digits=6, decimal_places=2) self.assertEqual(f.widget_attrs(Widget()), {}) self.assertEqual(f.widget_attrs(NumberInput

Re: Proposal to add attribute 'step' to FloatField and DecimalField

Just to clarify - you're talking about form fields rather than model fields, right? I can see the argument for form fields but not for model fields. Is there a better API we can think of for customising widgets from the field constructor that could then be passed through? As a rough example: m

Re: Proposal to add attribute 'step' to FloatField and DecimalField

On Wednesday, March 17, 2021 at 12:49:48 AM UTC+1 in...@markusholtermann.eu wrote: > That sounds like a sensible feature. Do you want to open a ticket and > maybe implement it? > Hi Markus, ticket #32559 has been issued to propose this feature. If

Re: Proposal to add attribute 'step' to FloatField and DecimalField

stance > FloatField(widget=NumberInput(attrs={'step': 0.5})). > > Since the HTML standard offers a step attribute on input fields of type > number, > from my point of view, this feature shall be reflected by Django's > FloatField and > optionally DecimalF

Proposal to add attribute 'step' to FloatField and DecimalField

ture shall be reflected by Django's FloatField and optionally DecimalField rather than having to parametrize the widget. Min- and max-values are already supported by the FloatField, so the step-value would make sense here as well. It furthermore would require to revalidate the step-value b

Re: Django 1.8 - django 1.7 differences to read DecimalField

; >> Hi, >> >> >> I'm the maintener of django-firebird database backend. >> >> I've an strange behavior (a different result) when reading a value from a >> DecimalField between Django 1.7 and Django 1.8 and I'm trying to figured >> ou

Re: Django 1.8 - django 1.7 differences to read DecimalField

I'm the maintener of django-firebird database backend. > > I've an strange behavior (a different result) when reading a value from a > DecimalField between Django 1.7 and Django 1.8 and I'm trying to figured > out where is my mistake. > > I've a django projec

Django 1.8 - django 1.7 differences to read DecimalField

Hi, I'm the maintener of django-firebird database backend. I've an strange behavior (a different result) when reading a value from a DecimalField between Django 1.7 and Django 1.8 and I'm trying to figured out where is my mistake. I've a django project which I update from

Re: Should DecimalField have special rounding to make float assignments match string assignments?

create_decimal_from_float > > (I don’t care much about Python 2 at this point. We should just make sure > we don’t introduce a debatable behavior in the last LTS release supporting > Python 2.) > > 3) Currently DecimalField accepts max_digits and decimal_places options. I > think it

Re: Should DecimalField have special rounding to make float assignments match string assignments?

. We should just make sure we > don’t introduce a debatable behavior in the last LTS release supporting > Python 2.) > > 3) Currently DecimalField accepts max_digits and decimal_places options. I > think it should accept a decimal context and delegate all operations to that

Re: Should DecimalField have special rounding to make float assignments match string assignments?

cs.python.org/3.5/library/decimal.html#decimal.Context.create_decimal_from_float (I don’t care much about Python 2 at this point. We should just make sure we don’t introduce a debatable behavior in the last LTS release supporting Python 2.) 3) Currently DecimalField accepts max_digits and decimal_places option

Re: Should DecimalField have special rounding to make float assignments match string assignments?

On 5 April 2016 at 14:49, Tim Graham wrote: > The default behavior of decimal rounding is ROUND_HALF_EVEN (to nearest with > ties going to nearest even integer). There's a proposal to change this to > cast floats to string and then use ROUND_HALF_UP to match the value of > strings [0][1]. Do you h

Should DecimalField have special rounding to make float assignments match string assignments?

If you assign a float with more decimal places than a DecimalField field supports to that field, the value may round differently than if you assign the same value as a string. For example: class Invoice(models.Model): gross = models.DecimalField(max_digits=10, decimal_places=1

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

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

DecimalField with no max_digits and decimal_places

Hi, Django's DecimalField requires both max_digits and decimal_places. Database backends allow them to be dropped, to specify an "unlimited precision" field. Adding support for this in Django is probably not very helpful for new apps, but can help significantly in using Django

Re: DecimalField model validation

he default rounding behaviour for `DecimalField`. Would it be considered backwards incompatible to change the default to ROUND_HALF_UP? If so, would it be easy enough to make it possible for users to easily change the default behaviour for a single field or even project-wide? I think rounding on

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

Re: DecimalField model validation

(mentally adding numbers) would, then I think the default behaviour is surprising to many users. I was certainly surprised when I first encountered it, not being familiar with Python's default of ROUND_HALF_EVEN. I don't see an easy way for users to change the default rounding behaviour for `De

Re: DecimalField model validation

ed to enter values with more decimal digits than expected, even if the value will be rounded. As a matter of fact forms.DecimalField does not know ronding. That said, a no_rounding kwarg sounds like a perfectly reasonable feature. ok, the kwarg will do (B) decimalfield shoud not validate val

Re: DecimalField model validation

out till you get the correct number). Since there's not a good way to make this the default value and retain backwards compatibility, this is unlikely to change. This behavior should be documented. That said, a no_rounding kwarg sounds like a perfectly reasonable feature. >  (B) decimalfield shoud

DecimalField model validation

ently before saving, if the value has too many decimal digits, raise an exception (just like for values that have too many digits) (B) decimalfield shoud not validate values that exceed its max_digits and decimal_places constraints (C) leave as is, but if you solve (A) and (B) it'

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.

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

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

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 Tra

DecimalField allows float value as 'default'.

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 'DecimalField default' and didn't see anywhere that this

Re: #5903 DecimalField returns default value as unicode string

On Wed, 2009-02-11 at 22:50 +0900, Russell Keith-Magee wrote: [...] > However, in this case, I'm reasonably convinced it is the right thing > to do. The list of 'ignored' types for force_unicode is essentially > the list of data types that we use for native data representations. I > can't think of

Re: #5903 DecimalField returns default value as unicode string

On Wed, Feb 11, 2009 at 9:06 AM, Brian Rosner wrote: > > Hey all, > > I recently came across the issue described in #5903 [1] earlier. There > are two distinct patches that fix the problem, but at different > levels. My inclination is to fix this issue at the model field level > and properly over

Re: #5903 DecimalField returns default value as unicode string

On Tue, Feb 10, 2009 at 7:10 PM, Alex Gaynor wrote: > > > On Tue, Feb 10, 2009 at 7:06 PM, Brian Rosner wrote: > >> >> Hey all, >> >> I recently came across the issue described in #5903 [1] earlier. There >> are two distinct patches that fix the problem, but at different >> levels. My inclinatio

Re: #5903 DecimalField returns default value as unicode string

On Tue, Feb 10, 2009 at 7:06 PM, Brian Rosner wrote: > > Hey all, > > I recently came across the issue described in #5903 [1] earlier. There > are two distinct patches that fix the problem, but at different > levels. My inclination is to fix this issue at the model field level > and properly over

#5903 DecimalField returns default value as unicode string

Hey all, I recently came across the issue described in #5903 [1] earlier. There are two distinct patches that fix the problem, but at different levels. My inclination is to fix this issue at the model field level and properly override get_default. My feeling is that allowing Decimal objects to pa

Re: surprise when initializing DecimalField with a string value

Jacob's comment on #django-dev: > that's been discussed ad-nauseum in the past. models don't > have __setattr__ hooks for speed, so you can say > "model.intfield = "Fish"" for all Django cares. > [...] it's a well-known problem, but one without a "good" fix. > I think model validation will prob

surprise when initializing DecimalField with a string value

According to the backwards incompatible changes wiki page: > you must either store a python decimal value in the model attribute or a > string (which will then be converted to a decimal) But what is "then" in "will then be converted"? It appears that the conversion doesn't take place when initi

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

DecimalField returns default value as unicode string.

Right now (unless I misread it) Django returns any non-callable default value using "force_unicode". This means that if you have a decimal field with a default value you have to save the model, and then retrieve it back from the database for that model to return the correct default value. I think

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.

ld is registered as a "double precision" type in the database. However, in 0.91, it is listed as a "numeric(%(max_digits)s, % (decimal_places)s)" - which translates into a DecimalField in the trunk version. So if I visit my Curriculum application, then go to Santa Cruz, I get th

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

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 >

DecimalField and 'decimal' module.

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 adapters ability to store or return values in some native database

Re: DecimalField

;release_id=291663> > > > > I'd also suggest keeping FloatField as it is (i.e. half-broken, > > depending on DB backend, or fix it to always return floats, but > > that's break backwards compatibility again), deprecate it, and > > introduce the new Deci

Re: DecimalField

t keeping FloatField as it is (i.e. half-broken, > depending on DB backend, or fix it to always return floats, but > that's break backwards compatibility again), deprecate it, and > introduce the new DecimalField. Only the use of DecimalField would > require the decimal.py mo

Re: DecimalField

p;package_id=130611&release_id=291663> I'd also suggest keeping FloatField as it is (i.e. half-broken, depending on DB backend, or fix it to always return floats, but that's break backwards compatibility again), deprecate it, and introduce the new DecimalField. Only the use

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

DecimalField

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 patch approved? I think we should just