Re: How to deal with potential Django bugs you come accross

[Erik Stein]

Hey Curtis --

thanks for your answer! I'll do this from now on (and of course I'll try 
me best to write a complete bug report including a proposed fix if the 
time allows).


https://code.djangoproject.com/ticket/30475#ticket

Have a nice day

-- erik


On 13.05.19 18:19, Curtis Maloney wrote:

Hi Erik,


On 5/13/19 8:22 PM, Erik Stein wrote:


Hello everyone --

 From time to time I come accross a potential bug in Django core, but 
because of a tight schedule don't have the time to dive into it and 
write a proper ticket. How would you suggest to deal with it?



my personal position would be to open a ticket with what information 
you _do_ have, so the discovery is not lost.


The "worst case" is one of the ever efficient Django Fellows comes by, 
tests it out, and closes it as "works as expected".


If you _don't_ log the issue, it _will_ be forgotten about, because 
we're all human. :)



Today e.g.

– Using i18n_patterns with prefix_default_language=True,
– trying to get the frontpage URL without a language given in the URL

works in debug mode, but gives an internal server error without any 
backtrace in production mode.


This was caused by a buggy 404.html template, but probably buggy 404 
templates should give a backtrace, too, and i18n_patterns shouldn't 
be concerned by this anyway.


Certainly a solution worthy of discussion!

Are those notes something which should get into Trac to be 
investigated later?


Absolutely yes!


Thanks for you opinion and guidance,


--
Curtis



--
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2c2b42de-e97c-aca6-0acf-21ed84c20c33%40classlibrary.net.
For more options, visit https://groups.google.com/d/optout.

Re: Django Async DEP

[Andrew Godwin]

On Mon, May 13, 2019 at 4:31 AM Tobias Kunze  wrote:

> Hi Andrew (and everybody following the discussion, of course),
>
> First off, thank you for your work here. DEP9 is an excellent technical
> document, and it was as easy and pleasant to read as a document of this
> scope and depth can be.
>
> Especially the Motivation section was very insightful – it might be
> worth moving it up a bit, as I found myself dropping about a third of my
> notes and questions from the first half of the DEP after reaching the
> motivation section.
> Also, discussing the Why first and the How later is a bit better
> argumentatively – if I just spent half an hour reading about the How,
> I'll start to see the Why as a given, so it's harder to reason about
> alternatives upon reaching the motivation section. Maybe that's just me,
> though.
>

The ordering that's there is defined by the DEP template, alas - though
maybe that's just because of historical reasons. I agree it might be better
to swap them.


>
> The Sequencing section is equally helpful to get a feeling for the
> implementation work. It might be worth including a note on additional
> future DEPs there, as those are only mentioned in the high level summary
> (and in the templating section, I think).
>

I've added another paragraph in there to flesh it out a bit.


>
> I have a couple of questions and comments – none of which are meant to
> criticise the direction of the DEP or arguments. It's just niggles,
> really. I also left some comments on the PR that concern only some
> phrasing.
>
> The DEP doesn't really include a discussion of potential downsides. Even
> if that's not in scope of a DEP, I'd like to ask this here:
>
> - Is there a potential negative impact for Django users who just
>   continue to use Django? The only mention of this says "Running code in
>   threads is likely not going to increase performance - the overhead
>   added will probably decrease it very slightly in the case where you're
>   just running normal, linear code". Do you have any details on that? I
>   would have expected some (even just a sentence or two) discussion of
>   potential downsides in the Rationale section next to the alternatives.
> - Is there a potential negative impact on Django if work on this
>   proposal takes a long time/is abandoned?
>

These are both good questions - I have added in explainers about them to
the "Motivation" section. (In short: Yes, but we'll keep it to a small
impact; No, as long as we're good about code committing and being
sustainable).


>
>
> Less general remarks:
>
> > Every single feature that is converted to be async internally will also
> present
> > a synchronous interface that is backwards-compatible with the API as it
> stands
> > today (in 2.2), at least for the normal deprecation period.
>
> As it stands, this will sound a lot like "we'll deprecate lots of
> synchronous interfaces soon" to people who are afraid of exactly that.
> It's probably worth to clarify this here, or to choose different
> phrasing, unless that's what you're planning to do.
>

Good point, I've made this a lot clearer.


>
> > This general overview works on nearly all features on Django that need
> to be
> > async, with the exceptions mostly being places where the Python language
> itself
> > does not provide async equivalents to features we already use.
>
> Can you give examples for this? They don't need to be in the draft, I
> think, I'd just like to understand this part better.
>

The classic one is attribute access - Django uses "
model_instance.related_field.name" to do work in the background. Attribute
access can't be async, though, so we can no longer call the database.

It also exists for length - doing "len(queryset)" does not pass down an
async context, so you can't do blocking work down there in a subthread. The
pattern continues for most things that Python makes objects supply
__special__ methods for; unless serious work is done to Python as an async
language, these will likely stay the same indefinitely.


>
> > Asynchronous views will continue to be wrapped in an ``atomic()`` block
> by
> > default - while this reduces immediate performance gains, as it will
> lock all
> > ORM queries to a single subthread (see "The ORM" below), it is what our
> users
> > will expect and much safer. If they want to run ORM queries
> concurrently, they
> > will have to explicitly opt out of having the transaction around the
> view using
> > the existing ``non_atomic_requests`` mechanism, though we will need to
> improve
> > the documentation around it.
>
> By default, Django's views are not wrapped in ``atomic()`` blocks. This
> is only the case if ``ATOMIC_REQUESTS`` is ``True``, which it isn't by
> default. Not sure if an off-by-default feature is worth an entire
> paragraph here, but in any case, please make it clear that not every
> async view will be wrapped in an ``atomic()`` block (unless I'm mistaken
> and they will be?).
>

I have updated this. I have kept th

Re: Introduction

[Ruchit Vithani]

I'm taking about this  requirements, which are 
described in the documentation. 

On Tuesday, May 14, 2019 at 6:09:34 PM UTC+5:30, Ruchit Vithani wrote:
>
> I've already installed requirements for tests. Before this, there was a 
> module `tests` which wasn't present, and I installed it using `pip3 install 
> tests`. This is the second module, which is not found. Am I missing 
> something? This is a link to traceback: https://dpaste.de/XYTB 
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/597f3763-145c-49ce-b9d1-881a16d84ab0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Introduction

[Ruchit Vithani]

I've already installed requirements for tests. Before this, there was a 
module `tests` which wasn't present, and I installed it using `pip3 install 
tests`. This is the second module, which is not found. Am I missing 
something? This is a link to traceback: https://dpaste.de/XYTB 

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/45af2cb9-2e7c-491b-b63f-178b211b457f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Introduction

[Adam Johnson]

Hi Ruchit

You should not be trying to 'pip install' the tests module. There is no
tests module in Django's tree, there is a test directory that contains many
individual test modules: https://github.com/django/django/tree/master/tests .
You can see there's an i18n module in there.

>From your traceback, I think you may not be running the tests correctly
with runtests.py. It looks like you are invoking unittest directly. Are you
running as per
https://docs.djangoproject.com/en/dev/intro/contributing/#running-django-s-test-suite-for-the-first-time
 ?

Thanks,

Adam

On Tue, 14 May 2019 at 13:43, Ruchit Vithani 
wrote:

> I'm taking about this  requirements, which
> are described in the documentation.
>
> On Tuesday, May 14, 2019 at 6:09:34 PM UTC+5:30, Ruchit Vithani wrote:
>>
>> I've already installed requirements for tests. Before this, there was a
>> module `tests` which wasn't present, and I installed it using `pip3 install
>> tests`. This is the second module, which is not found. Am I missing
>> something? This is a link to traceback: https://dpaste.de/XYTB
>>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/597f3763-145c-49ce-b9d1-881a16d84ab0%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3C1XQdLEre402NZn0AgPecef6GW-P4qXdZbt6aTJCdkQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Introduction

[Ruchit Vithani]

Hey Adam! I'm running tests same way as in that documentation. In tests 
directory, I used `python -m pip install -r requirements/py3.txt` and then `
./runtests.py`. I tried this again, but output is same.  

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/25fc9f2b-71e9-4cd8-88e3-90695c0daee8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Introduction

[Adam Johnson]

Try checking out an older commit and running the tests there. It may be
that this doesn't work in all situations on the current latest commit on
the master branch.

On Tue, 14 May 2019 at 14:25, Ruchit Vithani 
wrote:

> Hey Adam! I'm running tests same way as in that documentation. In tests
> directory, I used `python -m pip install -r requirements/py3.txt` and
> then `./runtests.py`. I tried this again, but output is same.
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/25fc9f2b-71e9-4cd8-88e3-90695c0daee8%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM39iOQE_fYuHphxCPzsJ1bHwmVdB9Hq_PpOU_gvONcAZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Thoughts on Django Model attribute (descriptor) inheritance.

[Kye Russell]

I don’t know enough to speak on the reasoning behind the current
implementation, but from the perspective of developer experience, I’ve run
into this a few times, and the current behaviour has felt jarring and
unpythonic.


From: Jarek Głowacki  
Reply: django-developers@googlegroups.com
 
Date: 15 May 2019 at 12:11:15 pm
To: Django developers (Contributions to Django itself)
 
Subject:  Thoughts on Django Model attribute (descriptor) inheritance.

Hi friends,

I've raised a ticket here:
https://code.djangoproject.com/ticket/30427#ticket
Has an associated PR and all.

Looking for some experts in this area to eyeball and drop some
thoughts/opinions, or even better, knowledge as to why we're doing things
this way presently.
I feel Django does class inheritance wrong at the moment -- when building a
Model, it refuses to staple on a class attribute if an ancestor/mixin has
already defined that attribute (with a non-falsey value). One could call it
reverse-MRO behaviour.

It looks like the intention in the past was to stop attributes or field
definitions from stomping on methods defined against the same class that
have the same name, but if anything, I'd rather have this raise a proper
warning if it's problematic, or silently stomp if it's not. Having it not
stomp results in some very unpythonic behaviour.
Have a read of my ticket/PR for further context.

Looking forward to getting this fixed, so I can bubble the fix up to
django-model-utils, and then to my production code. ^.^

Cheers,
Jarek
--
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/a7da90e7-a72c-482f-b195-eb196ae46e73%40googlegroups.com

.
For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANK-ykm7Ch3f%3D%3D4qn0iaj%2BMy9P2BO-YvSdk4Ygs4gPbg5-xmtg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Thoughts on Django Model attribute (descriptor) inheritance.

[Jarek Głowacki]

Hi friends,

I've raised a ticket here:
https://code.djangoproject.com/ticket/30427#ticket
Has an associated PR and all.

Looking for some experts in this area to eyeball and drop some 
thoughts/opinions, or even better, knowledge as to why we're doing things 
this way presently.
I feel Django does class inheritance wrong at the moment -- when building a 
Model, it refuses to staple on a class attribute if an ancestor/mixin has 
already defined that attribute (with a non-falsey value). One could call it 
reverse-MRO behaviour.

It looks like the intention in the past was to stop attributes or field 
definitions from stomping on methods defined against the same class that 
have the same name, but if anything, I'd rather have this raise a proper 
warning if it's problematic, or silently stomp if it's not. Having it not 
stomp results in some very unpythonic behaviour.
Have a read of my ticket/PR for further context.

Looking forward to getting this fixed, so I can bubble the fix up to 
django-model-utils, and then to my production code. ^.^

Cheers,
Jarek

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a7da90e7-a72c-482f-b195-eb196ae46e73%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.