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

[Ryan Hiebert]

>
> 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 that rule would be incorrect.

>

-- 
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/CABpHFHQwL8aGCA8k7aU10xuv6fJnrURu5cD9kv8b%2BWS52gqdEw%40mail.gmail.com.

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

[Shai Berger]

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 inevitable future, it's just that we're not in a
> rush to get there.

As Aymeric pointed out, that's inaccurate; If I understood correctly,
Carlton's argument amounted to "it would be better to have the string
produced by `raise from` in the output, but it's not worth the extra
verbosity in exception handling code" -- besides the price of the bulk
update.

> Keep in mind that the thing I care about is not just usage of "raise
> from" in Django, but in any Python package which is relevant.

... and Carlton's argument applies to them all; when also considering:

> On Sat, 18 Jan 2020 17:18:41 +0200
> Ram Rachum  wrote:
> 
> > 
> > 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 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.

-- 
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/20200207024841.368287f6.shai%40platonix.com.

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

[Aymeric Augustin]

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 `raise from` can be useful in specific cases where the 
default, implicit exception chaining doesn't do what you need.

> On 6 Feb 2020, at 15:37, Carlton Gibson  wrote:
> 
> Beyond that, the from syntax is simply more verbose. In the PR the changes 
> are 
> all adding a unneeded `as e`, followed by an equally unneeded `from e`. 


This wouldn't be an improvement.

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/5AF3A99A-4C6E-4919-BACB-7FFAE7C34FEC%40polytechnique.org.

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

[Ram Rachum]

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 benefits are not
worth the price of a bulk update to Django. In other words, "raise from" is
the inevitable future, it's just that we're not in a rush to get there.

Keep in mind that the thing I care about is not just usage of "raise from"
in Django, but in any Python package which is relevant. Most Python
developers don't know about this difference between "During the handling
of" and "The above exception was the direct cause", because "raise from"
isn't that prevalent yet. This is a chicken-and-egg problem, because as
long as project maintainers don't use "raise from", the exception chaining
wouldn't show the correct text, and people would get used to the fact that
they can't rely on this text to be correct.

Like any chicken-and-egg problem of changing people's habits, the best we
could hope is to move it forward at a glacial pace-- A situation somewhat
similar to the move to Python 3. If Django were to adopt this practice, it
would help in getting other projects to do that too, and for people to pay
attention to that line of text.


Thanks,
Ram.

On Thu, Feb 6, 2020 at 4:48 PM Mariusz Felisiak 
wrote:

> 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 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/ab6abbb0-f651-4271-b84c-a3bacaba9482%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/CANXboVaNK7YrWohu8jDcJCG3h43ngHqUqYOCxShV8W_O8rj8pw%40mail.gmail.com.

Re: CrossDB JSONField — Testing needed.

[Jacob Rief]

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 apparently there are different opinions out 
there.

-- 
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/cc2b0a3b-1567-4da6-ac01-857bb808c356%40googlegroups.com.

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

[Mariusz Felisiak]

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, 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/ab6abbb0-f651-4271-b84c-a3bacaba9482%40googlegroups.com.

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

[Carlton Gibson]

> +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 presented, in just the same order. 

The only difference is the string that divides them: 

```
The above exception was the direct cause of the following exception:
```

vs

```
During handling of the above exception, another exception occurred:
```

That change in string isn't worth 380+ changes over 100 files. 

* We're obscuring the history for nothing, and...
* Whilst I **think** there's no danger in this case, bulk edits are by 
their nature 
  unconsidered, and there is the ever-present risk of regression. 
  
Beyond that, the from syntax is simply more verbose. In the PR the changes 
are 
all adding a unneeded `as e`, followed by an equally unneeded `from e`. 

Looking at the diff, the comparison that comes to mind is if we went 
through 
and replaced all percent formatting with format()



So I'm -1 on merging the PR. I think we should close the ticket as wontfix. 

I would ask everyone to clarify exactly what they think the benefits of the 
proposed change are, and to follow-up if there's a hidden benefit I've 
missed. 


I'm not anti the from clause in general. I use it myself, and in any given, 
considered case, I see no reason not to use it in Django. 

This is different from insisting it must be used, and rightly so, because, 
as I understand it, the target use case for from is when you want to 
provide more targeted exception logging. 

Take this case: 

def inner():
raise Exception("This is the one we really want to show the user.")


def middle():
try:
inner()
except:
raise Exception("All sorts of stuff that's not so interesting.")


def outer():
try:
middle()
except Exception as e:
msg = "We cut out the unimportant stuff, to focus on what's 
important."
raise Exception(msg) from e.__context__


if __name__ == '__main__':
outer()

Here the use of from makes the traceback exactly how we want it:

$ python exceptions.py 
Traceback (most recent call last):
  File "exceptions.py", line 9, in middle
inner()
  File "exceptions.py", line 4, in inner
raise Exception("This is the one we really want to show the user.")
Exception: This is the one we really want to show the user.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "exceptions.py", line 23, in 
outer()
  File "exceptions.py", line 19, in outer
raise Exception(msg) from e.__context__
Exception: We cut out the unimportant stuff, to focus on what's 
important.
 
Contrasted to not using from, where we just get everything: 

$ python exceptions.py 
Traceback (most recent call last):
  File "exceptions.py", line 9, in middle
inner()
  File "exceptions.py", line 4, in inner
raise Exception("This is the one we really want to show the user.")
Exception: This is the one we really want to show the user.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "exceptions.py", line 16, in outer
middle()
  File "exceptions.py", line 11, in middle
raise Exception("All sorts of stuff that's not so interesting.")
Exception: All sorts of stuff that's not so interesting.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "exceptions.py", line 23, in 
outer()
  File "exceptions.py", line 19, in outer
raise Exception(msg)
Exception: We just output everything because we didn't use from.
 
That's where the real benefit lies. 

So, summary: 

* Exception chaining is the default. We already have that. 
* Short of something I missed (which is always possible 🙂) there's no 
reason for the bulk edit being proposed here. 

Kind Regards,

Carlton

-- 
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/8fd6f226-7ee6-403b-9a8e-9d02408a87c2%40googlegroups.com.

Re: Guidance for GSoC

[Carlton Gibson]

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&status=new&component=contrib.auth&col=id&col=summary&col=status&col=owner&col=type&col=component&col=version&desc=1&order=id

Then for 2fa, there's not a concrete proposal in play, so the first goal is 
that. There's some prior art here — and a thread recently on this topic if 
you search here — so I guess I'd begin looking at that. 
It should give some idea. From there it's easier to solicit concrete 
feedback. 

Kind Regards,

Carlton


On Thursday, 6 February 2020 13:41:05 UTC+1, Sanskar Jaiswal wrote:
>
> 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 moving on to this? 
> Also could anyone kindly guide me in the right direction in order to go 
> through all the necessary things for me to work on 2fa?
>
> Thanking you
> Sanskar Jaiswal
>

-- 
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/62751166-11dd-46b9-8c2b-5bb382d47ea7%40googlegroups.com.

Guidance for GSoC

[Sanskar Jaiswal]

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 moving on to this? Also
could anyone kindly guide me in the right direction in order to go through
all the necessary things for me to work on 2fa?

Thanking you
Sanskar Jaiswal

-- 
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/CACzaa%3DEbUKF8SpoooCpZ8u8aaVKKACe1z5RkRdvpW5TvnSDTSg%40mail.gmail.com.

Re: CrossDB JSONField — Testing needed.

[Adam Johnson]

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 encoded as strings and then decoded back as strings), I think the
new JSONField is making the right choice here.

On Thu, 6 Feb 2020 at 06:35, Jacob Rief  wrote:

> Hi Carlton, hi Sage,
> I just tested this implementation against my JSONField form editor
> library, namely django-entangled
> , using SQLIte.
> As you can see from the testing matrix
> , everything works fine
> using the well known jsonfield  and
> jsonfield2 , which until Django-3
> are the only viable options currently available for SQLite.
>
> However, after switching to the new implementation using the built-in
> JSONField, one of my units tests does not pass
> . After
> examining this locally, I discovered, that the form
> reports product_form._errors: {'properties': ['Value must be valid
> JSON.']}
> The location where this exception is raised, is inside the JSONField's
> validate()
> 
>  method.
> And the reason it is raised
> is because json.dumps(value, cls=self.encoder) can not reparse a valid
> dictionary containing for instance a Python Decimal value.
> Why should a valid Python dictionary be json.dumps(value,
> cls=self.encoder) anyway?
>
> – Jacob
>
> --
> 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/02f0df5e-3d9d-49c4-a81a-a1a2261a1b98%40googlegroups.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/CAMyDDM13toc2jrRm7eg6GSAGR2xmVgeoX8dkaoxTRytjesf0bw%40mail.gmail.com.

Re: Beginner-friendly issue to start contributing to codebase

[Adam Johnson]

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 fairly rapidly. There are many
eyeballs looking out for such issues. As fran says, you can look for older
issues on which work seems to have frozen. But beware - the older the
issue, the harder it likely is to be!

Thanks,

Adam

On Thu, 6 Feb 2020 at 01:01, Fran Hrženjak  wrote:

> Just a quick note: issues that have an owner but weren’t updated in a
> reasonably long time are usually open for taking. It is probably polite to
> ask the owner first, because maybe they just resumed working on the issue
> yesterday :) What is “reasonably long time” is probably open to
> interpretation, but I’d say anything that is counted in years has to be
> fair game.
>
> I’m wondering if it would make sense to have such tickets automatically
> unassigned...
>
>
>
>
> On Thu, Feb 6, 2020 at 1:41 AM Vibhu Agarwal 
> wrote:
>
>> Hi! I'm Vibhu, currently an undergraduate.
>> I've been working with Django for over a year now.
>> And for a long time, I've been wanting to contribute to Django as well.
>>
>> So I followed a few links shared repeatedly in the mailing list, like:
>> -
>> https://docs.djangoproject.com/en/3.0/internals/contributing/new-contributors/
>> - https://docs.djangoproject.com/en/dev/internals/contributing/
>>
>> Through those, I followed other links and thoroughly read the guides like:
>> "Reporting bugs and requesting features", "Triaging tickets", "Submitting
>> patches" and "Writing your first patch for Django"
>>
>> I even tried to get familiar with the process through #31222
>>  and #31226
>>  and looked through some
>> closed PRs as well.
>> Then I tried to find 'easy pickings' which are directly related to the
>> codebase, but I couldn't find any which is new or un-assigned.
>>
>> I just need to get started with understanding the codebase and its
>> structure.
>> If anyone could help me look for an issue which involves writing tests or
>> changing code in any way, it would be great.
>> Any beginner-friendly issue will do.
>>
>> --
>> 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/8489e521-d8b4-44b3-9569-3068dd14256d%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/CAM2o%3DwNBkdPV89JOoCizeKzOG%3D8uarHAnU8FbH08TA_v2L2y9w%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/CAMyDDM1O8tyV3GEW5ir5h76k-g5iL7h3kRoFhPScPxNzs0kcgQ%40mail.gmail.com.

Re: Beginner-friendly issue to start contributing to codebase

[Carlton Gibson]

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

Adjust the ExceptionReporter (& friends) in django.views.debug to show the 
template context in this kind of case. 

(There's a comment on the ticket to the effect of "what should it look 
like?" — Get it on the page, in roughly the right place, and we can look at 
that then.) 

Hopefully that gets you started. 

Kind Regards,

Carlton


On Thursday, 6 February 2020 01:41:45 UTC+1, Vibhu Agarwal wrote:
>
> Hi! I'm Vibhu, currently an undergraduate.
> I've been working with Django for over a year now.
> And for a long time, I've been wanting to contribute to Django as well.
>
> So I followed a few links shared repeatedly in the mailing list, like:
> - 
> https://docs.djangoproject.com/en/3.0/internals/contributing/new-contributors/
> - https://docs.djangoproject.com/en/dev/internals/contributing/
>
> Through those, I followed other links and thoroughly read the guides like:
> "Reporting bugs and requesting features", "Triaging tickets", "Submitting 
> patches" and "Writing your first patch for Django"
>
> I even tried to get familiar with the process through #31222 
>  and #31226 
>  and looked through some 
> closed PRs as well.
> Then I tried to find 'easy pickings' which are directly related to the 
> codebase, but I couldn't find any which is new or un-assigned.
>
> I just need to get started with understanding the codebase and its 
> structure.
> If anyone could help me look for an issue which involves writing tests or 
> changing code in any way, it would be great.
> Any beginner-friendly issue will do.
>

-- 
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/c7f5cbb2-f173-4392-b457-aa10a9a3c317%40googlegroups.com.