Re: New feature request - Run only a random subset of tests.

[Jason Johns]

agreed about this is a unittest/pytest specific focus, not django.

This is pretty straightforward to do with pytest, can have a custom flag 
and then randomize the test collection.  With unittest, not sure.

On Monday, February 12, 2024 at 11:36:57 AM UTC-5 Jörg Breitbart wrote:

> I also think that your requirements are too specific to be added to 
> django. You are prolly better suited by creating your own test picking 
> abstraction for this, e.g. by writing custom test suite aggregates or 
> using unittest.TestLoader.discover and going into tests of interest by 
> your own logic (assuming you are sticking to unittest for testing).
>

-- 
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/e0732ebc-9aa4-49c8-9193-ff32517bb421n%40googlegroups.com.

Re: The problem of versioning a large project.

[Jason Johns]

>Now we have organized versioning, where our project is divided into 
separate GIT repositories which are created for each application.



why? what's the reasoning for this? django already has apps, so why do you 
need to make multiple projects for single components?
On Friday, March 31, 2023 at 10:15:06 AM UTC-4 cha...@gmail.com wrote:

>
> Like Aharon, I'm not entirely certain what you mean but this line:
> > The task looks like bad practice, where we have to create a repository 
> within another one.
> reminded me of git submodules, which I don't think are considered bad 
> practice. Is that what you mean?
> On Thursday, March 30, 2023 at 5:17:41 AM UTC+9 Alex Sonar wrote:
>
>> The problem of versioning a large project.
>>
>> Hi guys, I really got stuck with the challenge, with the design of 
>> versioning for a large project.
>>
>> Now we have organized versioning, where our project is divided into 
>> separate GIT repositories which are created for each application.
>>
>> The new necessity point is to split some of them for front-end and 
>> back-and developers.
>>
>> The task looks like bad practice, where we have to create a repository 
>> within another one.
>>
>> Or redesign the file structures of the application itself, to meet this 
>> requirement.
>>
>> If someone has a similar challenge or practice and helps me make the 
>> right decision, I will be very grateful.
>>
>

-- 
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/9df4d7a0-0025-41ad-923d-aa736dcabcbbn%40googlegroups.com.

Re: dynamically added INSTALLED_APPS

[Jason Johns]

I'd be a -1 on dynamic modification with installed apps.  that's the 
developer's responsibility to add in, and should be implicit by design.  
The list of apps needs to come somewhere via configuration, and django 
defines that configuration to be done explicitly.

I be;ieve some of the major security holes via Wordpress come with being 
able to add in plugins and projects dynamically.   You might be discounting 
this, but it does open up a fairly large attack vector


On Tuesday, February 21, 2023 at 1:54:01 AM UTC-5 Christian González wrote:

> Am 20.02.23 um 14:23 schrieb Jacob Rief:
> > Isn't it a bit dangerous to auto-add a package from PyPI to a running 
> > Django installation? That module then gains full database access and 
> > could do all kind of nasty stuff.
> > Maybe I am a bit naive here, but 3rd party packages sometimes get 
> > installed incautiously.
>
> Hi Jacob,
>
> no, I don't think so. It is generally "dangerous" to run code you don't 
> know what it does ;-)
> In my case it is even more dangerous to run code I wrote myself, hehe.
>
> But really, if you install ANY package via pip, you have to trust that 
> package. So it doesn't matter if you install a Django GDAPS auto-plugin 
> package or django-money. you would have to add it manually to your 
> settings.py/ INSTALLED_APPS anyway to use it.
> GDAPS is intended to enable plugins for a main application - e.g. there 
> is medux, and medux.plugins.laboratory - both from the same vendor. 
> There is no trust problem when installing your own packages.
>
> Christian
>
> -- 
> Dr. Christian González
> https://nerdocs.at
>
>

-- 
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/6c3ea57a-c66d-40cf-809b-899d3b0d2b98n%40googlegroups.com.

Re: Proposal for an "Age" PostgreSQL ORM function

[Jason Johns]

the AGE function takes in two timestamps and returns an interval.  You can 
do this in python by subtracting two date/datetime objects and getting a 
timedelta.  what would the difference be to kick this out to the db?
On Tuesday, January 17, 2023 at 11:11:37 AM UTC-5 niccol...@gmail.com wrote:

> How would you see adding the "AGE" function to the current set of 
> PostgreSQL ORM functions?
>

-- 
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/17148207-2d4e-4163-86ce-0691e14ab7fan%40googlegroups.com.

Re: Intention behind `adelete` being a queryset method, and not available on a model instance?

[Jason Johns]

The explanation makes sense, which is one thing that’s making me feel this 
is something to be called out in the documentation, because it is a 
difference in expectations in the api interface. Since a model has a delete 
method, as does a queryset, the absence of that equivalence for async is 
not what I would expect and it’s not obvious why. 
On Friday, October 21, 2022 at 12:29:31 PM UTC-4 Adam Johnson wrote:

> I opened a ticket to add async methods to Model: 
> https://code.djangoproject.com/ticket/34112
>
> This would be released in Django 4.2, at minimum.
>
> Using async to perform model updates is not likely to be performant, since 
> the queries end up being processed synchronously on a thread anyway. This 
> is because the database libraries Django supports don't have async 
> interfaces.
>
> On Fri, Oct 21, 2022 at 4:49 PM Adam Johnson  wrote:
>
>> If you have a suggestion, sure. But from my perspective the docs are 
>> clear. There's an adelete() method doc'd for QuerySet, and not for Model, 
>> and the release note 
>> <https://docs.djangoproject.com/en/4.1/releases/4.1/#asynchronous-orm-interface>
>>  
>> says “QuerySet now provides an asynchronous interface...”.
>>
>> On Fri, Oct 21, 2022 at 3:51 PM Jason Johns  wrote:
>>
>>> gotcha, then perhaps a documentation tweak would be in order, on both 
>>> queryset and model pages?  because as is, its unclear this is expected.
>>>
>>> On Friday, October 21, 2022 at 9:57:33 AM UTC-4 Adam Johnson wrote:
>>>
>>>> This is intentional, as it stands. Django 4.1 only added async QuerySet 
>>>> methods, not async Model methods. Async model methods like adelete(), and 
>>>> perhaps asave(), would be the next logical step.
>>>>
>>>> On Fri, Oct 21, 2022 at 1:47 PM Jason Johns  wrote:
>>>>
>>>>> I came across a reddit post yesterday 
>>>>> <https://www.reddit.com/r/django/comments/y7w5dm/django_async_delete_from_db/>about
>>>>>  
>>>>> `adelete` raising an attribute error
>>>>>
>>>>> r = await mymodel.objects.aget(some_name=myname) 
>>>>> await r.adelete()
>>>>>
>>>>> would throw an `AttributeError`,
>>>>>
>>>>> whereas r = await mymodel.objects.filter(some_name=myname).adelete() 
>>>>> works as expected.
>>>>>
>>>>> I was a little curious about this, and adelete 
>>>>> <https://docs.djangoproject.com/en/4.1/ref/models/querysets/#django.db.models.query.QuerySet.adelete>
>>>>>  is 
>>>>> explicitly called out in the queryset docs within the `delete` section.  
>>>>> but the models doc page  
>>>>> <https://docs.djangoproject.com/en/4.1/ref/models/instances/#deleting-objects>only
>>>>>  
>>>>> contains items about `delete`.  Is this intentional or not, and if it is 
>>>>> intentional, perhaps a specific call-out in both queryset and model 
>>>>> delete 
>>>>> sections would help with clarification.
>>>>>
>>>>> -- 
>>>>> 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-develop...@googlegroups.com.
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/django-developers/82ba40ef-ea73-4492-a2c3-448dbd1b9245n%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/django-developers/82ba40ef-ea73-4492-a2c3-448dbd1b9245n%40googlegroups.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>>> -- 
>>> 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-develop...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/cbb9dbba-be64-4c97-abfe-0b42ed42ddb3n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/django-developers/cbb9dbba-be64-4c97-abfe-0b42ed42ddb3n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
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/f49f87ed-166e-4da8-baba-218b2da485a2n%40googlegroups.com.

Re: Intention behind `adelete` being a queryset method, and not available on a model instance?

[Jason Johns]

gotcha, then perhaps a documentation tweak would be in order, on both 
queryset and model pages?  because as is, its unclear this is expected.

On Friday, October 21, 2022 at 9:57:33 AM UTC-4 Adam Johnson wrote:

> This is intentional, as it stands. Django 4.1 only added async QuerySet 
> methods, not async Model methods. Async model methods like adelete(), and 
> perhaps asave(), would be the next logical step.
>
> On Fri, Oct 21, 2022 at 1:47 PM Jason Johns  wrote:
>
>> I came across a reddit post yesterday 
>> <https://www.reddit.com/r/django/comments/y7w5dm/django_async_delete_from_db/>about
>>  
>> `adelete` raising an attribute error
>>
>> r = await mymodel.objects.aget(some_name=myname) 
>> await r.adelete()
>>
>> would throw an `AttributeError`,
>>
>> whereas r = await mymodel.objects.filter(some_name=myname).adelete() 
>> works as expected.
>>
>> I was a little curious about this, and adelete 
>> <https://docs.djangoproject.com/en/4.1/ref/models/querysets/#django.db.models.query.QuerySet.adelete>
>>  is 
>> explicitly called out in the queryset docs within the `delete` section.  
>> but the models doc page  
>> <https://docs.djangoproject.com/en/4.1/ref/models/instances/#deleting-objects>only
>>  
>> contains items about `delete`.  Is this intentional or not, and if it is 
>> intentional, perhaps a specific call-out in both queryset and model delete 
>> sections would help with clarification.
>>
>> -- 
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/82ba40ef-ea73-4492-a2c3-448dbd1b9245n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/82ba40ef-ea73-4492-a2c3-448dbd1b9245n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/cbb9dbba-be64-4c97-abfe-0b42ed42ddb3n%40googlegroups.com.

Intention behind `adelete` being a queryset method, and not available on a model instance?

[Jason Johns]

I came across a reddit post yesterday 
about
 
`adelete` raising an attribute error

r = await mymodel.objects.aget(some_name=myname) 
await r.adelete()

would throw an `AttributeError`,

whereas r = await mymodel.objects.filter(some_name=myname).adelete() works 
as expected.

I was a little curious about this, and adelete 

 is 
explicitly called out in the queryset docs within the `delete` section.  
but the models doc page  
only
 
contains items about `delete`.  Is this intentional or not, and if it is 
intentional, perhaps a specific call-out in both queryset and model delete 
sections would help with clarification.

-- 
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/82ba40ef-ea73-4492-a2c3-448dbd1b9245n%40googlegroups.com.

Re: Configuration of "level" in LOGGING

[Jason Johns]

How would this work with secret stores like hashicorp vault, aws secrets 
manager?  Or even via environment variables?  This approach would work if 
you define the logging level in your configuration, but not so friendly for 
other approaches.

On Monday, April 4, 2022 at 9:26:02 PM UTC-4 Dan Swain wrote:

> The current Django LOGGING setup requires a string for the "level".  This 
> is not intuitive since the Python logging module defines logging.DEBUG, 
> logging.INFO, etc.  I think one should be able to configure the logging 
> level using {  'level': logging.DEBUG  } rather than being required to use  
> {  'level': 'DEBUG'  }.
>

-- 
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/9e295cb2-e009-4a0a-b506-cb1ebec77761n%40googlegroups.com.

Re: Feature requests for queryset

[Jason Johns]

filter takes in a decomposed dict of keys and values, ie 

filter_dict = {
"id_in": SomeIterable
}

qs = SomeModel.objects.filter(**filter_dict)

from your example, IGNORE_FILTER does not return an iterable, so how is 
that to work with a SQL query?

Seems to me that ths might be an x-y problem

On Monday, April 4, 2022 at 8:33:38 AM UTC-4 laurent...@gmail.com wrote:

> Hello,
>
> Below are 2 feature requests :
> - the first would just be to add a constant object for ignoring some 
> filters,
> to avoid lists of "if ... is not None: q = q.filter(...)" like I must
> do right now,
> q = q.filter(id_in=[1,2,3]) filters something
> q = q.filter(id_in=IGNORE_FILTER) does not filter
> - the second would be to have "in-place" variants of filter and exclude, 
> like :
> q.filter_in_place(id_lt=5)
> instead of
> q = q.filter(id_lt=5)
> Maybe other people asked for one or both of these features before,
> but I did check the search here :
> https://code.djangoproject.com/search
> and also the archive here :
> https://groups.google.com/g/django-developers/search?q=ignore%20filter
> etc.
> and found nothing related.
>
> I proposed this morning the following class with better example at my
> team at work,
> but the decision was took that we stay on bare Django.
> Nevertheless, some of my teammates agreed that the IGNORE_FILTER
> feature was nice.
>
> class EnhancedQuerySet:
> """
> Extends the functionalities of Django QuerySet
> Example:
> - before:
> def some_function(
> fk1_ids: Optional[List[int]] = None,
> fk2_ids: Optional[List[int]] = None,
> fk3_ids: Optional[List[int]] = None,
> fk4_ids: Optional[List[int]] = None,
> pk_ids: Optional[List[int]] = None,
> ...
> ):
> some_instances_queryset = SomeModelClass.objects.all()
> if fk1_ids is not None:
> some_instances_queryset =
> some_instances_queryset.filter(fk1_id__in=fk1_ids)
> if fk2_ids is not None:
> some_instances_queryset =
> some_instances_queryset.filter(fk2_id__in=fk2_ids)
> if fk3_ids is not None:
> some_instances_queryset =
> some_instances_queryset.filter(fk3_id__in=fk3_ids)
> if fk4_ids is not None:
> some_instances_queryset =
> some_instances_queryset.filter(fk4_id__in=fk4_ids)
> if pk_ids is not None:
> some_instances_queryset =
> some_instances_queryset.filter(id__in=pk_ids)
> for some_instance in some_instances_queryset:
> ...
> - after:
> def some_function(
> fk1_ids: Optional[List[int]] = EnhancedQuerySet.IGNORE_FILTER,
> fk2_ids: Optional[List[int]] = EnhancedQuerySet.IGNORE_FILTER,
> fk3_ids: Optional[List[int]] = EnhancedQuerySet.IGNORE_FILTER,
> fk4_ids: Optional[List[int]] = EnhancedQuerySet.IGNORE_FILTER,
> pk_ids: Optional[List[int]] = EnhancedQuerySet.IGNORE_FILTER,
> ...
> ):
> some_instances_queryset = EnhancedQuerySet(SomeModelClass.objects.all())
> some_instances_queryset.filter(
> fk1_id__in=fk1_ids,
> fk2_id__in=fk2_ids,
> fk3_id__in=fk3_ids,
> fk4_id__in=fk4_ids,
> id__in=pk_ids,
> )
> for some_instance in some_instances_queryset:
> ...
> You may alias EnhancedQuerySet for shorter code :
> from ... import EnhancedQuerySet as EQS
> def some_function(
> fk1_ids: Optional[List[int]] = EQS.IGNORE_FILTER,
> fk2_ids: Optional[List[int]] = EQS.IGNORE_FILTER,
> fk3_ids: Optional[List[int]] = EQS.IGNORE_FILTER,
> fk4_ids: Optional[List[int]] = EQS.IGNORE_FILTER,
> pk_ids: Optional[List[int]] = EQS.IGNORE_FILTER,
> ...
> ):
> some_instances_queryset = EQS(SomeModelClass.objects.all())
> some_instances_queryset.filter(
> fk1_id__in=fk1_ids,
> fk2_id__in=fk2_ids,
> fk3_id__in=fk3_ids,
> fk4_id__in=fk4_ids,
> id__in=pk_ids,
> )
> for some_instance in some_instances_queryset:
> ...
> """
>
> IGNORE_FILTER = object() # a sentinel for ignoring some filter to
> distinguish from None
>
> def __init__(self, queryset):
> self.queryset = queryset
>
> def _get_true_kwargs(self, kwargs: dict):
> true_kw_args = {}
> for key, value in kwargs.items():
> if value is EnhancedQuerySet.IGNORE_FILTER:
> continue
> true_kw_args[key] = value
> return true_kw_args
>
> def filter(self, *args, **kwargs):
> """
> Enhanced filter function with 2 features :
> - ignore some filters given with some default value
> - never forget the affectation after filtering, i.e. avoid this mistake:
> queryset.filter()
> instead of queryset = queryset.filter()
> """
> true_kw_args = self._get_true_kwargs(kwargs)
> self.queryset = self.queryset.filter(*args, **true_kw_args)
>
> def exclude(self, *args, **kwargs):
> """
> Similar to filter method but with exclude
> """
> true_kw_args = self._get_true_kwargs(kwargs)
> self.queryset = self.queryset.exclude(*args, **true_kw_args)
>
>
> Best regards,
> Laurent Lyaudet
>

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

djangocon eu slack and contact information

[Jason Johns]

At the django-users google group, someone made a recent post 
https://groups.google.com/g/django-users/c/E4SX505gTCY about the djangocon 
EU announcement 
.
  
Looks like there's two references to the conference Slack, one of which is

> We hope we'll see you all at DjangoCon Europe 2022, and don't forget to 
follow us @djangoconeurope  on 
Twitter, and also join our dedicated Slack channel 
.
That Slack link goes to a sign in page, there's no means to do a sign-up if 
you don't already have an account at that workspace.  I don't have a 
twitter account and there's no , so was curious if there were a means for 
anyone here to pass this on to David or Miguel at djangocon EU?  I tried 
sending a message to cont...@djangocon.eu, but that address was not found.

-- 
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/b8acf0f2-efba-466e-9067-a85111c98623n%40googlegroups.com.

Roadmap and communication of features planned for releases

[Jason Johns]

This came up via a query at Reddit 
https://reddit.com/r/django/comments/setc9n/official_roadmap/ and I wasn’t 
able to find anything other than what is already in the comments. That also 
made me curious and feel that more communication about planned features and 
changes could be useful.

Thanks!


-- 
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/27b5c12d-6473-4831-a635-47d01de55249n%40googlegroups.com.

Re: Feature Request: Provide an option to disable static files caching during development

[Jason Johns]

https://docs.djangoproject.com/en/3.2/ref/contrib/staticfiles/#django.contrib.staticfiles.storage.ManifestStaticFilesStorage

Are you using this?  basically, it converts static asset filenames from 
`styles.css` to `styles.2932y382.css` and other random-seeming hashes in 
the filename.  Useful for cache-busting.
On Monday, October 25, 2021 at 3:38:49 AM UTC-4 Bharat Chauhan wrote:

> Hi,
>
> That won't work because this is related to static files and how browsers 
> implement caching for static files.
>
> This is a good article on this: 
> https://engineering.fb.com/2017/01/26/web/this-browser-tweak-saved-60-of-requests-to-facebook/
>
> Basically, browsers won't revalidate the cache unless the server also 
> sends a `Cache-Control` header. Which Django's built-in static view doesn't 
> do. That means, if you make changes to CSS/JS files during development, 
> browsers will serve stale version unless the cache is disabled.
>
> On Saturday, October 23, 2021 at 1:37:39 PM UTC+5:30 roxane...@gmail.com 
> wrote:
>
>> Hi
>>
>> Wouldn't the setting "CACHE_MIDDLEWARE_SECONDS" do what you are looking 
>> for ?
>>
>> Regards,
>>
>>
>> Le vendredi 22 octobre 2021 à 15:53:44 UTC+2, Bharat Chauhan a écrit :
>>
>>> Really, no one is interested in making the developer experience a little 
>>> less frustrating?
>>>
>>> It's literally two lines of code and will eventually save hours trying 
>>> to refresh the cache by opening dev tools, 
>>> which, btw, isn't even possible on mobile.
>>>
>>> Besides, Django's dev server is not meant to be used in production. So 
>>> why even care about caching?
>>> On Tuesday, September 28, 2021 at 10:49:06 AM UTC+5:30 laym...@gmail.com 
>>> wrote:
>>>
 I'm +1 on this.

 In my experience teaching Django at university, this always confuses 
 students: "why are my changes not reflected in the browser?"

 Having static files caching disabled when DEBUG=True would be very 
 useful. Thanks for bringing this up!

 Sage

 On Monday, 27 September 2021 at 20:17:35 UTC+7 Bharat Chauhan wrote:

> Hello,
>
> I recently opened a ticket (#33148 
> ) but it was closed as 
> duplicate of (#32891 ) 
> which itself is marked "wontfix".
>
> The reasoning provided by Carlton Gibson for this is:
>
> > *I don't think this is the right approach. As far as I can see the 
> browser behaviour is correct and as desired, s**erving static assets 
> from the browser cache when possible.*
>
> At least while DEBUG is True, I see no harm in setting `Cache-Control: 
> max-age=0` header.
>
> This will allow browsers to cache the files while forcing them to 
> revalidate cache using the If-Modified-Since header. This way, Django can 
> serve updated files if they get modified or return a 304 response in 
> which 
> case browsers will use the cached file (conforming to Carlton's comment 
> about using browser cache when possible).
>
> This will aid in development as we now have to open the browser's 
> network tab and disable the cache to refresh static files. In Mobile, 
> disabling cache is not possible, so we have to test in Incognito Mode. 
> It's 
> a frustrating development experience.
>
> Thank you.
>


-- 
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/12b65160-10b5-4af0-ab84-2cac8b7326f5n%40googlegroups.com.

Re: RSS access to Google groups?

[Jason Johns]

https://support.google.com/groups/thread/118690869/when-will-googlegroups-rss-feed-be-back-online?hl=en

Apparently you're not the only one having this error, and seems the 
solution only applies to public groups.  

On Tuesday, July 27, 2021 at 11:38:47 AM UTC-4 Claude Paroz wrote:

>
> Hi,
> It looks like from several days now, access to Google groups by RSS feeds 
> is producing an error.
> E.g. 
> https://groups.google.com/forum/feed/django-developers/msgs/rss.xml?num=50
>
> Does anyone know if this means that Google stopped supporting reading 
> groups by RSS?
>
> Claude
>

-- 
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/7ef9e94e-5b1d-432b-989c-ea66b75ac546n%40googlegroups.com.

Re: The certificate for code.djangoproject.com expired on 7/4/2021.

[Jason Johns]

FWIW, a user at pyslackers said they got a 503 about the same time about 50 
minutes after Asif's initial message.  Then about two hours later (about an 
hour before Adam's reply), someone else responded that they weren't able to 
replicate.  Maybe there was a delay in applying the cert rotation?  I'm not 
able to easily see when the cert was generated.

On Sunday, July 4, 2021 at 5:38:01 AM UTC-4 Adam Johnson wrote:

> Hi Asif
>
> I'm not seeing a problem - the certificate I get expires in October.
>
> [image: Screenshot 2021-07-04 at 10.36.15.png]
>
> Thanks,
>
> Adam
>
> On Sun, 4 Jul 2021 at 06:34, Asif Saif Uddin  wrote:
>
>>
>> Websites prove their identity via certificates, which are valid for a set 
>> time period. The certificate for code.djangoproject.com expired on 
>> 7/4/2021.
>>  
>> Error code: SEC_ERROR_EXPIRED_CERTIFICATE
>>  
>> View Certificate
>>
>> https://code.djangoproject.com/wiki/SummerOfCode2021
>>
>> Asif
>>
>> -- 
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/539fc003-f4de-4dae-8ace-d5103c19f44en%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/722377bc-1d6f-491e-bf19-ab25871dbb2dn%40googlegroups.com.

Re: Should a queryset avoid using a pk of a deleted object?

[Jason Johns]

Does https://code.djangoproject.com/ticket/22553 cover this case?  It was 
closed as a documentation update with this commit in the docs: 
https://github.com/django/django/pull/2974/files


>From your example, re-doing the book.authors.all() call will refresh the 
queryset's cache.
On Wednesday, November 4, 2020 at 5:51:36 AM UTC-5 Carles Pina Estany wrote:

>
> Hi all,
>
> I have a question about Django ORM. I'd like to confirm that the current
> behaviour is expected (in a way it is!) or find/open an issue if
> needeed.
>
> In this example I've defined two models (see them at the end of the
> email if needed): one for a Book with a ManyToMany to authors, and a
> second model of Author.
>
> And code like this:
> ```
> author = Author.objects.create(name='James')
> book = Book.objects.create(title='test')
>
> book.authors.add(author)
> book.save()
>
> authors = book.authors.all()
>
> book.delete()
>
> print(authors) # should a user expect all the authors?
> ```
>
> In the `print(authors)` line the book is already deleted and it returns
> no authors. It executes an SQL query where at that point book.pk does
> not exist. I think that technically it could return wrong existing data
> if the book.pk had been reused, AFAIK none of the default database
> backends would do this but I think that it could happen if doing a field
> with primary_key=True.
>
> If the `authors = book.authors.all()` line was after the
> `book.delete()`: Django raises a ValueError with the error message
> ' needs to have a value for field "id" before this
> many-to-many relationship can be used.'
>
> I understand why this happens. In some code I needed something along
> these lines and I'm doing something like "authors =
> list(book.authors.all())" to keep the list of authors, delete the book
> and then do some actions in the authors.
>
> I think that this can be confusing. Also, Django prevents the error in
> one case (get query set after the deletion) but not the other case
> (execute the query after deletion).
>
> Fix idea:
> If QuerySet was holding a book instance it could enforce that book.pk is
> set at the time of running the query (or returning the result if the
> result was cached?)
>
> I had a quick look at QuerySet and the book instance is in
> self._hints['instance']. In `QuerySet._fetch_all` I could do something
> along the lines of:
> `
> if 'instance' in self._hints and self._hints['instance'].pk is None:
> raise ValueError('Object deleted')
> `
>
> I guess that in
> create_forward_many_to_many_manager.ManyRelatedManager.__init__ the book
> instance could be saved in some variable in the QuerySet object (I guess
> that self._hints['instance'] is not meant to be used like my example) to
> check this when appropiate. Has this ever been considered? Or is the
> behaviour as it is now good enough?
>
> Thank you very much,
>
> PS: Models used in the example:
> ```
> class Author(models.Model):
> name = models.TextField(max_length=64)
>
> def __str__(self):
> return self.name
>
>
> class Book(models.Model):
> title = models.TextField(max_length=128)
> authors = models.ManyToManyField(Author)
>
> def __str__(self):
> return self.title
> ```
>
> -- 
> Carles Pina i Estany
> https://carles.pina.cat
>

-- 
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/28155993-2ea0-4406-b9d0-44da422b3ad5n%40googlegroups.com.

Re: Proposal - Warn user when creating or applying a delete migration?

[Jason Johns]

I appreciate the feedback!  

I do agree with you, Adam, that this may not be something that would 
strictly be Django's responsibility, but I also feel that if a thing is 
causing a number of footguns, regardless if its primarily the user's fault, 
Django is getting the blame.  I do like your suggestion to Tom's proposal, 
especially if its combined with shell colors.

Rene makes a very good point, and this would primarily be useful on the 
dev's machine when applying migrations after changes, and before they hit 
staging/prod.

thank you :-)

-- 
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/b55252c8-8735-4d0b-a2e2-0e9d897226cfo%40googlegroups.com.

Proposal - Warn user when creating or applying a delete migration?

[Jason Johns]

Should Django output a warning and/or require a prompt when a DeleteModel 
or RemoveField are to be executed when applying migrations?

Over at the pythondev slack group, a user wanted to rename a model to 
another name, and wasn't aware of  the `db_table` attribute in Model Meta.  
So a new model was created, the old one removed.  Then a migration was made 
and applied... only to delete the data on the staging environment.  This 
user was also unaware of the typical three step migration process 
recommended for removing a model or field, and made the statement that 
there should have been a prompt during migrate that data loss was a 
possibility.

This got me thinking.  Googling around seems to suggest this experience of 
running a delete migration is a somewhat common footgun because the 
implications are not as explicit as Python warnings and exceptions.  As a 
result, it might be beneficial for migrate to have some tweaks to attempt 
to reduce surprise.

How about this:

   1. Migrate checks if any executions of migrations.DeleteModel or 
   migrations.RemoveField are included in the migrations being applied
   2. If so, output a warning message about a table being dropped or column 
   being deleted and that data loss will occur
   3. Output a yes/no input prompt asking if the user has made a data 
   migration or is aware and acknowledges the risk


Is this something that would fit in with the overall philosophy of Django?  
To be honest, I'm undecided about this, but this may be my own biased 
feelings that this should be implicit in the developer's mind when 
considering removing columns and tables.  But then again, I have been 
burned by this in a toy project.

-- 
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/e4af0410-7eab-4431-8c56-5094d9498b92o%40googlegroups.com.

Re: Forms submitted by bots

[Jason Johns]

We use Signal Sciences  at work, 
integrated with nginx

I'm looking for a solution which will be zero time wasting for human users, 
> not even clicking on the recaptcha's button, but on the other hand will 
> prevent bots from submitting the form
>

welcome to the arms race :-)

-- 
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/7302fe10-36d2-4abf-9d78-476203f60fe9%40googlegroups.com.

Re: Ideas for a new DEP on long-term Django API compatibility

[Jason Johns]

Pascal, I don't think anyone here disagrees with your overall goal to 
reduce the breaking changes.  As someone that got handed a 1.2 project with 
zero tests and updated it to 1.8, good test coverage to lay the foundation 
for reviving an ambitious project that went comatose before being 
prioritized again, the amount of breakage and updating required was 
surprisingly small.  It took about a month or so to do, and a quarter of 
that was setting up staging and prod environments on AWS.  The core devs 
here have done a great job, in my opinion, of keeping the breaking changes 
to a minimum, and making them in a thoughtful manner with an eye to the 
future.

Tech debt is a very real thing.  Keeping it under control is vital to the 
pace of improvement and updates for any project, large, middling or small.  
Any project requires maintanence at minimum, just like owning a car or 
house.  If you buy a car and run it every day for five years, only filling 
up the gas tank and adding a splash of oil now and then,  you don't have 
any excuse to be upset at the mechanic or manufacturer for the size of the 
repair bill when things start breaking.  At least with software, its alot 
easier to get fixes out than with hardware.  You make a persuasive argument 
and have great passion, but the overall goal of enabling out of date and 
unsupported releases to remain around longer than they should be makes me 
feel really uncomfortable.  A spftware project is not buy once and forget, 
neither is a car.  And your package seems to encourage that lax practice to 
a level that I would be highly resistant at working at a company if I 
couldn't persuade management to prioritize keeping up to date and tech debt 
at a manageable level.

Open source has a pretty low barrier to entry, and django projects like the 
ones you listed on django packages are reflective of that.  Its easy to 
make a package and put it out, but maintaining and iterating and releasing 
take alot more in terms or time, effort and emotional state.  Fortunately, 
Python as a whole seems to be much easier on package devs than the JS 
community, but as I'm sure Carlton, Adam, Tim, and anyone that's published 
a package with requests for support can attest, it can get exhausting.  
That's when packages just die on the vine.  Some are lucky to 
be resuscitated by another dev taking over, or forking the original, but 
that doesn't happen for the majority.  Deliberately going out of your way 
to ensure that old code which hasn't been looked at in however long and was 
last working on two LTS releases ago gives me a very squicky feeling in my 
stomach.  

-- 
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/097ecac4-0596-40d4-a069-7e8d2c879ce9%40googlegroups.com.

Re: ipdb throws AttributeError in autoreload.py with 2.2.2

[Jason Johns]

Wow, that was quick! Thank you!

-- 
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/6b7125aa-404e-4678-8c19-578533cb52fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

ipdb throws AttributeError in autoreload.py with 2.2.2

[Jason Johns]

Hello,

About two weeks ago, work updated the base docker image to use django 2.2.2 
and I noticed an issue right off the bat with using ipdb 0.12 and ipython 
7.5.0 (which are also defaults for the docker image).  I really didn't have 
the time to dig more, and got along well enough with pdb in the meantime.  
This weekend, I had some free time to poke around, and these are my 
findings:


In a DRF serializer helper method, I import ipdb and set a breakpoint.  The 
API call executes and stops here.  After anywhere from 1 to 3 seconds pause 
at the breakpoint, I then see the following output from ipdb> and the 
runserver process exits.
> /orm/service/api/serializers/helpers/facet_generator.py(62)__make_facet()
 61 import ipdb; ipdb.set_trace()
---> 62 log.info(f'Facet field: {facet_field}')
 63 log.info(f'Facet values: {facet_values}')

ipdb> Traceback (most recent call last):
  File "/orm/manage.py", line 15, in 
execute_from_command_line(sys.argv)
  File 
"/usr/local/lib/python3.7/site-packages/django/core/management/__init__.py", 
line 381, in execute_from_command_line
utility.execute()
  File 
"/usr/local/lib/python3.7/site-packages/django/core/management/__init__.py", 
line 375, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
  File 
"/usr/local/lib/python3.7/site-packages/django/core/management/base.py", 
line 323, in run_from_argv
self.execute(*args, **cmd_options)
  File 
"/usr/local/lib/python3.7/site-packages/django/core/management/commands/runserver.py",
 
line 60, in execute
super().execute(*args, **options)
  File 
"/usr/local/lib/python3.7/site-packages/django/core/management/base.py", 
line 364, in execute
output = self.handle(*args, **options)
  File 
"/usr/local/lib/python3.7/site-packages/django/core/management/commands/runserver.py",
 
line 95, in handle
self.run(**options)
  File 
"/usr/local/lib/python3.7/site-packages/django/core/management/commands/runserver.py",
 
line 102, in run
autoreload.run_with_reloader(self.inner_run, **options)
  File "/usr/local/lib/python3.7/site-packages/django/utils/autoreload.py", 
line 585, in run_with_reloader
start_django(reloader, main_func, *args, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/django/utils/autoreload.py", 
line 570, in start_django
reloader.run(django_main_thread)
  File "/usr/local/lib/python3.7/site-packages/django/utils/autoreload.py", 
line 288, in run
self.run_loop()
  File "/usr/local/lib/python3.7/site-packages/django/utils/autoreload.py", 
line 294, in run_loop
next(ticker)
  File "/usr/local/lib/python3.7/site-packages/django/utils/autoreload.py", 
line 334, in tick
for filepath, mtime in self.snapshot_files():
  File "/usr/local/lib/python3.7/site-packages/django/utils/autoreload.py", 
line 350, in snapshot_files
for file in self.watched_files():
  File "/usr/local/lib/python3.7/site-packages/django/utils/autoreload.py", 
line 249, in watched_files
yield from iter_all_python_module_files()
  File "/usr/local/lib/python3.7/site-packages/django/utils/autoreload.py", 
line 103, in iter_all_python_module_files
return iter_modules_and_files(modules, frozenset(_error_files))
  File "/usr/local/lib/python3.7/site-packages/django/utils/autoreload.py", 
line 120, in iter_modules_and_files
sys_file_paths.append(module.__file__)
AttributeError: module '__main__' has no attribute '__file__'

If you suspect this is an IPython bug, please report it at:
https://github.com/ipython/ipython/issues
or send an email to the mailing list at ipython-...@python.org

You can print a more detailed traceback right now with "%tb", or use 
"%debug"
to interactively debug it.

Extra-detailed tracebacks for bug-reporting purposes can be enabled via:
%config Application.verbose_crash=True

Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/IPython/core/history.py", 
line 780, in writeout_cache
self._writeout_input_cache(conn)
  File "/usr/local/lib/python3.7/site-packages/IPython/core/history.py", 
line 764, in _writeout_input_cache
(self.session_number,)+line)
sqlite3.ProgrammingError: SQLite objects created in a thread can only be 
used in that same thread. The object was created in thread id 
139743563077376 and this is thread id 139743865329408.



To be sure it wasn't just the project's fault, I checked out another team's 
project and got the same error.  This seems to be isolated to just ipdb.  
Using pdb does not show the same errors

Then, I pulled the latest from django github and confirmed that it is 
probably related to the changes in iter_modules_and_files 

 between 
2.2.1 and 2.2.2.  Looking at ipdb 
's package structure, I 
think the problem is the usage of __main__.py, because it apparently does 
not 

Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

[Jason Johns]

Tom Christie wrote this about what DRF brings to the table over plain Django:

Django REST framework isn't required, but it helps you get a lot of things 
right that will be time consuming and error prone if you're working from core 
Django.
 • Serializers
The Django serializers are not really suitable for anything other than dumping 
and loading fixture data - they don't allow you to customize the representation 
in any substantial way.
Using Django Forms for validation isn't suitable either as they're intended for 
HTML only validation and can't eg handle nested validation.
REST frameworks serializers are designed for API usage and cover both JSON or 
form validation, as well as being able to represent as either HTML Forms or 
formats such as JSON. They also give you lots of scope for handling the 
representation of relationships, such as using hyperlinked relations.
 • Authentication and permissions
REST framework's authentication will gracefully handle both session based and 
token based schemes at the same time, and get the CSRF behavior right. You'll 
find that really awkward to do if using plain Django. It also helps ensure 
you're issuing failure responses that are suitable for API clients (eg get 401 
vs 403 responses right)
The auth, permissions and throttling are also more flexible because they're 
defined at a view level, rather than as middleware or a view decorator. This 
makes it easier to eg combine multiple schemes, or to apply different schemes 
to different parts of your application.
 • Views
Django's generic class based views are suitable to HTML applications. REST 
framework's generic class based views are suitable for API services. Typicallly 
API views have slightly different behavior by convention. Eg create in an HTML 
application might typically redirect the user to the created item, whereas an 
API will respond with a 201 CREATED response.
There's stacks of other functionality and behavior that makes using Django REST 
framework simpler, quicker and likely more correct than if you start with plain 
Django. But those are some of the obvious differences to get started with.

https://reddit.com/r/django/comments/3h9oj8/_/cu5pzu9/?context=1

Seems pretty concise and self explanatory to me. This could easily be adapted 
to be in the docs.

-- 
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/af24d69f-1d16-40db-9558-11745fce2399%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: revisiting the Python version support policy

[Jason Johns]

In addition, with tools like https://github.com/pyenv/pyenv available that make 
changing the currently applicable python version in any given shell extremely 
easy, I feel pinning support to a specific operating system version, however 
stable, is not the optimal approach 

-- 
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/211103b2-ecb4-4e3e-bf84-85cd049b47ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A faster paginator for django

[Jason Johns]

https://www.citusdata.com/blog/2016/03/30/five-ways-to-paginate/ has some 
interesting alternatives.  I believe Django uses the first one. But the 
others have some tradeoffs that might not apply to all the dbs that django 
supports.

-- 
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/b649819f-80c3-4b12-af07-0914c679287a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Jason Johns]

This is prompted by James Bennet's article yesterday 
 which prompted a 
discussion with a coworker of mine.

I've been using django for a while now, am a mid-level at a company that 
uses django/DRF heavily, and am a regular lurker here because its a great 
way to keep up with the happenings of the project.  That said, this is from 
an outsiders perspective:


   1. The documentation of the framework is top notch, but the sections on 
   contributing and getting up to speed with the framework, how to run it 
   while developing on it, etc are sparse.  The codebase is fairly 
   intimidating when you read a ticket and then try to dig in.  Fortunately, 
   all breakage from my experimentation is private and not public :-).  I feel 
   having a much more thorough documentation/examples of ramping up and 
   getting started would do a great job in reducing some of that intimidation 
   factor.
   2. The fellows, Tim and Carlton, do a great job here in triaging tickets 
   and handling the day to day work of the project.  But I feel the bug 
   tracker is being a significant hindrance to contributors and possible 
   contributors, and when combined with a lack of intuitive methods to find 
   easy picking tickets makes it more difficult to get going from scratch.  I 
   imagine this is something that has been discussed before.
   3. I like the idea James proposed about mergers and releasers.  I would 
   also suggest that mergers be people who have significant experience in 
   specific parts of Django and handle merging of those tickets.  This is 
   similar to how the Linux kernel project is set up, with maintainers 
   responsible for specific segments of the code tree.  It would also be great 
   if these mergers had technical team-lead like skills that can be used to 
   shepherd both new and knowledgeable contributors onward and upward with 
   tickets, knowledge and support.

I personally am going to make more of an effort to get more involved here, 
but I think these three points above would help lower the mental resistance 
of someone that wants to enter the project.  I have to wonder, however, how 
well situated the experienced people here are for spending time getting new 
contributors up to speed.  Onboarding a new developer is a major time 
allocation at companies, much less open source projects that are being 
worked on in ocassional company time/spare time across the world.  What's 
the capacity available, and who is available for what kind of questions?  

-- 
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/6a80dbf4-dcc5-40dc-bca8-11cdcc6e7ab8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django and Cython

[Jason Johns]

Not at all, just that Cython itself is probably not the approach to take.  
Andrew Godwin recently posted a proposal for a Django ASGI roadmap 
 and 
there's a good amount of work to be done there.

Benchmarks have their place.  But if they're not matching real world 
problems, then I don't see much use of them other than stroking egos of 
their developers.  And my personal experience says that most of the 
problems with Django's slowness have most of the bottlenecks with db 
connections, networking latency and other things outside of Python.  And 
those problems inside Python might not be the best things to leverage 
Cython for.

I get the issue of wanting to show up to your peers with node, but 
personally, I just don't find it worth it.  It has its use cases, but more 
and more I see it being squashed into a use case its really not suited for 
simply because the creator or team are very one-dimensional as far as 
languages..  Use the right tool for the job, and just ignore the fanbois.

-- 
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/3a82c5de-b3d0-449a-8e6b-2f008fd9c803%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django and Cython

[Jason Johns]

There was a discussion a while back about this 
https://groups.google.com/forum/#!searchin/django-developers/cython/django-developers/Fi4U602GxHA/mE50LOPkBgAJ

tl;dr not sure what benefits Django would get from it, since the 
bottlenecks you experience are most likely non-Django/Python parts of your 
project, such as networking latency, db queries, connection initiation, 
etc.  In addition, pypy is an alternative interpreter that you can drop in 
for up to 3.5.x Python versions.

On Wednesday, August 1, 2018 at 5:21:38 PM UTC-4, Daniel Anechitoaie wrote:
>
> I'm looking at frameworks like https://vibora.io/ that make use of Cython 
> to greatly improve the performance and I'm just wondering if something like 
> this would work with Django?
> Was there any discussion (taken into consideration) about using Cython to 
> boost the performance of certain aspects of the framework?
> Would it help make it faster?
>
> I really love Python and Django for me is the best web framework out 
> there, but you have to notice how fast other frameworks from other 
> programming languages are.
> Would using Cython help boost the performance?
>

-- 
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/7173fb49-48d3-48c0-a711-0671af91d297%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[visualization-api] Capture selection event target and save locally for later event trigger

[jason . johns]

I'm using the Organizational Chart library to create a dynamic decision 
tree.

One part of the chart library is after adding a new data row, a redraw is 
necessary to apply the data to the visual graph.  When doing so, the visual 
identifier of an element selection is lost.  What I'd like to do is have 
some way to save the target select element to trigger a select event after 
redraw.

DataTable.getSelection() doesn't work here, since it returns data values, 
rather than the element

I can use jQuery(this), but that returns a jQuery wrapper for the target 
element, and I don't know how to extract out the data required to execute 
an event trigger.

Given

selectionHandler = google.visualization.events.addListener(orgChart, 
select, selectHandler);

orgChart.draw(data, {allowHtml : true, allowCollapse : true, nodeClass : 
questionClass});

How can I capture the select target to replace `this` in the example

google.visualization.events.trigger(this, 'select', null);



-- 
You received this message because you are subscribed to the Google Groups 
Google Visualization API group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-visualization-api+unsubscr...@googlegroups.com.
To post to this group, send email to google-visualization-api@googlegroups.com.
Visit this group at http://groups.google.com/group/google-visualization-api.
For more options, visit https://groups.google.com/groups/opt_out.

[visualization-api] Dynamic adds to Organization Chart not drawing past first child of root node.

[jason . johns]

I'm attempting to adapt Google's organization chart library to aid in the 
construction of a decision tree question workflow.

The tree creation workflow is

 1. Select Create New Tree button, root node of tree is created
 2. User inserts question text
  * Text is added to selected node via `setFormattedText()`
 3. User adds possible answers to question, which are added as child nodes 
of selected node.

and so on until the tree is complete.

My issue is only one child node can be added to the root node before the 
current selection object changes to undefined.

var orgChart, nodeCount;

var data, selection, selectionHandler;
var questionArray = [];
var answerText = ;

var question = {
  questionText : ,
  answers : [],

  clear : function(){
this.questionText = ;
this.answers = [];
  }
}

The drawFunction initializes the chart.  Each selection event is saved in a 
temporary variable, which is used to extract out the row/column information 
as well as other bits and pieces.

function drawChart() {
  orgChart = new 
google.visualization.OrgChart(document.getElementById(chart));
  data = new google.visualization.DataTable();
  data.addColumn(string, question);
  data.addColumn(string, parentQuestion);
  data.addColumn(string, tooltip);

  function selectHandler(){
selection = orgChart.getSelection()[0]
var value = data.getValue(selection.row, 0);
console.log(Selected Value:  + value);
populateData(value);
$(#question_text_input).trigger(focus);

  }

  selectionHandler = google.visualization.events.addListener(orgChart, 
select, selectHandler);
  orgChart.draw(data, {allowHtml : true, allowCollapse : true});
}

My save handlers are

function saveQuestionHandler(){

  questionArray.push(question);
  data.setFormattedValue(selection.row, 0, question.questionText);
  orgChart.draw(data, {allowHtml : true, allowCollapse : true});
}

function saveAnswerHandler(){
  question.answers.push(answerText);
  nodeCount++;

  $(#answers).append(li id =  + nodeCount +_ + 
question.answers.length +  class = 'answer'  + 
wiky.process(answerText) + /li);

  var count = data.addRow([{v : toString(nodeCount), f : answerText},   
data.getValue(selection.row, 0), null]);
  orgChart.draw(data, {allowHtml : true, allowCollapse : true});


  console.log(currentNode:  + nodeCount + \nparentNode:  + 
data.getValue(selection.row, 0) + 
Insertion Count  + count);
}

This code works for a single addition to the root node, but fails otherwise.

Now, there are two issues with the results.  First, the `saveAnswerHandler` 
is indeed firing, since the `append()` method is adding a new list item to 
the unordered list, but the `draw()` method is not responding to the new 
entries.

Second issue is if I click on the newly created child node, I get a 
`Selected Value : [Object Undefined]` entry.

Any help is appreciated.

-- 
You received this message because you are subscribed to the Google Groups 
Google Visualization API group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-visualization-api+unsubscr...@googlegroups.com.
To post to this group, send email to google-visualization-api@googlegroups.com.
Visit this group at http://groups.google.com/group/google-visualization-api.
For more options, visit https://groups.google.com/groups/opt_out.

RE: srm_env

[Jason Johns - SAS(IT)]

The same thing happens on both of my PWS 433au's. I've tried it with a
SRM flash that was about 5 years old(when I first got the machines, they
had been in use about 6 years) and with the most current flash. One box
is running 2.4.18 and the other is running 2.4.20. I cannot change any
of the srm environment variables.
The only way to get back to a srm prompt if boot is set to auto is to
reboot and hit control-p several times as soon as it says it's loading
aboot.

-Original Message-
From: Rich Payne [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 11, 2003 7:27 AM
To: Jan Lentfer
Cc: Debian Alpha
Subject: Re: srm_env




echo HALT /proc/srm_environment/etc..etc..

That should work (as root of course).

--rdp

On 12 Feb 2003, Jan Lentfer wrote:

 Hi all,

 I was playing around with the srm_env kernel module on my PWS 500.
 It there a way to actually change variables in /proc/srm_environment
 I tried to change auto_action to HALT with vi, which resulted in a
 machine freeze.
 When I booted back up all of my set variablse were lost (bootdef_dev,
 etc)

 TIA,

 Jan

 --
 Jan Lentfer
 System Administrator
 Molekulare Zellbiologie / AG Holstein, TU Darmstadt, Schnittspahnstr.
 10, 64287 Darmstadt



 --
 To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact
[EMAIL PROTECTED]


Rich Payne
http://talisman.mv.com
rdp at talisman dot mv dot com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
[EMAIL PROTECTED]

Video and NIC problems

[Jason Johns]

Hi,

I recently installed debian 2.2.r5 on my laptop and had a few problems with
my Video and NIC cards.  I have a SIS 630/730 card and a HAMR 5600 Voice
modem which I can use as a dialup or NIC card.  If anyone can help people
fix this it would be greatly appreciated.

Jason Johns
[EMAIL PROTECTED]
North Carolina, USA


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Video and NIC problems

[Jason Johns]

Hi,

I recently installed debian 2.2.r5 on my laptop and had a few problems with
my Video and NIC cards.  I have a SIS 630/730 card and a HAMR 5600 Voice
modem which I can use as a dialup or NIC card.  If anyone can help people
fix this it would be greatly appreciated.

Jason Johns
[EMAIL PROTECTED]
North Carolina, USA