Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

2022-06-28 Thread Dave Gaeddert
> To begin with - thats the place I dont like .get() at all. The fact that
> it might end up with multiple objects is a nuisance, but we cannot do
> much about it for API compat reasons
> ...

For what it's worth, I agree with what you're saying here too. Having a 
`unique_or_none` (and maybe `unique`) with that field checking could be 
cool, but in the interest of actually getting a change into Django, I 
assume `get_or_none` without that behavior is a much easier place to start.

On Sunday, June 26, 2022 at 2:07:34 PM UTC-5 j.bre...@netzkolchose.de wrote:

> Well from my own habits to use .get() only for unique filtering (>80% on 
> pks only) I also see some benefit of a .get_or_none() variant - it would 
> stop writing those exception handler wrappers over and over halfway 
> during project realization. A ready-to-go official way would reduce that 
> to a conditional expression from line one on.
>
> > .get_or_none() probably should allow to query only pks and
> > unique_together fields, so there will be no third state?
>
> To begin with - thats the place I dont like .get() at all. The fact that 
> it might end up with multiple objects is a nuisance, but we cannot do 
> much about it for API compat reasons. Idea - if we want such a changed 
> behavior - maybe call it "unique_or_none()" to make the difference 
> clear? If its called .get_or_none() imho it is better to stick to .get() 
> behavior regarding multiple objects (still raising).
>

-- 
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/b630d7a0-d832-41d0-985b-a7ae7ac1f1b6n%40googlegroups.com.


Re: (Circa end of 2021) Localization issues with input type=date?

2022-06-28 Thread Denny Biasiolli
Hi everyone,

I just arrived on this topic searching for ideas about improving the admin 
datetime format.
I noticed that datetime values are passed between to/from the admin form 
using the format defined in settings, but as you mentioned, this could be a 
problem when users from different timezones are using the admin interface.

I'd like to contribute to this, and I can suggest to use an iso format 
(used in input type "date", "datetime-local" and "time") to pass data, so 
all formatting problems can be avoided.

My idea was to change the `localize_input` function to return 
`value.isoformat()` when `isinstance(value, (datetime.datetime, 
datetime.date, datetime.time))`.
After this we can customize the attrs of `AdminDateWidget`, 
`AdminTimeWidget` (and eventually add a `AdminDateTimeWidget`)
passing the correct input type (`date`, `time` or `datetime-local`).

Any other idea?
On Tuesday, October 12, 2021 at 3:22:41 PM UTC+2 carlton...@gmail.com wrote:

> Thank you all, yes — there's some good points there. (Some others raised 
> on the PR and the ticket too.) 
>
> It's looks like there are still some caveats, and describing those 
> succinctly remains to do. 
> 👍
>
> Kind Regards,
>
> Carlton
>
>
> On Wednesday, 29 September 2021 at 21:13:51 UTC+2 Tobias Bengfort wrote:
>
>> > Back then there were various issues with localisation when **not** 
>> using type=text. 
>>
>> As https://code.djangoproject.com/ticket/16630#comment:11 states: the 
>> inputs only accept a special format. To make it work I had to explicitly 
>> set the format: `DateInput(format='%Y-%m-%d', attrs={'type': 'date'}`. 
>>
>> Another thing to be aware of: The native date picker UI uses the 
>> system/browser locale, not the one that is used on the page. (See also 
>> https://bugs.chromium.org/p/chromium/issues/detail?id=263320) 
>>
>> Hope that helps 
>>
>> tobias 
>>
>

-- 
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/f5112c37-13f5-49c9-a7d3-69e15d311e32n%40googlegroups.com.