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 m

Re: Django 3.0 Release Notes - ASGI

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:

Re: Admin: Making raw_id fields navigable for readonly users

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 rendere

Re: Admin: Making raw_id fields navigable for readonly users

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 re

Admin: Making raw_id fields navigable for readonly users

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 a

Automatically discovering AppConfig subclasses

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,

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

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

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

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

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

+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.

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

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 go

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

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" > c

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 f

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

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 oth

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 recen

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

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. Pyth

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

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

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

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

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

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 ope