Re: UniqueConstraint validation error message conditional vs non-conditional

[Othniel Davidson]

nice one there

On Sun, Sep 11, 2022 at 3:36 PM David Sanders 
wrote:

> Hi folks (and in particular Simon Charette),
>
> I had a bit of a gotcha moment when a custom unique constraint validation
> message disappeared when I added a condition to it. I won't raise a ticket
> for this because it looks intentional from the constraint validation PR,
> but I wanted to seek clarification and whether either some adjustment to
> the behaviour could be made or clarification in the docs.
>
> Here's a boiled down example:
>
> Validating models with UniqueConstraint usually groups errors by field
> name:
>
> class Test(Model):
> test = CharField(max_length=255)
>
> class Meta:
> constraints = [
> UniqueConstraint(fields=["test"], name="unique"),
> ]
>
> Test.objects.create(test="abc")
> test = Test(test="abc")
> test.validate_constraints()
> django.core.exceptions.ValidationError: {'test': ['Test with this Test
> already exists.']}
>
> However if a condition is added to the UniqueConstraint the validation
> error is categorised as a non-field error:
>
> class Test(Model):
> test = CharField(max_length=255)
>
> class Meta:
> constraints = [
> UniqueConstraint(fields=["test"], name="unique",
> condition=~Q(test="")),
> ]
>
> Test.objects.create(test="abc")
> test = Test(test="abc")
> test.validate_constraints()
> django.core.exceptions.ValidationError: {'__all__': ['Constraint “unique”
> is violated.']}
>
> This affects the way custom error messages are defined (eg forms
> error_messages dict vs constraint violation_error_message)
>
> This behaviour is defined in UniqueConstraint.validate() and looks to be
> intentional from this advice from Simon:
> https://github.com/django/django/pull/14625#issuecomment-897275721
>
> I was wondering what the rationale for that was? Would it be possible to
> make the behaviour consistent? And if not - would a PR to clarify how
> ValidationErrors are raised for constraints in the docs be welcomed?
>
> Cheers,
> David
>
> --
> 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/CADyZw-5w94wvx26OVdSaDHGjKxRGvdnCZYeMOM-p4J9t9JUqMw%40mail.gmail.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/CAPRrvgzm5O110ZRLD9B6YO-kF%2B61tCEmBc-E0z02pCKbeaGJcg%40mail.gmail.com.

Re: Proposal to upgrade django.core.mail to Python's modern email API

[Othniel Davidson]

Thank you for the update

On Sat, Jul 20, 2024 at 15:26 Pankaj Kumar  wrote:

> Hi Sir,
>I hope this message finds you well.
>
> I am writing to inform you that we have reviewed and decided to accept the
> proposal to upgrade django.core.mail to Python's modern email API. We
> believe that this upgrade will bring significant improvements to our
> system's performance and maintainability.
>
> I would also like to extend my sincere apologies for the delay in our
> response. I received the proposal seven days ago, and I regret not being
> able to get back to you sooner. Thank you for your patience and
> understanding in this matter.
>
> We are looking forward to the successful implementation of this upgrade
> and are excited about the enhancements it will bring to our project. Please
> let us know the next steps and how we can assist in the process.
>
> Thank you once again for your proposal and for your continued support.
>
> Best regards,
>
> - PANKAJ NEEMA
>
>
>
> On Sat, 6 Jul 2024 at 04:00, Mike Edmunds  wrote:
>
>> On Friday, June 28, 2024 at 1:07:35 PM UTC-7 Florian Apolloner wrote:
>> > Are all of those documented? If not we can simply remove them
>> (especially if the deprecation implementation turns out to be a PITA).
>>
>> It sort of depends on the definition of "documented." I've dug into
>> real-world usage; results and proposals below.
>>
>> Incidentally, I thought there was (used to be?) a policy that internal
>> undocumented APIs were fair game for use by third-party libraries,
>> subclassing, etc., so long as they didn't start with an underscore. (But
>> "private" underscore APIs could have breaking changes at any time.) Am I
>> remembering that wrong? Or was internal API stability only guaranteed for
>> patch-level releases?
>>
>> *Should go through deprecation process* (in my opinion, sorted roughly
>> by real-world usage)
>>
>>- *BadHeaderError* is mentioned in the docs
>>
>> 
>>  as
>>potentially raised during sending
>>   - Exposed in django.core.mail.__all__
>>   - Real-world use: ~2300+ cases in GitHub code search
>>   
>> ,
>>   seems to be primarily error handling
>>   
>> 
>>   - Proposal: deprecate on import. (Modern Python email API raises
>>   ValueError for newlines in headers. In our deprecation, we'll need
>>   `BadHeaderError = ValueError`—rather than subclassing ValueError—to
>>   preserve behavior of existing error handling code.)
>>   - Suggested replacement for docs: change `except BadHeaderError`
>>   to `except ValueError`
>>
>>   - *sanitize_address()* is not documented, but is widely used
>>   - Not exposed in django.core.mail (have to import from
>>   django.core.mail.message)
>>   - Real-world use: ~430 cases in GitHub code search
>>   
>> ,
>>   often in custom EmailBackend implementations
>>   
>> 
>>  or
>>   for special case handling
>>   
>> 
>>  that
>>   needs knowledge of how django.core.mail handles addresses.
>>   - Proposal: deprecate. (Have to keep implementation around anyway
>>   as part of other deprecated code.)
>>   - Suggested replacement for docs: none (it's an internal,
>>   undocumented API). Or we could say it depends on the use case: just 
>> skip it
>>   if no longer relevant, use something like Python's modern email Address
>>   object if you need formatting cleanup, or copy sanitize_address() into 
>> your
>>   code and adapt for your needs. (Incidentally, it's already pretty
>>   common to copy
>>   
>> 
>>   and adapt sanitize_address().)
>>
>>   - *SafeMIMEText* and *SafeMIMEMultipart* are mentioned in the docs
>>
>> 
>>as the return type of EmailMessage.message(), but not further documented
>>   - Exposed in django.core.mail.__all__
>>