>
> I think the conclusion should be to ask for a change in Python, not
> Django. The rule "if an exception is raised explicitly from an except
> clause then it is considered raised-from" seems simple enough to me.
>
I really like that. It makes perfect sense, and I can't think of a case
where
On Thu, 6 Feb 2020 20:08:28 +0200
Ram Rachum wrote:
>
> If I understand correctly, you both agree that using "raise from" in
> this context is better than using plain raise, just that the benefits
> are not worth the price of a bulk update to Django. In other words,
> "raise from" is the
Hello Ram,
> On 6 Feb 2020, at 19:08, Ram Rachum wrote:
>
> In other words, "raise from" is the inevitable future, it's just that we're
> not in a rush to get there.
I'm not sure how you came to this conclusion; I'm not seeing this in Carlton's
and Mariusz' answers.
Carlton only said that
Hi guys,
I'm disappointed that you're against this change... But I understand that
you have a different perspective. Here's my last-ditch effort to convince
you.
If I understand correctly, you both agree that using "raise from" in this
context is better than using plain raise, just that the
The reason it behaves differently to jsonfield and jsonfield2 is that it
does not use the built-in django.core.serializers.json.DjangoJSONEncoder.
Therefore serializing Decimal fields fails.
In my opinion the basic types, such as Decimal and Date/Time fields shall
be serializable to JSON, but
I agree with Carlton, I don't see much (if any) value in the bulk update.
Best,
Mariusz
--
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,
> +1 on chaining exceptions. I think the information is useful.
Absolutely. But exceptions are **already** chained, regardless of whether
we
use the `from` syntax.
Without the from clause exceptions are "implicitly" chained. With the from
claus it's "explicit".
Just the same tracebacks are
Hi.
Auth is a long way from the ORM. :) I guess first make sure you understand
contrib.auth. Maybe look at some auth tickets.
https://code.djangoproject.com/query?status=assigned=new=contrib.auth=id=summary=status=owner=type=component=version=1=id
Then for 2fa, there's not a concrete proposal
Hey everyone,
As I was recommended in the django forum mentorship channel, I proceeded to
go through the codebase of django's orm layer. I was thinking of working on
two factor authentication for GSoC. Should I start work for this from right
now or should I resolve a few tickets first before
Thanks for your testing!
It's being passed through json.dumps to check it would be possible to store
it as JSON. Seems legitimate to me.
The other libraries default to an encoder that allows storage of Decimals,
whilst the new field doesn't. Since Decimals don't round-trip in JSON
(they're
Hi Vibhu
Thank you for your documentation improvements. There are certainly many
more bigger improvements that can be made. For similar small typo fixes in
the future, you can just directly submit a PR rather than do all the
paperwork of adding an issue.
Yes, "easy pickings" tickets get resolved
Hi Vibhu
Take a look at: https://code.djangoproject.com/ticket/29446
Create a venv. Install your checkout of Django (with `pip install -e
path/to/django`)
Create a test project with a simple template view.
Pass a callable that raises an error to the template.
See the debug view. It should show
12 matches
Mail list logo
