Re: ngettext_lazy and ngettext

[אורי]

Hi,

Did you see PR #12332?
https://github.com/django/django/pull/12332
אורי
u...@speedy.net


On Sat, Jan 11, 2020 at 3:38 AM Matemática A3K 
wrote:

> Trying to recap all the discussion done in the mailing list, Trac and
> Github:
>
> The problem that was originally reported in #30439 was about mixed plural
> forms in catalogs bundled with Django, which led to broken translations.
>
> Then, it added the not announced changes in the plural forms of locales,
> which led to break users' translations.
>
> These problems occur when catalogs gets updated in Django and users
> updates their version.
>
> Michal proposed not merging and doing catalogs look-ups per language,
> Claude proposed the "dict-merge" policy (have a dict of merged catalogs
> according to their plural forms), which is a variant of Michal's.
>
> The "dict-merge" policy have the problem of updates in the plural forms in
> Django won't reach users' catalogs.
>
> Whether merge or not merge the catalogs (the merging policy) is about how
> to encourage the user to take action, not the fix itself.
>
> The fix is on the warning of the situation and on the tools for addressing
> it.
>
> The proposed fix is:
> 1- Warn the user at a system check level and at run-time
> 2- Use the "not-merge" policy to encourage action.
> 3- Provide the makemessages --comply-plural-forms tool so both Django and
> its users can have consistent plural forms in their catalogs conveniently.
> 4- Provide the LOCALE_ROOT setting and the makemessages
> --collect-base-catalogs tool so users can make changes in their plural
> forms conveniently and persisted across updates.
>
> The PR is cluttered with a lot of inconsistencies fixes across all
> catalogs bundled with Django and the catalogs used for tests.
>
> Once a warning is raised when merging (either merging or not), most of the
> tests will fail because of that warning, so all bundled catalogs (and those
> used for tests) have to be aligned in order to have things working.
>
> Here are the files of the PR filtered:
> https://github.com/django/django/pull/12280/files?file-filters%5B%5D=.py%5B%5D=.txt
>
> For ensuring Django's catalogs consistency, there is a test that will fail
> if there is any catalog unaligned. The next time Django's catalogs will be
> updated, CI will check the consistency. If not, who will do the merge has
> to run "python -m django makemessages --comply-plural-forms" and "python -m
> django compilemessages" on the corresponding dir (django.conf,
> django.contrib.app or the test locale) to fix it. This way, the messages
> from the provider will be retained and the consistency be assured.
>
> There are valid reasons for users to customize their plural forms, i.e.
> fixing a broken one while a fix is in the way or use another implementation
> of the standard. Having to modify the source distribution for customizing
> is not ideal, besides not being persistent across updates and may not be
> possible in some setups. This should be done locally, at the project tree.
> This is what the LOCALE_ROOT setting addresses.
>
> Claude already objected this fix though he did not provide reasons (
> https://github.com/django/django/pull/12280#issuecomment-571483273).
>
> Does anyone see any rationale, design or implementation problem in the
> fix? Any comment is welcomed :)
>
> On Mon, Jan 6, 2020 at 4:17 PM Matemática A3K 
> wrote:
>
>>
>>
>> On Fri, Dec 13, 2019 at 1:04 AM Matemática A3K 
>> wrote:
>>
>>>
>>>
>>> On Fri, Dec 6, 2019 at 2:14 AM Matemática A3K 
>>> wrote:
>>>


 On Thu, Dec 5, 2019 at 4:23 PM Maciek Olko 
 wrote:

> Hi,
> I am wondering if Django shouldn't use Unicode Plural Rules as
> standard and promote it for third-party apps. Even if sometimes number of
> forms are not applicable to certain cases, there may be cases when all of
> forms will be needed.
>

 I agree for Django, for third-party translations, for what I understood
 (CIIW) this may be a differentiator

>>>
>>> Under this rationale, this would be the fix:
>>>
>>> .. _plural-forms:
>>>
>>> Plural Forms
>>> 
>>>
>>> Django does not support multiple plural forms in catalogs. As all
>>> translation
>>> catalogs are merged, only the plural form in the main Django po file
>>> (located in
>>> ``django/conf/locale//LC_MESSAGES/django.po``) is considered.
>>>
>>> Plural forms in all other po files are ignored by the GNU gettext
>>> merging process.
>>>
>>> Therefore, you shouldn't use different plural forms in your project or
>>> application
>>> po files, as it may lead to unexpected results.
>>>
>>> To prevent inconsistencies and undesired behaviors in translations,
>>> Django will
>>> not merge any catalog that contains a different plural form than the
>>> main one
>>> and will issue a warning about the conflicting catalog.
>>>
>>> This conflict may arise mostly in two situations:
>>>
>>> * when the main plural form for a language is updated
>>> in Django and your po 

Re: Django 3.0 Release Notes - ASGI

[Josh Smeaton]

Sorry to resurrect this thread, and to ask and not do, but there have been 
a few questions on this ML about async support, and I imagine there'd be a 
few over on django-users too.

I've created https://code.djangoproject.com/ticket/31182#ticket to track 
this. 

On Tuesday, 15 October 2019 15:15:46 UTC+11, Andrew Godwin wrote:
>
> I agree - we need to communicate that ASGI support does *not *mean you 
> can start writing async def views. I think we should put a big disclaimer 
> to that effect next to it in the release notes and say it should be coming 
> next release.
>
> Andrew
>
> On Mon, Oct 14, 2019 at 5:45 PM Josh Smeaton  > wrote:
>
>> A co-worker just linked me to 
>> https://docs.djangoproject.com/en/dev/releases/3.0/#asgi-support and 
>> asked me (basically) if we can start doing all kinds of async work in one 
>> of our projects. Unfortunately, I didn't really know how to answer.
>>
>> Preface: I haven't followed the ASGI plan very closely (I read the DEP 
>> and have a vague understanding of the vision).
>>
>> It's my understanding that there's only very limited support for ASGI, 
>> and most features of Django won't work properly when running under ASGI. 
>> But that's not clear from reading the release notes or the deploy on ASGI 
>> section of the docs. Should we have a section in the docs that show what is 
>> and is not supported, along with examples?
>>
>> It'd be good to have a spot in the docs to point to that shows what is in 
>> and out of scope for each milestone.
>>
>> Thoughts?
>>
>> -- 
>> 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-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/9b11ecd8-997f-4edc-a627-5523da611a55%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/a79be729-972d-4511-949b-64b3e774d5fc%40googlegroups.com.

Re: Admin: Making raw_id fields navigable for readonly users

[Julien Rebetez]

Thanks for the quick response !

> The link should only be rendered if the user has permission to view the 
> target model.

Right, didn't think about that. Will do

> Perhaps a stupid question, but — wouldn't this apply to non-raw_id, readonly 
> foreign keys as well? I don't think they're rendered as links, are they?

Indeed, they aren't rendered as links either. I'll apply it to both then.

I've opened a ticket and will continue documenting my progress there :
https://code.djangoproject.com/ticket/31181

On Sat, Jan 18, 2020 at 7:35 PM Aymeric Augustin
 wrote:
>
> Hello Julien,
>
> This would be a nice UX improvement. The link should only be rendered if the 
> user has permission to view the target model.
>
> Perhaps a stupid question, but — wouldn't this apply to non-raw_id, readonly 
> foreign keys as well? I don't think they're rendered as links, are they?
>
> Best regards,
>
> --
> Aymeric.
>
>
>
> On 18 Jan 2020, at 19:18, Julien Rebetez  wrote:
>
> Hello,
>
> When viewing a model with raw_id fields in the admin UI, if you only have 
> view permission, then those fields are not rendered as links (you cannot go 
> to the related model) - they are just plaintext.
>
> I that something that you would agree to change ? That would be helpful for 
> us at work as we have quite a few raw_id fields and have readonly users as 
> well.
>
> I have a working patch for this - just need to clean it up & add tests. So if 
> it's a welcome change, I'll go ahead and do a PR.
>
> Thanks
> Julien
>
> --
> 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/9c38e6ad-d663-429b-a10b-5d8ce2906810%40googlegroups.com.
>
>
> --
> You received this message because you are subscribed to a topic in the Google 
> Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/django-developers/XFoaohDpqZE/unsubscribe.
> To unsubscribe from this group and all its topics, 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/FCDEAC08-D76E-4800-A8F4-1F537EC7D956%40polytechnique.org.

-- 
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/CAMYZvB%2BLTE0xnztcGS2DVOi0YKiuKu3KOj_e-sA7vt6FRCmMFQ%40mail.gmail.com.

Re: Admin: Making raw_id fields navigable for readonly users

[Aymeric Augustin]

Hello Julien,

This would be a nice UX improvement. The link should only be rendered if the 
user has permission to view the target model.

Perhaps a stupid question, but — wouldn't this apply to non-raw_id, readonly 
foreign keys as well? I don't think they're rendered as links, are they?

Best regards,

-- 
Aymeric.



> On 18 Jan 2020, at 19:18, Julien Rebetez  wrote:
> 
> Hello,
> 
> When viewing a model with raw_id fields in the admin UI, if you only have 
> view permission, then those fields are not rendered as links (you cannot go 
> to the related model) - they are just plaintext.
> 
> I that something that you would agree to change ? That would be helpful for 
> us at work as we have quite a few raw_id fields and have readonly users as 
> well.
> 
> I have a working patch for this - just need to clean it up & add tests. So if 
> it's a welcome change, I'll go ahead and do a PR.
> 
> Thanks
> Julien
> 
> -- 
> 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/9c38e6ad-d663-429b-a10b-5d8ce2906810%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/FCDEAC08-D76E-4800-A8F4-1F537EC7D956%40polytechnique.org.

Admin: Making raw_id fields navigable for readonly users

[Julien Rebetez]

Hello,

When viewing a model with raw_id fields in the admin UI, if you only have 
view permission, then those fields are not rendered as links (you cannot go 
to the related model) - they are just plaintext.

I that something that you would agree to change ? That would be helpful for 
us at work as we have quite a few raw_id fields and have readonly users as 
well.

I have a working patch for this - just need to clean it up & add tests. So 
if it's a welcome change, I'll go ahead and do a PR.

Thanks
Julien

-- 
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/9c38e6ad-d663-429b-a10b-5d8ce2906810%40googlegroups.com.

Automatically discovering AppConfig subclasses

[Aymeric Augustin]

Hello,

Since the app-loading refactor in Django 1.7, we recommend referencing 
AppConfig classes in INSTALLED_APPS e.g. 
"django.contrib.admin.apps.AdminConfig".

I don't think this style gained a lot of traction compared to the legacy, 
shorter style e.g. "django.contrib.admin". As a consequence, most apps define a 
`default_app_config` , which is an ugly hack for backwards-compatibility.

I think we should stop fighting the community, embrace the shorter style, and 
deprecate `default_app_config`. A  pull request doing all this is here: 
https://github.com/django/django/pull/12310 
. The rationale is explained with 
more details in the PR comments and the docs changes.

This was briefly discussed in the recent "GDAPS" thread. I'm starting a new 
thread to make sure this doesn't fly under the radar. Please let me know your 
thoughts!

Best regards,

-- 
Aymeric.



-- 
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/8F5547FD-0CE3-4B68-8492-7DDD70ADE9F0%40polytechnique.org.

Re: Use "raise from" where appropriate, all over the codebase

[Adam Johnson]

>
> I would like to make the point that chained exceptions might be slightly
> annoying when displayed via console output, as you see the inner exception
> first and have to scroll up to see the exception you actually have to
> handle.


Just coming back to this, Tom it's not quite true. Yes you see the "inner"
exception first - meaning the one raised inside the 'except' block. But
that is the one you, as a user, have to handle. This is not a concern for
me.

I checked with a simple program that Python prints them in the same order
and format whether or not "raise ... from" is used on the inner. The only
change is the message reads "The above exception was the direct cause of
the following exception:" which is pretty clear I think.

On Sat, 18 Jan 2020 at 15:18, Ram Rachum  wrote:

>
>
> On Sat, Jan 18, 2020 at 5:05 PM Shai Berger  wrote:
>
>> [snip]
>
> But as it turns out, `from` puts the
>> original exception on the `__cause__` in *addition* to `__context__`:
>>
>> [snip]
>> So that is not a concern.
>>
>
> Awesome! I did not know that.
>
>
>
>> > Regarding automatically enforcing this format going forward: I looked
>> > at the list of Flake8 rules  and
>> > couldn't find anything about it.
>> >
>>
>> Indeed, I don't think there can be -- it cannot be a style violation to
>> run into an error while handling another error...
>>
>
> I think it can be, as it's very rare to have a legitimate exception
> without a "raise from" inside an except clause. In almost any context in
> which "during handling of..." is correct, the raising is done deeper in the
> stack.
>
> I think it's rare enough that personally, I would have liked to have a
> Flake8 / PyLint rule like that enforces it, and allow ignoring it with a
> comment. (As much as I hate Lint ignore comments.)
>
> --
> 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/CANXboVYxb%2BMeOHp%3De4gzqroKWkHzLjeGXy55qJyRLQQVcUPrWg%40mail.gmail.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/CAMyDDM0%2BcpfiqFs3X9Kw9g%3D7444JahSjGBCa%2B2piSm71g_%3D12g%40mail.gmail.com.

Re: Use "raise from" where appropriate, all over the codebase

[Shai Berger]

On Sat, 18 Jan 2020 17:18:41 +0200
Ram Rachum  wrote:

> On Sat, Jan 18, 2020 at 5:05 PM Shai Berger  wrote:
> 
> > > Regarding automatically enforcing this format going forward: I
> > > looked at the list of Flake8 rules 
> > > and couldn't find anything about it.
> > >  
> >
> > Indeed, I don't think there can be -- it cannot be a style
> > violation to run into an error while handling another error...
> >  
> 
> I think it can be, as it's very rare to have a legitimate exception
> without a "raise from" inside an except clause. In almost any context
> in which "during handling of..." is correct, the raising is done
> deeper in the stack.
> 
> I think it's rare enough that personally, I would have liked to have a
> Flake8 / PyLint rule like that enforces it, and allow ignoring it
> with a comment. (As much as I hate Lint ignore comments.)

That makes sense. And you know, flake8 supports plugins... a couple of
web searches and "pip search flake8 | grep {raise,from,chain}" didn't
pull anything which seems relevant, but if so, it can be written.

Shai.

-- 
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/20200118174903.5d9b2247.shai%40platonix.com.

Re: Use "raise from" where appropriate, all over the codebase

[Jon Dufresne]

+1 on chaining exceptions. I think the information is useful.

> Is there anything we can do to control the way python displays them?

I don't think we should do anything non-standard to display exceptions.
Over time, Python programmers have become accustomed to how these
exceptions are displayed. To alter that would be to introduce something
unfamiliar from all their other Python debugging experiences.

If exception displaying should be improved, I think the effort should be
upstream to benefit the larger Python community.

> And how would we ensure the format is kept going forwards? Is there a
flake8 rule/plugin we could activate to enforce it?

At the very least, we could add a note in the code style guidelines that
chained exceptions should normally be used.

Cheers

-- 
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/CADhq2b41caYYAXS%3DypOs6wCQ%3D%2BcSE%3D53Uxk6ia4009ZOo8XiNA%40mail.gmail.com.

Re: Use "raise from" where appropriate, all over the codebase

[Ram Rachum]

On Sat, Jan 18, 2020 at 5:05 PM Shai Berger  wrote:

> [snip]

But as it turns out, `from` puts the
> original exception on the `__cause__` in *addition* to `__context__`:
>
> [snip]
> So that is not a concern.
>

Awesome! I did not know that.



> > Regarding automatically enforcing this format going forward: I looked
> > at the list of Flake8 rules  and
> > couldn't find anything about it.
> >
>
> Indeed, I don't think there can be -- it cannot be a style violation to
> run into an error while handling another error...
>

I think it can be, as it's very rare to have a legitimate exception without
a "raise from" inside an except clause. In almost any context in which
"during handling of..." is correct, the raising is done deeper in the stack.

I think it's rare enough that personally, I would have liked to have a
Flake8 / PyLint rule like that enforces it, and allow ignoring it with a
comment. (As much as I hate Lint ignore comments.)

-- 
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/CANXboVYxb%2BMeOHp%3De4gzqroKWkHzLjeGXy55qJyRLQQVcUPrWg%40mail.gmail.com.

Re: Use "raise from" where appropriate, all over the codebase

[Shai Berger]

Hi all,

On Sat, 18 Jan 2020 14:27:23 +0200
Ram Rachum  wrote:

> [...] In any case, the
> way Python chains exceptions when showing them is orthogonal to this
> proposed change. Python already displays the exceptions chained even
> if we don't use "raise from", the only thing that "raise from"
> changes is the text that Python puts between the 2 chained exceptions.
> 

Indeed. Well, almost: there is one more thing that addnig the `from`
changes, and that is the attributes on the exception (actually, it's
these attributes which really control the display): Without `from`, the
original exception is placed in a `__context__` attribute; with `from`,
it is placed in a `__cause__` attribute.

At first I thought this was a reason to object to this change -- I
thought code which catches exceptions and looks into their `__context__`
might break because of it. But as it turns out, `from` puts the
original exception on the `__cause__` in *addition* to `__context__`:

In [8]: try:
   ...: try:
   ...: 1/0
   ...: except ZeroDivisionError as e:
   ...: raise Exception("hi") from e
   ...: except Exception as ex:
   ...: exc = ex
   ...: 

In [10]: exc
Out[10]: Exception('hi')

In [13]: exc.__cause__ is exc.__context__
Out[13]: True

So that is not a concern.

> Regarding automatically enforcing this format going forward: I looked
> at the list of Flake8 rules  and
> couldn't find anything about it.
> 

Indeed, I don't think there can be -- it cannot be a style violation to
run into an error while handling another error...

Shai.

-- 
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/20200118170519.55c8f2e9.shai%40platonix.com.

Re: ngettext_lazy and ngettext

[אורי]

On Sat, Jan 11, 2020 at 3:38 AM Matemática A3K 
wrote:

> Does anyone see any rationale, design or implementation problem in the
> fix? Any comment is welcomed :)
>

https://github.com/django/django/pull/12280#issuecomment-575242878

We use Django 2.1 in Speedy Net and this issue has prevented us from
upgrading to Django 2.2. I'm trying to understand this PR but it seems to
me quite complicated. Will we be able to keep using 2 plural forms in
Hebrew for our translations if this PR is accepted? Or will we have to
convert our translations to 4 plural forms like is used in Django 2.2? For
me it makes sense to use 2 plural forms (n==1, n!=1) because we don't need
any complicated translations. I checked Django translations and
almost/maybe in 100% of the Hebrew translations, 3 plural forms are
identical. Do we have to convert our translations to 4 plural forms too?
And if we want to keep using 2 plural forms in Hebrew, how do we do it
while still using the latest version of Django?

You can see my comments on #30439 and in the Django developers mailing list.

Uri
אורי

-- 
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/CABD5YeE9PyYEObL4Lscw%2BZGWZYQTVDg80%2BL3_C3e6AW_5%3DfLXw%40mail.gmail.com.

Re: Use "raise from" where appropriate, all over the codebase

[Ram Rachum]

Hi Uri,

All the files were edited manually by me. I used a crude regex to find the
relevant locations: "except .{3,100}raise"

I bet that there are a few cases that my regex didn't cover, but it
probably covered 90%, so we can first decide whether we want this change,
and later worry about the other 10%.

‪On Sat, Jan 18, 2020 at 2:37 PM ‫אורי‬‎  wrote:‬

> Ram,
>
> I noticed that 100 files changed in this commit. Did you edit each file
> manually before you committed, or was it some script doing it for you?
>
> If it was a script or program, can I see it?
>
> Uri.
> אורי
> u...@speedy.net
>
>
> On Sat, Jan 18, 2020 at 11:55 AM Ram Rachum  wrote:
>
>> Hi guys,
>>
>> I recently made a big ticket/PR to Django, and Shai Berger told me I
>> should first talk about it in this mailing list.
>>
>> This is the ticket: https://code.djangoproject.com/ticket/31177 and its
>> PR: https://github.com/django/django/pull/12339
>>
>> It's a generalization of this ticket that I opened and wrote a patch for
>> a few days ago: https://code.djangoproject.com/ticket/31166 It was
>> discussed and merged.
>>
>> Basically, I think that in any place where we catch an exception, and
>> then wrap it with our own exception for whatever reason, we should use the
>> "raise new_exception from old_exception" syntax rather than just "raise
>> new_exception".
>>
>> This means that when Python displays the stacktrace (and when we display
>> it in the debug page,) this will make it have a text of "this exception is
>> the direct result of" instead of "During handling of the above exception,
>> another exception occurred". This is more accurate, because the latter
>> basically means "there was an error in the process of error-handling,"
>> which is absolutely not the case for us, and could mislead a user.
>>
>> Note that we already started transitioning to "raise from", slowly:
>>  - Commit by Mariusz Felisiak:
>> https://github.com/django/django/commit/84dcd1624784c2239f96a97b3151145a85dfbbe3
>>  - Commit by Diederik van der Boor:
>> https://github.com/django/django/commit/25f21bd2376603c8e233a0a0e5a726a0fdfdd33e
>>  - Commit by Thomas Allison:
>> https://github.com/django/django/commit/3e8b7333904f1ab6aa18eeb508659256f3644816
>>
>> What do you think?
>>
>>
>> Thanks,
>> Ram.
>>
>> --
>> 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/25086cdc-24ab-4f0a-bdb9-9756551ac170%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/ibEOt3A9c2M/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/CABD5YeHpYTz06M4ywKKmGB8P%3DAhj6Sv3P7K7%3DjB%3DYpCz6wpxLQ%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/CANXboVaYugrK3V19GEK0BWmUDOFVsvpiwNDuWr9wKcswQGeQHg%40mail.gmail.com.

Re: Use "raise from" where appropriate, all over the codebase

[אורי]

Ram,

I noticed that 100 files changed in this commit. Did you edit each file
manually before you committed, or was it some script doing it for you?

If it was a script or program, can I see it?

Uri.
אורי
u...@speedy.net


On Sat, Jan 18, 2020 at 11:55 AM Ram Rachum  wrote:

> Hi guys,
>
> I recently made a big ticket/PR to Django, and Shai Berger told me I
> should first talk about it in this mailing list.
>
> This is the ticket: https://code.djangoproject.com/ticket/31177 and its
> PR: https://github.com/django/django/pull/12339
>
> It's a generalization of this ticket that I opened and wrote a patch for a
> few days ago: https://code.djangoproject.com/ticket/31166 It was
> discussed and merged.
>
> Basically, I think that in any place where we catch an exception, and then
> wrap it with our own exception for whatever reason, we should use the
> "raise new_exception from old_exception" syntax rather than just "raise
> new_exception".
>
> This means that when Python displays the stacktrace (and when we display
> it in the debug page,) this will make it have a text of "this exception is
> the direct result of" instead of "During handling of the above exception,
> another exception occurred". This is more accurate, because the latter
> basically means "there was an error in the process of error-handling,"
> which is absolutely not the case for us, and could mislead a user.
>
> Note that we already started transitioning to "raise from", slowly:
>  - Commit by Mariusz Felisiak:
> https://github.com/django/django/commit/84dcd1624784c2239f96a97b3151145a85dfbbe3
>  - Commit by Diederik van der Boor:
> https://github.com/django/django/commit/25f21bd2376603c8e233a0a0e5a726a0fdfdd33e
>  - Commit by Thomas Allison:
> https://github.com/django/django/commit/3e8b7333904f1ab6aa18eeb508659256f3644816
>
> What do you think?
>
>
> Thanks,
> Ram.
>
> --
> 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/25086cdc-24ab-4f0a-bdb9-9756551ac170%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/CABD5YeHpYTz06M4ywKKmGB8P%3DAhj6Sv3P7K7%3DjB%3DYpCz6wpxLQ%40mail.gmail.com.

Re: Use "raise from" where appropriate, all over the codebase

[Ram Rachum]

Hi Tom and Adam,

I do agree that Python's chained exceptions can be confusing. Of course,
when you really need that exception information to troubleshoot something,
it's an absolute godsend. In any case, the way Python chains exceptions
when showing them is orthogonal to this proposed change. Python already
displays the exceptions chained even if we don't use "raise from", the only
thing that "raise from" changes is the text that Python puts between the 2
chained exceptions.

Regarding automatically enforcing this format going forward: I looked at
the list of Flake8 rules  and couldn't find
anything about it.

On Sat, Jan 18, 2020 at 12:57 PM Adam Johnson  wrote:

> Agree with Tom here.
>
> Is there anything we can do to control the way python displays them?
>
> And how would we ensure the format is kept going forwards? Is there a
> flake8 rule/plugin we could activate to enforce it?
>
> On Sat, 18 Jan 2020 at 10:23, Tom Forbes  wrote:
>
>> I agree with this change from a correctness standpoint but I would like
>> to make the point that chained exceptions might be slightly annoying when
>> displayed via console output, as you see the inner exception first and have
>> to scroll up to see the exception you actually have to handle.
>>
>> Tom
>>
>> On 18 Jan 2020, at 09:55, Ram Rachum  wrote:
>>
>> 
>>
>> Hi guys,
>>
>> I recently made a big ticket/PR to Django, and Shai Berger told me I
>> should first talk about it in this mailing list.
>>
>> This is the ticket: https://code.djangoproject.com/ticket/31177 and its
>> PR: https://github.com/django/django/pull/12339
>>
>> It's a generalization of this ticket that I opened and wrote a patch for
>> a few days ago: https://code.djangoproject.com/ticket/31166 It was
>> discussed and merged.
>>
>> Basically, I think that in any place where we catch an exception, and
>> then wrap it with our own exception for whatever reason, we should use the
>> "raise new_exception from old_exception" syntax rather than just "raise
>> new_exception".
>>
>> This means that when Python displays the stacktrace (and when we display
>> it in the debug page,) this will make it have a text of "this exception is
>> the direct result of" instead of "During handling of the above exception,
>> another exception occurred". This is more accurate, because the latter
>> basically means "there was an error in the process of error-handling,"
>> which is absolutely not the case for us, and could mislead a user.
>>
>> Note that we already started transitioning to "raise from", slowly:
>>  - Commit by Mariusz Felisiak:
>> https://github.com/django/django/commit/84dcd1624784c2239f96a97b3151145a85dfbbe3
>>  - Commit by Diederik van der Boor:
>> https://github.com/django/django/commit/25f21bd2376603c8e233a0a0e5a726a0fdfdd33e
>>  - Commit by Thomas Allison:
>> https://github.com/django/django/commit/3e8b7333904f1ab6aa18eeb508659256f3644816
>>
>> What do you think?
>>
>>
>> Thanks,
>> Ram.
>>
>> --
>> 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/25086cdc-24ab-4f0a-bdb9-9756551ac170%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/74BA6A05-D971-47EF-A0B6-4EF1149E83E6%40tomforb.es
>> 
>> .
>>
> --
> Adam
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/ibEOt3A9c2M/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/CAMyDDM0x0L%2Ba_r_gGL80qL3eqwMS4OV3%3Du-Hc0Wj3N1ruyQfuA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  

Re: Use "raise from" where appropriate, all over the codebase

[Adam Johnson]

Agree with Tom here.

Is there anything we can do to control the way python displays them?

And how would we ensure the format is kept going forwards? Is there a
flake8 rule/plugin we could activate to enforce it?

On Sat, 18 Jan 2020 at 10:23, Tom Forbes  wrote:

> I agree with this change from a correctness standpoint but I would like to
> make the point that chained exceptions might be slightly annoying when
> displayed via console output, as you see the inner exception first and have
> to scroll up to see the exception you actually have to handle.
>
> Tom
>
> On 18 Jan 2020, at 09:55, Ram Rachum  wrote:
>
> 
>
> Hi guys,
>
> I recently made a big ticket/PR to Django, and Shai Berger told me I
> should first talk about it in this mailing list.
>
> This is the ticket: https://code.djangoproject.com/ticket/31177 and its
> PR: https://github.com/django/django/pull/12339
>
> It's a generalization of this ticket that I opened and wrote a patch for a
> few days ago: https://code.djangoproject.com/ticket/31166 It was
> discussed and merged.
>
> Basically, I think that in any place where we catch an exception, and then
> wrap it with our own exception for whatever reason, we should use the
> "raise new_exception from old_exception" syntax rather than just "raise
> new_exception".
>
> This means that when Python displays the stacktrace (and when we display
> it in the debug page,) this will make it have a text of "this exception is
> the direct result of" instead of "During handling of the above exception,
> another exception occurred". This is more accurate, because the latter
> basically means "there was an error in the process of error-handling,"
> which is absolutely not the case for us, and could mislead a user.
>
> Note that we already started transitioning to "raise from", slowly:
>  - Commit by Mariusz Felisiak:
> https://github.com/django/django/commit/84dcd1624784c2239f96a97b3151145a85dfbbe3
>  - Commit by Diederik van der Boor:
> https://github.com/django/django/commit/25f21bd2376603c8e233a0a0e5a726a0fdfdd33e
>  - Commit by Thomas Allison:
> https://github.com/django/django/commit/3e8b7333904f1ab6aa18eeb508659256f3644816
>
> What do you think?
>
>
> Thanks,
> Ram.
>
> --
> 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/25086cdc-24ab-4f0a-bdb9-9756551ac170%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/74BA6A05-D971-47EF-A0B6-4EF1149E83E6%40tomforb.es
> 
> .
>
-- 
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/CAMyDDM0x0L%2Ba_r_gGL80qL3eqwMS4OV3%3Du-Hc0Wj3N1ruyQfuA%40mail.gmail.com.

Re: Use "raise from" where appropriate, all over the codebase

[Tom Forbes]

I agree with this change from a correctness standpoint but I would like to make 
the point that chained exceptions might be slightly annoying when displayed via 
console output, as you see the inner exception first and have to scroll up to 
see the exception you actually have to handle.

Tom

> On 18 Jan 2020, at 09:55, Ram Rachum  wrote:
> 
> 
> Hi guys,
> 
> I recently made a big ticket/PR to Django, and Shai Berger told me I should 
> first talk about it in this mailing list.
> 
> This is the ticket: https://code.djangoproject.com/ticket/31177 and its PR: 
> https://github.com/django/django/pull/12339
> 
> It's a generalization of this ticket that I opened and wrote a patch for a 
> few days ago: https://code.djangoproject.com/ticket/31166 It was discussed 
> and merged.
> 
> Basically, I think that in any place where we catch an exception, and then 
> wrap it with our own exception for whatever reason, we should use the "raise 
> new_exception from old_exception" syntax rather than just "raise 
> new_exception".
> 
> This means that when Python displays the stacktrace (and when we display it 
> in the debug page,) this will make it have a text of "this exception is the 
> direct result of" instead of "During handling of the above exception, another 
> exception occurred". This is more accurate, because the latter basically 
> means "there was an error in the process of error-handling," which is 
> absolutely not the case for us, and could mislead a user.
> 
> Note that we already started transitioning to "raise from", slowly:
>  - Commit by Mariusz Felisiak: 
> https://github.com/django/django/commit/84dcd1624784c2239f96a97b3151145a85dfbbe3
>  - Commit by Diederik van der Boor: 
> https://github.com/django/django/commit/25f21bd2376603c8e233a0a0e5a726a0fdfdd33e
>  - Commit by Thomas Allison: 
> https://github.com/django/django/commit/3e8b7333904f1ab6aa18eeb508659256f3644816
> 
> What do you think? 
> 
> 
> Thanks,
> Ram.
> -- 
> 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/25086cdc-24ab-4f0a-bdb9-9756551ac170%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/74BA6A05-D971-47EF-A0B6-4EF1149E83E6%40tomforb.es.

Use "raise from" where appropriate, all over the codebase

[Ram Rachum]

Hi guys,

I recently made a big ticket/PR to Django, and Shai Berger told me I should 
first talk about it in this mailing list.

This is the ticket: https://code.djangoproject.com/ticket/31177 and its PR: 
https://github.com/django/django/pull/12339

It's a generalization of this ticket that I opened and wrote a patch for a 
few days ago: https://code.djangoproject.com/ticket/31166 It was discussed 
and merged.

Basically, I think that in any place where we catch an exception, and then 
wrap it with our own exception for whatever reason, we should use the 
"raise new_exception from old_exception" syntax rather than just "raise 
new_exception".

This means that when Python displays the stacktrace (and when we display it 
in the debug page,) this will make it have a text of "this exception is the 
direct result of" instead of "During handling of the above exception, 
another exception occurred". This is more accurate, because the latter 
basically means "there was an error in the process of error-handling," 
which is absolutely not the case for us, and could mislead a user.

Note that we already started transitioning to "raise from", slowly:
 - Commit by Mariusz Felisiak: 
https://github.com/django/django/commit/84dcd1624784c2239f96a97b3151145a85dfbbe3
 - Commit by Diederik van der Boor: 
https://github.com/django/django/commit/25f21bd2376603c8e233a0a0e5a726a0fdfdd33e
 - Commit by Thomas Allison: 
https://github.com/django/django/commit/3e8b7333904f1ab6aa18eeb508659256f3644816

What do you think? 


Thanks,
Ram.

-- 
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/25086cdc-24ab-4f0a-bdb9-9756551ac170%40googlegroups.com.