Re: Async Caching

2020-09-27 Thread Adam Johnson
>
> I'm slightly confused by what you mean (and what the dep means).


I understand the DEP as saying that we'll implement the async methods in
the BaseCache class as backing onto the sync versions:

class BaseCache
async def get_async(...):
return await asgiref.sync_to_async(self.get)(*args, **kwargs)

This means that existing cache backends don't all need to be converted in
one go.

Also just saw https://forum.djangoproject.com/. Any preference for where
> future talks should be held: Google or that forum?
>

Essentially both are equivalent. I think there remain more readers on the
mailing list though, which can help if you're discussing bigger picture
things.

On Sun, 27 Sep 2020 at 04:30, Andrew Wang  wrote:

> Hey Adam and Andrew,
>
> I can definitely make the naming scheme something like get_async() rather
> than just get().
>
> > This section specifically says that the default implementations will
> back onto the sync methods by default, so built-in cache backends won't
> need to all be converted (at once?).
>
> I'm slightly confused by what you mean (and what the dep means). Are you
> saying in case someone is using a built-in cache backend like LocMem for
> local development and then an async third-party cache backend for
> production, then the code is like:
>
> class BaseCache:
> def get(...):
> NotImplementedError
> async def get_async(...):
> NotImplementedError
>
> class LocMemCache:
> def get(...):
> ...
> async def get_async(...):
> return await asgiref.sync_to_async(self.get)(*args, **kwargs)
>
> >  It could be informative to have a working backend using this interface,
> and if you encounter any edge cases whilst creating it.
>
> You can view my progress (once midterms are over :P) over here.
>  I'm planning on
> making the structure very similar to django-redis to make any migration
> process to an async Django easier. When I compared redis-py to aioredis,
> there weren't that many differences besides file structure (and passing the
> event loop around), so hopefully nothing weird pops up. But I will
> definitely post in this thread or in a ticket (if I do make a PR for
> BaseCache) if something odd does pop up.
>
> > The main work to do here is to work how quite how possible it is to
> offer all of them and if everything can be made to work regardless of what
> mode (sync or async) it's in
>
> In terms of the package or the other built-in backends or just everything
> in general like the ORM? If in terms of the package, most if not all
> methods would have to be awaited... I could also just be confusing all
> these words, so sorry about uhh me I guess!
>
> Also just saw https://forum.djangoproject.com/. Any preference for where
> future talks should be held: Google or that forum?
>
> Thanks for the suggestions! Have fun with the ORM!
> Andrew
> On Saturday, September 26, 2020 at 8:38:07 PM UTC-4 Andrew Godwin wrote:
>
>> Agreed - there's no work on caching inside Django yet, since the ORM is
>> my next focus, but I would definitely suggest writing a new pluggable
>> third-party backend that somehow provides async versions of the methods.
>>
>> The main work to do here is to work how quite how possible it is to offer
>> all of them and if everything can be made to work regardless of what mode
>> (sync or async) it's in; hopefully there's a lot less long-lived-connection
>> issues than in the ORM, say.
>>
>> Andrew
>>
>> On Sat, Sep 26, 2020, at 3:56 PM, Adam Johnson wrote:
>>
>> Hi Andrew
>>
>> I don't believe any work has started on async caching in core. However
>> there is a plan in DEP 9, the document that outlines how asynchronous
>> caching will work, using suffixed methods like get_async() etc. See
>> https://github.com/django/deps/blob/master/accepted/0009-async.rst#caching
>> . This section specifically says that the default implementations will back
>> onto the sync methods by default, so built-in cache backends won't need to
>> all be converted (at once?).
>>
>> I think a good start would be making your aioredis-based backend in a
>> third party package, using the future naming scheme `*_async`. It could be
>> informative to have a working backend using this interface, and if you
>> encounter any edge cases whilst creating it.
>>
>> Thanks,
>>
>> Adam
>>
>> On Sat, 26 Sep 2020 at 05:55, Andrew Wang  wrote:
>>
>> Hey guys, I'd like to contribute to the effort to make Django more async
>> capable. I've started to write an aioredis based cache backend based on
>> django-redis, but I noticed the BaseCache in Django is still all
>> synchronous basically.
>>
>> I was wondering which backends I should make async capable and how would
>> I go about it?
>>
>> I was thinking instead of creating a new class, we could just add the
>> async methods (e.g. add, get) to BaseClass. And for the FileBased, Dummy,
>> and LocMem backends, the plan would be the same? Problem with those

Django freelancing WhatsApp group

2020-09-27 Thread Divyesh Khamele
Hello all hope you are interested in joining:-

https://chat.whatsapp.com/FxBXbilF9vj3UJDIRaPSCP

Django Freelancing group.
Thanks

On Tue, 11 Aug 2020, 22:32 Desh Deepak,  wrote:

> Hello everyone, I want to developing a django project. Who wants to
> collaborate to do a project and learn django share your github user id for
> github reposetory access.
>
> Live on Heroku
> http://kidszania.herokuapp.com/
>
>
> Thanks
> Desh Deepak
> +91 7011101001
>
>
> --
> 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/CAJ0m4xi70WZ9ZsL4nBU3HmNU%2BZ8TLgNgL4BwAfS7%3DhxNZ-SxNg%40mail.gmail.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/CAEV-ETQPnwYK0vUksYdximpjG5-1Es7tDyfn_6%3DP7CsPpMFmCw%40mail.gmail.com.


Re: Fellow Reports -- September 2020

2020-09-27 Thread Carlton Gibson
Hi all. 


Calendar Week 39 -- ending 27 September.


Triaged:

https://code.djangoproject.com/ticket/32040 -- django.test encoding does 
not match 'utf-8' (needsinfo)
https://code.djangoproject.com/ticket/32036 -- stack overflow on admin save 
(invalid)
https://code.djangoproject.com/ticket/32035 -- AbstractUser.clean assumes 
default manager is named objects (needsinfo)
https://code.djangoproject.com/ticket/32033 -- No longer able to override 
DATA_UPLOAD_MAX_MEMORY_SIZE outside of settings.py (invalid)
https://code.djangoproject.com/ticket/32031 -- Add model instance to 
app_list context (Accepted)
https://code.djangoproject.com/ticket/32028 -- Top-level form rows (not 
stacked inlines etc.) are not aligned with the form title (Accepted)
https://code.djangoproject.com/ticket/32029 -- The responsive admin layout 
adds an ugly top margin to the second-to-last option of horizontal radio 
fields (Accepted)



Reviewed:

https://code.djangoproject.com/ticket/32041 -- Detected MIME types can 
easily be wrong on Windows
https://github.com/django/django/pull/13454 -- Fixed #32038 -- Fixed 
EmptyFieldListFilter crash with GenericRelation.
https://github.com/django/django/pull/13409 -- Fixed #31986 -- Fixed admin 
display issues.
https://code.djangoproject.com/ticket/27906 -- 
assertInHTML('', 
'') fails
https://github.com/django/django/pull/13448 -- Fixed #32012 -- Made test 
database creation sync apps models when migrations are disabled.
https://github.com/django/django/pull/13436 -- Fixed #30231 -- Fixed 
FilteredSelectMultiple widget verbose_name usage
https://github.com/django/django/pull/13425 -- Fixed #32004 -- Clarified 
docs for when request.FILES is set.
https://github.com/django/django/pull/13445 -- Corrected docstring quotes 
in various code.
https://github.com/django/django/pull/13432 -- Made indexes tests use 
required_db_features.



Authored:

https://github.com/django/django/pull/13446 -- Fixed #32016 -- Clarified 
manual logging config docs.


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/446aa2c4-bfc4-41e4-9798-8be669b66f68n%40googlegroups.com.


Found a bug related with admin panel, m2m-field and model save() method

Methods associated with m2m (clear, set) fields do not work in the save () 
method of the model using from the admin panel.
The error did not occur when instantiation or update was initiated from 
other sources (wrapper, control command api) 

Details (test project with instructions to reproduction) here:

https://github.com/Sibiryakanton/Django_bugcase


-- 
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/19d90b6b-1ce5-420a-936a-8f4b7380f312n%40googlegroups.com.


Re: Allow disabling choices in a

@tony thanks this realy helped me!

On Tuesday, 1 May 2018 at 01:33:19 UTC+2 tony...@gmail.com wrote:

> This might be a late answer but this is a simplified version that can be 
> modified using the form instance.
>
> You can either pass a list of values to be disabled i.e
>
> def __init__(self, disabled_choices, *args, **kwargs):
> self.disabled_choices = disabled_choices
>
> OR
> 
> from django.forms import Select
> 
> 
> class SelectWidget(Select):
> """
> Subclass of Django's select widget that allows disabling options.
> """
> def __init__(self, *args, **kwargs):
> self._disabled_choices = []
> super(SelectWidget, self).__init__(*args, **kwargs)
> 
> @property
> def disabled_choices(self):
> return self._disabled_choices
> 
> @disabled_choices.setter
> def disabled_choices(self, other):
> self._disabled_choices = other
> 
> def create_option(self, name, value, label, selected, index, subindex=
> None, attrs=None):
> option_dict = super(SelectWidget, self).create_option(
> name, value, label, selected, index, subindex=subindex, attrs=
> attrs
> )
> if value in self.disabled_choices:
> option_dict['attrs']['disabled'] = 'disabled'
> return option_dict
>
>
> To disabled an option based on a condition i.e user isn't a superuser.
> 
> class MyForm(forms.Form):
> status = forms.ChoiceField(required=True, widget=SelectWidget, choices
> =Status.choices())
> 
> def __init__(self, request, *args, **kwargs):
> if not request.user.is_superuser:
> self.fields['status'].widget.disabled_choices = [1, 4]
> super().__init__(*args, **kwargs)
>
>
> On Friday, June 3, 2011 at 12:50:12 PM UTC-4, Jody McIntyre wrote:
>>
>> We need to be able to disable choices in a , which is done by 
>> setting the disabled attribute on the  tag, for example:
>> Bananas
>>
>>  Currently we're doing this by subclassing the Select widget: 
>> http://djangosnippets.org/snippets/2453/
>>
>> It would be nice if the built in Select widget supported this.  One way 
>> would be to replace the existing render_option method with what I've 
>> written, and I can prepare a patch if desired, but this approach changes 
>> the format of the "choices" data structure to something that won't be 
>> understood by other widgets.  Perhaps these widgets should be improved too, 
>> but I don't want to do this unless my changes have a good chance of being 
>> accepted.
>>
>> I logged this as a ticket (16149) and was told to discuss it here.  To 
>> address aagustin's comments:
>>
>> 1. Backwards compatibility is already addressed.  If the widget is passed 
>> a regular "choices" field, the existing behavior is preserved.
>>
>> 2. I don't understand what you mean by "boilerplate" in the API.  A 
>> "choices" field with a disabled choice looks like:
>>
>> choices = (('apples', 'Apples'),
>>('oranges', 'Oranges'),
>>('bananas', {'label': 'Bananas',
>> 'disabled': True}),
>>('grobblefruit', 'Grobblefruit'))
>>
>> I can't think of a more concise way of clearly representing that 
>> 'bananas' is disabled while still allowing it to have a label, unless we 
>> want to change the "choices" data structure a lot more to something like:
>>
>> choices = (('apples', 'Apples'),
>>('oranges', 'Oranges'),
>>('bananas', 'Bananas',  {'disabled': True}),
>>('grobblefruit', 'Grobblefruit'))
>>
>> Suggestions & other thoughts welcome :)
>> Jody
>>
>

-- 
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/5b35106d-cc38-461a-9126-7ca6c4f11a7an%40googlegroups.com.


Re: Found a bug related with admin panel, m2m-field and model save() method

I believe the behaviour you're seeing is due to the fact that the admin 
view first has to save the instance of the model being edited, and only 
then can it save the related objects and relationships. So it is a two-step 
thing:
https://github.com/django/django/blob/84609b3205905097d7d3038d32e6101f012c0619/django/contrib/admin/options.py#L1584-L1585

Not sure if it is a bug, though. Perhaps it can be documented (if it 
isn't). Something like "If you are overriding MyModel.save (or using 
post_save signal?), be aware that the admin ..."?


On Sunday, 27 September 2020 at 21:28:13 UTC+2 antoni...@gmail.com wrote:

> Methods associated with m2m (clear, set) fields do not work in the save () 
> method of the model using from the admin panel.
> The error did not occur when instantiation or update was initiated from 
> other sources (wrapper, control command api) 
>
> Details (test project with instructions to reproduction) here:
>
> https://github.com/Sibiryakanton/Django_bugcase
>
>
>

-- 
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/1c6ad952-0105-4c31-84b2-43afa6c8e126n%40googlegroups.com.


Re: Async Caching

Cool, thanks for the clarification. One thing I noticed while programming 
the test cases (so WIP is 
here: https://github.com/Andrew-Chen-Wang/django-async-redis) is that it's 
not really fun having to type out get_async since autocomplete. If a dev 
knows that they'll be using an await, then I think it's best if everything 
is prefixed with async_* rather than suffixed. Thoughts?

As a side note, the only other change that would need to happen is in 
django.core.cache close_caches AFAIK.

Andrew 

On Sunday, September 27, 2020 at 3:30:56 AM UTC-4 Adam Johnson wrote:

> I'm slightly confused by what you mean (and what the dep means). 
>
>
> I understand the DEP as saying that we'll implement the async methods in 
> the BaseCache class as backing onto the sync versions:
>
> class BaseCache
> async def get_async(...):
> return await asgiref.sync_to_async(self.get)(*args, **kwargs)
>
> This means that existing cache backends don't all need to be converted in 
> one go.
>
> Also just saw https://forum.djangoproject.com/. Any preference for where 
>> future talks should be held: Google or that forum?
>>
>
> Essentially both are equivalent. I think there remain more readers on the 
> mailing list though, which can help if you're discussing bigger picture 
> things.
>
> On Sun, 27 Sep 2020 at 04:30, Andrew Wang  wrote:
>
>> Hey Adam and Andrew,
>>
>> I can definitely make the naming scheme something like get_async() rather 
>> than just get().
>>
>> > This section specifically says that the default implementations will 
>> back onto the sync methods by default, so built-in cache backends won't 
>> need to all be converted (at once?).
>>
>> I'm slightly confused by what you mean (and what the dep means). Are you 
>> saying in case someone is using a built-in cache backend like LocMem for 
>> local development and then an async third-party cache backend for 
>> production, then the code is like:
>>
>> class BaseCache:
>> def get(...):
>> NotImplementedError
>> async def get_async(...):
>> NotImplementedError
>>
>> class LocMemCache:
>> def get(...):
>> ...
>> async def get_async(...):
>> return await asgiref.sync_to_async(self.get)(*args, **kwargs)
>>
>> >  It could be informative to have a working backend using this 
>> interface, and if you encounter any edge cases whilst creating it.
>>
>> You can view my progress (once midterms are over :P) over here. 
>>  I'm planning on 
>> making the structure very similar to django-redis to make any migration 
>> process to an async Django easier. When I compared redis-py to aioredis, 
>> there weren't that many differences besides file structure (and passing the 
>> event loop around), so hopefully nothing weird pops up. But I will 
>> definitely post in this thread or in a ticket (if I do make a PR for 
>> BaseCache) if something odd does pop up.
>>
>> > The main work to do here is to work how quite how possible it is to 
>> offer all of them and if everything can be made to work regardless of what 
>> mode (sync or async) it's in
>>
>> In terms of the package or the other built-in backends or just everything 
>> in general like the ORM? If in terms of the package, most if not all 
>> methods would have to be awaited... I could also just be confusing all 
>> these words, so sorry about uhh me I guess!
>>
>> Also just saw https://forum.djangoproject.com/. Any preference for where 
>> future talks should be held: Google or that forum?
>>
>> Thanks for the suggestions! Have fun with the ORM!
>> Andrew
>> On Saturday, September 26, 2020 at 8:38:07 PM UTC-4 Andrew Godwin wrote:
>>
>>> Agreed - there's no work on caching inside Django yet, since the ORM is 
>>> my next focus, but I would definitely suggest writing a new pluggable 
>>> third-party backend that somehow provides async versions of the methods.
>>>
>>> The main work to do here is to work how quite how possible it is to 
>>> offer all of them and if everything can be made to work regardless of what 
>>> mode (sync or async) it's in; hopefully there's a lot less 
>>> long-lived-connection issues than in the ORM, say.
>>>
>>> Andrew
>>>
>>> On Sat, Sep 26, 2020, at 3:56 PM, Adam Johnson wrote:
>>>
>>> Hi Andrew
>>>
>>> I don't believe any work has started on async caching in core. However 
>>> there is a plan in DEP 9, the document that outlines how asynchronous 
>>> caching will work, using suffixed methods like get_async() etc. See 
>>> https://github.com/django/deps/blob/master/accepted/0009-async.rst#caching 
>>> . This section specifically says that the default implementations will back 
>>> onto the sync methods by default, so built-in cache backends won't need to 
>>> all be converted (at once?).
>>>
>>> I think a good start would be making your aioredis-based backend in a 
>>> third party package, using the future naming scheme `*_async`. It could be 
>>> informative to have a working backend usi

Re: Async Caching

So the debate between async_foo and foo_async has not really happened yet; I'm 
really split on the choice. As you say, async_foo allows you to get to the 
async versions quicker, but foo_async allows you to start your typing with the 
operation you're doing and then select the variant.

I think right now I would prefer get_async all things considered, since I don't 
think autocomplete is necessarily easier either way, but I'm open to 
suggestions.

Andrew

On Sun, Sep 27, 2020, at 6:03 PM, Andrew Wang wrote:
> Cool, thanks for the clarification. One thing I noticed while programming the 
> test cases (so WIP is here: 
> https://github.com/Andrew-Chen-Wang/django-async-redis) is that it's not 
> really fun having to type out get_async since autocomplete. If a dev knows 
> that they'll be using an await, then I think it's best if everything is 
> prefixed with async_* rather than suffixed. Thoughts?
> 
> As a side note, the only other change that would need to happen is in 
> django.core.cache close_caches AFAIK.
> 
> Andrew 
> On Sunday, September 27, 2020 at 3:30:56 AM UTC-4 Adam Johnson wrote:
>>> I'm slightly confused by what you mean (and what the dep means).
>> 
>> I understand the DEP as saying that we'll implement the async methods in the 
>> BaseCache class as backing onto the sync versions:
>> 
>> class BaseCache
>> 
>> async def get_async(...):
>> return await asgiref.sync_to_async(self.get)(*args, **kwargs)
>> 
>> This means that existing cache backends don't all need to be converted in 
>> one go.
>> 
>>> Also just saw https://forum.djangoproject.com/. Any preference for where 
>>> future talks should be held: Google or that forum?
>> 
>> Essentially both are equivalent. I think there remain more readers on the 
>> mailing list though, which can help if you're discussing bigger picture 
>> things.
>> 
>> 
>> On Sun, 27 Sep 2020 at 04:30, Andrew Wang  wrote:
>>> Hey Adam and Andrew,
>>> 
>>> I can definitely make the naming scheme something like get_async() rather 
>>> than just get().
>>> 
>>> > This section specifically says that the default implementations will back 
>>> > onto the sync methods by default, so built-in cache backends won't need 
>>> > to all be converted (at once?).
>>> 
>>> I'm slightly confused by what you mean (and what the dep means). Are you 
>>> saying in case someone is using a built-in cache backend like LocMem for 
>>> local development and then an async third-party cache backend for 
>>> production, then the code is like:
>>> 
>>> class BaseCache:
>>> def get(...):
>>> NotImplementedError
>>> async def get_async(...):
>>> 
>>> NotImplementedError
>>> 
>>> class LocMemCache:
>>> def get(...):
>>> ...
>>> async def get_async(...):
>>> return await asgiref.sync_to_async(self.get)(*args, **kwargs)
>>> 
>>> >  It could be informative to have a working backend using this interface, 
>>> > and if you encounter any edge cases whilst creating it.
>>> 
>>> You can view my progress (once midterms are over :P) over here. 
>>>  I'm planning on 
>>> making the structure very similar to django-redis to make any migration 
>>> process to an async Django easier. When I compared redis-py to aioredis, 
>>> there weren't that many differences besides file structure (and passing the 
>>> event loop around), so hopefully nothing weird pops up. But I will 
>>> definitely post in this thread or in a ticket (if I do make a PR for 
>>> BaseCache) if something odd does pop up.
>>> 
>>> > The main work to do here is to work how quite how possible it is to offer 
>>> > all of them and if everything can be made to work regardless of what mode 
>>> > (sync or async) it's in
>>> 
>>> In terms of the package or the other built-in backends or just everything 
>>> in general like the ORM? If in terms of the package, most if not all 
>>> methods would have to be awaited... I could also just be confusing all 
>>> these words, so sorry about uhh me I guess!
>>> 
>>> Also just saw https://forum.djangoproject.com/. Any preference for where 
>>> future talks should be held: Google or that forum?
>>> 
>>> Thanks for the suggestions! Have fun with the ORM!
>>> Andrew
>>> On Saturday, September 26, 2020 at 8:38:07 PM UTC-4 Andrew Godwin wrote:
 __
 Agreed - there's no work on caching inside Django yet, since the ORM is my 
 next focus, but I would definitely suggest writing a new pluggable 
 third-party backend that somehow provides async versions of the methods.
 
 The main work to do here is to work how quite how possible it is to offer 
 all of them and if everything can be made to work regardless of what mode 
 (sync or async) it's in; hopefully there's a lot less 
 long-lived-connection issues than in the ORM, say.
 
 Andrew
 
 On Sat, Sep 26, 2020, at 3:56 PM, Adam Johnson wrote:
> Hi Andrew
> 
> I don't believe any work has st