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

[Jacob Rief]

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 accepted I will assign myself to implement it.

– Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/061938e3-b44c-4a14-a343-fd8a6356fca2n%40googlegroups.com.

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

[Josh Smeaton]

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:

my_step_field = forms.FloatField(widget_attributes={"step": 0.5})

Rather than encode each kind of attribute in the form field constructor it 
could take a dictionary that is passed along to customise the widget. Often 
I've found it 
annoying to track down the exact widget required, find the import, and then 
customise the widget. The specific arguments to fill out the attributes are 
less onerous.

Thoughts?

On Wednesday, 17 March 2021 at 18:54:29 UTC+11 jacob...@gmail.com wrote:

> 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 accepted I will assign myself to implement it.
>
> – Jacob
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/67a32579-a119-4d54-b765-0e2dad850771n%40googlegroups.com.

Re: Query regarding Google Summer Of Code

[Muskan Vaswan]

Thank you so much, Ahmad. Heading your suggestion, I've put my question/ 
potential proposal up on the forum here 

.


On Wednesday, 17 March 2021 at 09:51:48 UTC+5:30 Ahmad A. Hussein wrote:

> Hello Muskan,
>
> "We're still going to be strict with what we accept - you'll need to 
> provide a *strong use case* for your idea and show that it would be *useful 
> to a majority of developers* or *significantly improve* the development 
> of Django itself."
>
> This is from the wiki page 
>  for GSoC 2021. So 
> I believe you could submit a GSoC proposal for UI/UX but your proposal 
> would need to greatly impact a sizable amount of developers.
>
> As for UI/UX fixes, I believe the process is the same as normal tickets: 
> you submit a ticket on the issue tracker, people review it and establish 
> consensus, and then you submit a patch following said consensus.
>
> If you're looking to get feedback on your proposal, submit it on the 
> forums  under Mentorship. Plenty of 
> people will take a look at it and will help you get on the right track.
>
> On Tue, Mar 16, 2021 at 7:50 PM Muskan Vaswan  wrote:
>
>> Hello again, I am Muskan and I have a few questions regarding GSoC 2021.
>>
>> Are contributions to django/djangoproject (the tickets trac) considered 
>> in GSoC. While the dashboard itself is mentioned on the wiki page I was 
>> wondering if it extends to the issue tracker itself to. If so, then would 
>> fixing UI/UX bugs (large enough) be considered a valid contribution to 
>> GSoC? 
>> Besides this, regardless of GSoc, what is the process of approval for 
>> UI/UX fixes in any of the django projects/sub-projects? Does this process 
>> stay the same in consideration of a GSoC proposal?
>>
>> Is there any mentor or such, that we as GSoC aspirants can get in tough 
>> with before the submissions of proposals so we can more more freely ask 
>> doubts specifically related to our potential proposals?
>>
>> -
>> Regards
>> Muskan Vaswan
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/f1bf29ea-f7ce-421d-8c3d-b3af9c6d89c8n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f088322d-a32d-4c0f-90ec-391dcd7df18bn%40googlegroups.com.

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

[Carlton Gibson]

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()), {'step': '0.01'})
f = DecimalField(max_digits=10, decimal_places=0)
self.assertEqual(f.widget_attrs(NumberInput()), {'step': '1'})
f = DecimalField(max_digits=19, decimal_places=19)
self.assertEqual(f.widget_attrs(NumberInput()), {'step': '1e-19'})
f = DecimalField(max_digits=20)
self.assertEqual(f.widget_attrs(NumberInput()), {'step': 'any'})
f = DecimalField(max_digits=6, widget=NumberInput(attrs={'step': 
'0.01'}))
self.assertWidgetRendersTo(f, '')

I’m not sure about extending it for FloatField:

> On 17 Mar 2021, at 12:35, Josh Smeaton  wrote:

> 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:

> my_step_field = forms.FloatField(widget_attributes={"step": 0.5})

> Thoughts?


In general, I think we should be very cautious about adding more API here. 

There’s already one clear way to do it, passing the widget. 

Adding (say) a widget_attributes is no clearer than the original: 

my_step_field = forms.FloatField(widget=NumberInput(attrs={'step': 0.5})).

Except now there are TWO ways of configuring one widget attribute. 

We set maxlength/minlength on widgets for CharFields because they map from an 
already existing kwarg. 

For the case of `step` on a FloatField we’d need to add a kwarg — but that’s 
only there to set a single attribute on the widget. 

In that case, I don’t think the explicit declaration is too much to ask. 

“But I need this for all my forms” — create a project-level field and 
declare it once there.

While not all attributes have custom kwargs on the field: 
"We can set THAT widget attribute from the field, why not THIS 
one?”

tl;dr: I sceptical this would be a good extension of the API surface area. 

C. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/483FD31B-347C-4A4A-BDEF-52B724795123%40gmail.com.

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

[Jacob Rief]

>
> We set maxlength/minlength on widgets for CharFields *because they map 
> from an already existing kwarg*. 
>
> For the case of `step` on a FloatField we’d need to add a kwarg — but 
> that’s only there to set a single attribute on the widget. 
>
> 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 consistent, the same should apply to the step value.
This would  furthermore allow the field 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 the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e1402ecc-fa2b-47a8-ba79-f2d7f7f98f27n%40googlegroups.com.

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

[Carlton Gibson]

> 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 consistent, the same should apply to the step value.
> This would  furthermore allow the field to validate against a multiple of 
> that step value. Such a feature currently has to be implemented on the 
> project level.

If we’re happy to add that extra to forms.FloatField then it would alleviate my 
concern about a pass-through parameter. (At least the field would be **doing** 
something with it.) 

(I don’t object if everyone is keen.) 
C.


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8A007E70-C106-4705-B33C-ED8269161546%40gmail.com.

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

['Adam Johnson' via Django developers (Contributions to Django itself)]

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
many ways of configuring form fields/widgets, we don't need another.

On Wed, 17 Mar 2021 at 14:43, Carlton Gibson 
wrote:

>
>
> 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 consistent, the same should apply to the step value.
> This would  furthermore allow the field to validate against a multiple of
> that step value. Such a feature currently has to be implemented on the
> project level.
>
>
> If we’re happy to add that extra to forms.FloatField then it would
> alleviate my concern about a pass-through parameter. (At least the field
> would be **doing** something with it.)
>
> (I don’t object if everyone is keen.)
> C.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/8A007E70-C106-4705-B33C-ED8269161546%40gmail.com
> 
> .
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM16qkuHG_KXQvhZVitWgiJugxZ-9053UacyUm7jVxULmQ%40mail.gmail.com.

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

[Jacob Rief]

Great News!
So please accept 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 
decimal_places).

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b4a920d6-024f-4181-aef8-52fed51d40f2n%40googlegroups.com.

Django's build: Try Earthly?

[Vlad A. Ionescu]

Hi Django devs,

Nick Pope directed me to this list. Wondering if anyone is interested in
trying https://github.com/earthly/earthly for Django's build.

Earthly could help with reproducing CI failures locally (via containers),
testing against multiple versions of Python in parallel, or for migrating
between CI vendors.

It works well on top of Jenkins and GH Actions.

Happy to put together a demo PR if this is of interest. Let me know!

Cheers,
Vlad.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAO_OUmM%2BMFU1nPMzFaEsGcD4rh6tFh-wQ3T_hK4GH5-4%2BCxgxQ%40mail.gmail.com.