Re: Digest for django-developers@googlegroups.com - 1 update in 1 topic

[Asif Saif Uddin]

I just want to share my 2 cents...

Oracle is highly used in government and big Corporations in my country and
banks and many critical places.

So while the number of django user of oracle might be low, the prospect of
introducing python and django to a legacy project is invaluable.

I personally know this from work experience. But on the  other hand, we
should also consider future maintenance experts for oracle backend. I
believe with some guidelines and help From current oracle backend
maintainers would help to pass the knowledge to new prospective future
contributors.

Best regards to all of you.
Asif

On Mon, 28 Aug 2023, 9:40 am ,  wrote:

> django-developers@googlegroups.com
> 
>  Google
> Groups
> 
> 
> Topic digest
> View all topics
> 
>
>- Proposing the removal of Oracle from the Django supported backend
>databases <#m_2265663842392659825_group_thread_0> - 1 Update
>
> Proposing the removal of Oracle from the Django supported backend
> databases
> 
> David Sanders : Aug 28 01:10AM +1000
>
> I posted a thread a while back about the latest version of Oracle 23c which
> appears to add support for a few things that would fix some of the
> workarounds we have in the ORM (eg boolean expressions). I know dropping
> 19c is a long way off but at least the future is looking brighter 
>
> On Wed, 9 Aug 2023, 6:40 pm Carlton Gibson, 
> wrote:
>
> Back to top <#m_2265663842392659825_digest_top>
> You received this digest because you're subscribed to updates for this
> group. You can change your settings on the group membership page
> 
> .
> To unsubscribe from this group and stop receiving emails from it send an
> email to django-developers+unsubscr...@googlegroups.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/CAKAqTgqDaApZBQ9077bZjBzdyabQjX9T_Ama5wykD8CJDy%2BYYA%40mail.gmail.com.

Re: Proposal of standardize of reverse foreign key and m2m

[Asif Saif Uddin]

I get the following error while visiting the link 

Websites prove their identity via certificates, which are valid for a set 
time period. The certificate for code.djangoproject.com expired on 2/3/2022.
 
Error code: SEC_ERROR_EXPIRED_CERTIFICATE
 
On Thursday, February 3, 2022 at 2:17:33 AM UTC+6 al...@interia.eu wrote:

> Hi,
>
> I am working on ticket https://code.djangoproject.com/ticket/19580
> https://github.com/django/django/pull/15318
>
> Currently (in the patch) unsaved object raises error when trying to use 
> reverse foreign key or m2m relation. (Change in FK in patch)
>
> Other issue that is worth to consider is when saved object has nullable 
> referenced field.
>
> class Manufacturer(models.Model):
> name = models.CharField(max_length=100, null=True, blank=True, unique=True)
>
> class Car(models.Model):
> manufacturer = models.ForeignKey(Manufacturer, null=True, blank=True, 
> to_field="name")
>
> Car().save()
> m = Manufacturer()
> m.save()
> m.car_set.all() # returns empty QuerySet 
>
> but when we try call on this relation methods 
> add/get_or_create/remove/clear it raises ValueError like M2M (Change in FK 
> in patch)
>
> Same case with M2M
>
> class Pizza(models.Model):
> name = models.CharField(max_length=100, null=True, blank=True)
>
> class Topping(models.Model):
> pizzas = models.ManyToMany(Pizza, through="PizzaTopping")
>
> class PizzaTopping(models.Model):
> pizza = models.ForeignKey(Pizza, null=True, blank=True, to_field="name")
> topping = models.ForeignKey(Topping)
>
> Topping().save()
> p = Pizza()
> p.save()
> p.topping_set().all() # raise ValueError "" needs 
> to have a value for field "name" before this many-to-many relation can be 
> used.
>
> Implementation of M2M seems to be correct because behavior is consistent - 
> in every case when value of referenced field is None it raises error.
> See comment in similar ticket (10 years old) 
> https://code.djangoproject.com/ticket/17541#comment:8
>
> I am in doubt if suggested in the ticket solution is correct (it is 9 
> years old) because in most cases it will raise error but only when there is 
> an attempt to use query there is empty QuerySet returned.
> Proposal is to raise error instead return empty QuerySet in Foreign Key 
> like M2M does.
>
> Albert
>

-- 
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/db44ce9e-6765-469d-a359-7981d7558ec9n%40googlegroups.com.

Re: Developing an SPA version of Django admin

[Asif Saif Uddin]

Hi guys,
the django admin still need to dogfood many new django features. we can 
start with that. for reference you can check django-admin2.

thanks,
Asif

On Sunday, October 17, 2021 at 2:36:16 AM UTC+6 Christian González wrote:

> Hello,
>
> my 2 cents here. I've searched for years to find "the right" frontend for 
> Django. Tried, React, Angular, Vue, Svelte, and many others, even developed 
> GDAPS, a Django plugin system with flexible optional frontend integration 
> optionally (Vue only ATM - but the frontend integration is stuck, read 
> below why), and almost got crazy. I ended up in forgetting all the frontend 
> frameworks altogether as they all are completely un-pythonic and 
> un-djangoish, get into your way and force you to re-write everything you 
> already had working.You have to write all the logic of views again in your 
> frontend of choice, and well, do the validation *again* in the backend. So 
> everything gets more complex, with the "benefit" of getting a few 
> milliseconds and fewer round trips. It's just "cooler". 
>
> Oh, and yes, forget Django's template language. In the best case the 
> frontend barks at it and you have to define own variable delimiters (Vue) 
> if mixed into the templates, or it isn't even possible to use it without 
> getting into big trouble. You'll end up defining a separate project, and 
> using REST or GraphQL for communication with Django. Additionally you have 
> to throw webpack, rollup, parcel, or any other bundler of your choice into 
> the mix. Which then won't like your non-admin-frontend.
>
> What I ended with, and that has none of those disadvantages, is *HTMX*. 
> Keep your views, keep your templates, keep your validations/validators, 
> render everything serverside, just salt the html templates with some HTMX 
> attrs where needed. Works almost perfectly, and even could be added 
> incrementally.
>
> If I would develop a better Django admin, I'd go for HTMX. (and I tried 
> Sockpuppet, Unicorn, and many others too.)
> If it was for me, I even would add a neat HTMX integration to Django core.
>
> Cheers, Christian
>
>
> Am 15.10.21 um 08:52 schrieb Warren Havemann:
>
> Hi everyone,
>
> I've been contemplating the development of an SPA version of admin either 
> in Angular, React, Vue or even Flutter... preferably in Angular due to it's 
> data binding approach.
>
> The idea is to serve the SPA from Django, dynamically generating it so 
> that the great model based apps that one can create with the current admin 
> site can be dynamically generated in a similar way, but as an SPA.  Why 
> SPA.. just to enable a better, more powerful user experience without the 
> round trips and page reloads.   
>
> Hoping it will in the same way form a RAD tool for SPA development with a 
> Django back-end.
>
> If we get really smart, we may be able to make it theme-able.
>
> I have messaged the django dev group as I have had a look at the work that 
> may be involved and I believe that if we we're to succeed in making this a 
> standard addition to django as an admin alternative, we make have to 
> accommodate it in the code a bit... there may be a bit of refactoring of 
> the admin code. 
>
> Just wondering if anyone would be up for joining me in creating something 
> like this?... or if you know of an existing project trying to do this?
>
> Thanks
> Warren
>
> -- 
> 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/c29b745c-21d5-46c8-ab51-312b1a73114dn%40googlegroups.com
>  
> 
> .
>
> -- 
> Dr. Christian Gonzálezhttps://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/04da2824-b615-48fb-9ae5-562e3d9c5125n%40googlegroups.com.

Re: Working towards a simpler GCBV implementation?

[Asif Saif Uddin]

all good new things were disruptive in django no matter what. urls and 
paths existed but the newer approach were recommended for new projects. the 
current GCBV are not so simple.

On Tuesday, January 3, 2017 at 7:20:24 PM UTC+6 Adam Johnson wrote:

> I think this is probably too disruptive a change for Django core, 
> especially after so long with the current GCBV implementations - it would 
> require all users to rewrite their CBV's. Possibly the documentation could 
> recommend django-vanilla-views?
>
> On 3 January 2017 at 13:02, Asif Saifuddin  wrote:
>
>> Hi,
>>
>> I have started work on https://github.com/django/django/pull/7783 for 
>> converting django built in generic views to django-vanilla-views.
>>
>> I would like to hear what you think before I proceed for more.
>>
>> Thanks,
>>
>> Asif
>>
>> On Friday, September 16, 2016 at 1:37:36 AM UTC+6, Asif Saifuddin wrote:
>>>
>>> Hi Tom,
>>>
>>> I am basically +1 to see this change in the django core. The package is 
>>> 3 years old and should be tested enough. If you/other core team members 
>>> thinks that now is a good time to include it to core and deprecation of 
>>> older API, then I will be willing to work and send PR for this.
>>>
>>> Looking for others opinions.
>>>
>>> Thanks,
>>>
>>> Asif
>>>
>>> On Thursday, October 3, 2013 at 3:09:58 PM UTC+6, Tom Christie wrote:

 Hi folks,

 I recently released an alternative implementation of Django's existing 
 class based views.  The intention was to mirror the *exact* same set of 
 functionality that we currently provide, but simplify the implementation 
 and API.  It's nothing cleverer or grander than a clean re-write, but the 
 end result is *significantly* less complex.  The class hierarchy is 
 trivial, the API is much smaller, and the flow control is much more 
 obvious.

 I won't go into any more here, as there's plenty of detail in the 
 documentation:

 http://django-vanilla-views.org

 There's also useful context in the related blog post, here:

 http://dabapps.com/blog/fixing-djangos-generic-class-based-views/

 The difficult thing here really is that there's no obvious approach to 
 introducing something like this in a backwards compatible way.

 It might be that we could take an incremental approach using the 
 standard deprecation process, but given the nature of the GCBVs it'd 
 likely 
 be pretty awkward.
 There might be some bits of deprecation process we simply wouldn't be 
 able to deal with in any sensible way, and we'd certainly end up with a 
 seriously gnarly implementation during the deprecation period.

 I'd be interested in getting some opinions from folks on the following:

 * If a simpler GCBV implementation along the lines of 
 django-vanilla-views is something we think we should working towards.
 * What approaches we might be able to take to dealing with backwards 
 compatibility if we did want to do so.

 Thanks for your time.

   Tom

 -- 
>> 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/5792872e-157c-4ba6-87c1-bf0f5a07d981%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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/261b0ef2-ca18-4547-b9c6-27ba96a702aen%40googlegroups.com.

Re: Working towards a simpler GCBV implementation?

[Asif Saif Uddin]

IMHO, we can include vanilna views like simpler implementations for GCBV 
and may be ViewSets As well. extensively document the old iplementations to 
newer implementations, and not deprecating the current implementations that 
early. they way django regex_based url was converted to sipler path() based 
url routing, that could be a good path for this.

Best,
Asif

On Wednesday, January 11, 2017 at 6:10:22 PM UTC+6 James Bennett wrote:

> Please read Florian's message. 2.0 is not going to be "we bumped the major 
> version, now we can pile in lots of breaking changes".
>

-- 
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/096772bd-108d-44e6-b2a5-b3f88548f791n%40googlegroups.com.

Re: Django ORM query syntax enhancement

[Asif Saif Uddin]

Hi Adam,

I agree with some of your points. however djngo orm query syntax is the 
main pain point for anyone new to django orm.  The reason those packages 
are not widely used is because most people dont know about them and not 
about this DEP. And most new users mainly end up learning built in query 
syntax. not many know much about these Deps and orm syntactic sugars.

If some movement were seen in this front and advocacy then probably there 
will be more attention to syntactic sugar packages. The orm sugar package 
is still works in production with django orm as well. So it would be great 
to see the Dep could be improved based on the both packages good parts.

I think I should try to  write some blogs as well using those packages.

Best,
Asif
On Wednesday, October 6, 2021 at 3:55:58 PM UTC+6 Adam Johnson wrote:

> I would not be for merging anything into Django at this time.
>
> There are several libraries providing "enhanced" query syntax: 
> django-orm-sugar, django-model-values, and django-natural-query. None of 
> them seems to be particularly popular (<100 github stars, minimal PyPI 
> downloads), and only django-model-values is maintained. Moreover they all 
> achieve their goals without any changes to Django, so there's not much of a 
> compelling reason to merge anything to core.
>
> To consider adding "another way to do things" in the ORM we'd want more 
> evidence that users want it. I'd suggest further contributions and advocacy 
> for django-model-values or similar. Its documentation could definitely be 
> improved, and blog posts could promote its advantages.
>
> On Wed, 6 Oct 2021 at 10:13, Asif Saif Uddin  wrote:
>
>> Hey all,
>>
>> can we have some consensus on this?
>>
>> Asif
>>
>> On Saturday, April 1, 2017 at 12:55:27 PM UTC+6 Alexey Zankevich wrote:
>>
>>> Hey all,
>>>
>>> Please check a draft DEP related to external query language support by 
>>> Django ORM https://github.com/django/deps/pull/40. 
>>>
>>> Regards,
>>> Alexey
>>>
>>>
>>> On Wednesday, March 22, 2017 at 10:07:51 AM UTC+3, Asif Saifuddin wrote:
>>>>
>>>> Hi Aric,
>>>>
>>>> I checked your package. it's nice too. thanks for the work.
>>>>
>>>> Asif
>>>>
>>>> On Monday, October 17, 2016 at 4:38:26 AM UTC+6, Aric Coady wrote:
>>>>>
>>>>> +1.  I implemented much the same thing for part of django-model-values 
>>>>> <https://pypi.python.org/pypi/django-model-values/>, but went with F 
>>>>> expressions 
>>>>> <http://pythonhosted.org/django-model-values/reference.html#f> as the 
>>>>> basis instead.  Primarily because F expressions already support operator 
>>>>> overloading and are a natural intermediate object;  from there one can 
>>>>> create Q, OrderBy, and Func objects.
>>>>>
>>>>> In []: from model_values import F
>>>>>
>>>>> In []: F.user.created
>>>>> Out[]: FExpr(user__created)
>>>>>
>>>>> In []: F.user.created >= 0
>>>>> Out[]: 
>>>>>
>>>>> In []: F.user.created.min()
>>>>> Out[]: Min(FExpr(user__created))
>>>>>
>>>>> In []: -F.user.created
>>>>> Out[]: OrderBy(FExpr(user__created), descending=True)
>>>>>
>>>>> In []: F.text.iexact('...')
>>>>> Out[]: 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thursday, October 6, 2016 at 10:04:56 AM UTC-7, Alexey Zankevich 
>>>>> wrote:
>>>>>>
>>>>>> Hey all,
>>>>>>
>>>>>> Just want to announce recent changes in Django ORM Sugar library, 
>>>>>> which might be useful in future Django query syntax enhancement (if ever 
>>>>>> happens).
>>>>>> 1. Now it supports indexes and slices:
>>>>>>
>>>>>> >>> Q.data.owner.other_pets[0].name='Fishy'
>>>>>> Q(data__owner__other_pets__0__name='Fishy')
>>>>>> >>> Q.tags[0] == 'thoughts'
>>>>>> Q(tags__0='thoughts')
>>>>>> >>> Q.tags[0:2].contains(['thoughts']) 
>>>>>> Q(tags__0_2__contains=['thoughts'])
>>>>>>
>>>>>>
>>>>>> 2. Previously, it was only possible to call defined method (like it 
>>>>>> is done for *is_not_null()* functi

Re: Django ORM query syntax enhancement

[Asif Saif Uddin]

Hey all,

can we have some consensus on this?

Asif

On Saturday, April 1, 2017 at 12:55:27 PM UTC+6 Alexey Zankevich wrote:

> Hey all,
>
> Please check a draft DEP related to external query language support by 
> Django ORM https://github.com/django/deps/pull/40. 
>
> Regards,
> Alexey
>
>
> On Wednesday, March 22, 2017 at 10:07:51 AM UTC+3, Asif Saifuddin wrote:
>>
>> Hi Aric,
>>
>> I checked your package. it's nice too. thanks for the work.
>>
>> Asif
>>
>> On Monday, October 17, 2016 at 4:38:26 AM UTC+6, Aric Coady wrote:
>>>
>>> +1.  I implemented much the same thing for part of django-model-values 
>>> , but went with F 
>>> expressions 
>>>  as the 
>>> basis instead.  Primarily because F expressions already support operator 
>>> overloading and are a natural intermediate object;  from there one can 
>>> create Q, OrderBy, and Func objects.
>>>
>>> In []: from model_values import F
>>>
>>> In []: F.user.created
>>> Out[]: FExpr(user__created)
>>>
>>> In []: F.user.created >= 0
>>> Out[]: 
>>>
>>> In []: F.user.created.min()
>>> Out[]: Min(FExpr(user__created))
>>>
>>> In []: -F.user.created
>>> Out[]: OrderBy(FExpr(user__created), descending=True)
>>>
>>> In []: F.text.iexact('...')
>>> Out[]: 
>>>
>>>
>>>
>>>
>>> On Thursday, October 6, 2016 at 10:04:56 AM UTC-7, Alexey Zankevich 
>>> wrote:

 Hey all,

 Just want to announce recent changes in Django ORM Sugar library, which 
 might be useful in future Django query syntax enhancement (if ever 
 happens).
 1. Now it supports indexes and slices:

 >>> Q.data.owner.other_pets[0].name='Fishy'
 Q(data__owner__other_pets__0__name='Fishy')
 >>> Q.tags[0] == 'thoughts'
 Q(tags__0='thoughts')
 >>> Q.tags[0:2].contains(['thoughts']) 
 Q(tags__0_2__contains=['thoughts'])


 2. Previously, it was only possible to call defined method (like it is 
 done for *is_not_null()* function) or registered with decorator. Now 
 if you try to call unknown function of sugar Q, it will internally pass 
 function name and append it as *__functionname *to lookup field:

 >>> Q.user.username.contains('Rodriguez')
 Q(user__username__contains='Rodriguez')


 There is no such function "contains" anymore in sugar Q, however, it 
 just adds *__contains* to lookup field and passes parameter to it.

 3. It will pass a tuple to lookup if multiple arguments passed:

 >>> Q.user.create_datetime.range(d1, d2)
 Q(user__create_datetime__range=(d1, d2))


 I think the library is at the final state now and isn't going to get 
 new substantial features, but responses are highly appreciated.

 Regards,
 Alexey


 On Sunday, August 16, 2015 at 4:18:26 PM UTC+3, Alexey Zankevich wrote:
>
> Hi all,
>
> This topic is related to the current ORM query syntax with underscores.
> There are lots of arguing related to it, anyway it has pros and cons.
>
> Let's take a concrete example of querying a model:
>
> >>> 
> GameSession.objects.filter(user__profile__last_login_date__gte=yesterday)
>
>
> Pros:
>
> 1. The syntax is easy to understand
> 2. Can be extended with custom transforms and lookups
>
> However, there are several cons:
>
> 1. Long strings is hard to read, especially if we have fields with 
> underscores.
> It's really easy to make a mistake by missing one:
>
> >>> 
> GameSession.objects.filter(user_profile__last_login_date__gte=yesterday)
>
> Not easy to catch missing underscore between user and profile, is it? 
> Even
> though, it's not easy to say whether it should be "user_profile" 
> attribute or
> user.profile foreign key.
>
> 2. Query strings can't be reused, thus the approach violates DRY 
> principle.
> For example, we need to order results by last_login_date:
>
> >>> 
> GameSession.objects.filter(user__profile__last_login_date__gte=yesterday) 
> \
> .order_by('user__profile__last_login_date')
>
> We can't keep user__profile_login_date as a variable as in the first 
> part of the
> expression we use a keyword argument, meanwhile in the second part - 
> just a 
> string. And thus we just have to type query path twice.
>
> 3. Lookup names not natural to Python language and require to be 
> remembered or
> looked up in documentation. For example, "__gte" or "__lte" lookups 
> tend to be
> confused with "ge" and "le" due to similarity to methods "__ge__" and 
> "__le__".
>
> 4. Lookup keywords limited to a single argument only, very 
> inconvenient when
> necessary to filter objects by range.
>
> I was thinking a lot trying to solve those issues, keeping in mind 
> Django

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

[Asif Saif Uddin]

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-developers+unsubscr...@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.

Re: Remove automatic date-naming of migrations (00XX_auto_YYYMMDD)

[Asif Saif Uddin]

I Like the idea of Claude.
Asif

On Wednesday, April 22, 2020 at 7:23:22 PM UTC+6, Claude Paroz wrote:
>
> Le mercredi 22 avril 2020 15:06:12 UTC+2, Adam Johnson a écrit :
>>
>> I'd like to propose using this new full coverage of operation naming to 
>> remove the "auto_MMDD" behaviour, and instead always combine 
>> operations' "suggested migration names" up until a limit of say 60 
>> characters. I made a commit for that here: 
>> https://github.com/adamchainz/django/commit/c2bc6893a05c2c8099e1fb68e688618446641ed6
>> ...
>> Mariusz wrote on the PR:
>>
>> Personally, I'm against removing auto named migrations. IMO chaining 
>>> operation names is even more confusing.  
>>>
>>
> An alternative could be to ask the user in interactive mode (and keep the 
> current behaviour in non-interactive mode).
>
> 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/0bf74280-1620-4954-9629-3fd52d9a8b1e%40googlegroups.com.

Re: Psycopg3 Redesign

[Asif Saif Uddin]

Report:

https://www.varrazzo.com/blog/2020/03/26/psycopg3-first-report/

./auvipy

On Wednesday, March 11, 2020 at 9:06:21 PM UTC+6, Andrew Godwin wrote:
>
> I am particularly excited for native async support arriving - that's 
> something I'd love to have and ship support for from our side when it's 
> done. The rest looks quite sensible too.
>
> Andrew
>
> On Wed, Mar 11, 2020 at 3:39 AM Jure Erznožnik  > wrote:
>
>> His proposed changes look awesome to me! 
>>
>> IMHO, the biggest issue going async with current implementation was 
>> connection pooling for async code. I feared that we might need huge numbers 
>> of connections in certain scenarios, especially if the code required 
>> altering the connections themselves. The proposed changes look like they 
>> eliminate the issue altogether and I'm not referring to direct async 
>> support alone.
>>
>> LP,
>> Jure
>>
>>
>> On 11/03/2020 09:28, Asif Saif Uddin wrote:
>>
>> Hi,
>>
>> As this library is used by django, I thought it would be good to share 
>> with django internals deveopers?
>>
>> https://www.varrazzo.com/blog/2020/03/06/thinking-psycopg3/
>>
>> Hope it is useful.
>>
>> ./auvipy
>> -- 
>> 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-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/faea6068-ec43-4da6-9780-1beaedaf0b16%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/faea6068-ec43-4da6-9780-1beaedaf0b16%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-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/110c8328-c0ea-e32e-081a-ca42657193b7%40gmail.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/110c8328-c0ea-e32e-081a-ca42657193b7%40gmail.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/cfce2c00-7046-4b42-8081-fd36d09cd712%40googlegroups.com.

Re: GSOC Proposal: 2FA

[Asif Saif Uddin]

can you elaborate more on the technical break down of the project steps?

On Thursday, March 26, 2020 at 11:10:27 PM UTC+6, Rohit Jha wrote:
>
> Hi,
>
> Here is my proposal for GSoCon 2FA
>
>
> https://docs.google.com/document/d/1f-9hOYHZ9rzLH7UEzdPmVi1n4jQJ92gDwYpqef1ZYMk/edit?usp=sharing
>
> Feedback and criticism is highly appreciated.
> Thanks & Regards 
>

-- 
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/b8fb2e07-1c3f-4b60-94b9-1fffecfa4d8c%40googlegroups.com.

Re: GSOC Student

[Asif Saif Uddin]

you should check the idea page for gsoc 2020 first. then pick a component 
of django internals and find out relevant ticets to create a good proposal 
to solve the problem of any part of django. 

On Friday, March 27, 2020 at 4:02:23 PM UTC+6, Edidiong Etuk wrote:
>
> Hi, I'm Edidiong, I'd like to be engaged with the GraphQL ORM wrapper, 
> either as a student or just freelancing. How do I begin?
>

-- 
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/e7912ad0-bc2b-4faf-9b00-a5c2a4557fb6%40googlegroups.com.

Re: GSoC Mentors

[Asif Saif Uddin]

Hi,

I believe I can help in project management and some technical help with my 
3 failed attempt to get selected as gsoc student in django project. I can 
share my experience from my failures :)

Hope that would be useful :)

Kind regards,

Asif

On Wednesday, March 25, 2020 at 2:43:49 PM UTC+6, Carlton Gibson wrote:
>
> Hi all. 
>
> We're reaching the end of the application period for GSoC. 
>
> In order to know how many students we might accept, we need to know how 
> many prospective mentors we have. 
>
> This falls into two kinds of job: 
>
> 1. General project management help: communicating with students to help 
> them set a schedule and a rhythm, and make sure they're able to make 
> progress. (The hope is they're self motivated but...) 
>
> 2. More technical input. For this I'm thinking particularly about the 
> migrations framwork (Markus, Simon, Shai, Andrew, ...) but *experienced 
> hands* with knowledge of the internals: your input would be invaluable 
> here. 
>
> The forum seems to be working well, and it's a good format for this kind 
> of thing, so I want to aim to focus the discussion there. 
>
> I'd like to share the mentoring as a group. We'd need to assign specific 
> mentors but I don't see why it can't be a group thing. 
>
> If you could hang out a bit on the forum (mainly for task 1) and/or offer 
> technical input, which you might be doing already/anyway (for task 2) then 
> that would be a super contribution. 
>
> Please let me know if you'd be willing to help mentor. 
>
> Thanks
>
> 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/57821d9b-54fd-41c4-ad10-14a966c1c93a%40googlegroups.com.

Psycopg3 Redesign

[Asif Saif Uddin]

Hi,

As this library is used by django, I thought it would be good to share with 
django internals deveopers?

https://www.varrazzo.com/blog/2020/03/06/thinking-psycopg3/

Hope it is useful.

./auvipy

-- 
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/faea6068-ec43-4da6-9780-1beaedaf0b16%40googlegroups.com.

Re: Google Patch Rewards program

[Asif Saif Uddin]

Really good plans Adam!

On Saturday, December 21, 2019 at 11:51:11 PM UTC+6, Adam Johnson wrote:
>
> I just saw Google is expanding their Patch Rewards program for open source 
> security improvements: 
> https://security.googleblog.com/2019/12/announcing-updates-to-our-patch-rewards.html
>
> They are offering two tiers of rewards - $5,000 or $30,000 - for  open 
> source projects making security improvements. I think Django would find it 
> hard to fit in the "small" tier - we generally fix known vulnerabilities 
> quickly - but we could use the "large" tier to fund a bigger GSoC style 
> project. I suspect it would need active involvement from a DSF member to 
> push it through. Not sure how the funding would work in terms of DSF and 
> paying for development time on the project.
>
> Some projects that could fit:
>
>- 2FA built-in to django.contrib.auth (as suggested for GSoC as well 
>in this thread: 
>
> https://groups.google.com/forum/#!msg/django-developers/ifYT6lX8nmg/1nVO3As1AwAJ
>  
>)
>- Adding CSP to SecurityMiddleware and shipping some default 
>(django-csp is a good start but requires users to actively seek it: 
>https://django-csp.readthedocs.io/en/latest/ )
>- Adding CORS to Django itself (I'm maintaining django-cors-headers, 
>but its design is a bit pants 
>https://github.com/adamchainz/django-cors-headers )
>- Other things in James Bennett's list of suggestions from this thread 
>in May 2018: 
>
> https://groups.google.com/forum/#!msg/django-developers/DDpkrvFdnvk/J46ZbakxAgAJ
>
> Thoughts?
> -- 
> Adam
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3c2cb15c-3c55-431c-8ee7-a5a207051389%40googlegroups.com.

Re: Sounding out for GSoC 2020.

[Asif Saif Uddin]

As a long term user of django, I would love to see the DB/ORM + HTTP 
related improvements more in django and the schema migration improvements 
as I use django mostly for ORM and API/CMS based projects.

I like the proposals of Adams related to ORM and inclusion of 
django-cors-headers to core. 

Beside the Idea of supporting 2FA, I think django should think about 
providing oauth2 support out of the box based on oauthlib and 
django-oauth-toolkit :)

Definitely there could be better packages :)

Just my thoughts as an long term user of django framework.

Thanks,
Asif

On Thursday, December 19, 2019 at 4:51:06 AM UTC+6, Adam Johnson wrote:
>
> This year was interesting. Sage in particular did well putting together a 
>> cross-db JSONField, but he was probably under-mentored, 
>> since Mariusz has spent quite a bit of time reworking the PR, and still 
>> has a bit to go, before we can pull it in, hopefully for 3.1
>>
>> So, one consideration we need to think about seriously is our capacity 
>> for mentoring. (This isn't just about the candidate's ability — Sage was 
>> able to implement all suggestions — we just didn't have as much capacity as 
>> we might have liked to think about the requirement implementation — and 
>> there were four of us actively giving some time each... — Anyhow, to think 
>> about.) 
>>
>
> I think your analysis is pretty accurate Carlton. Sage was a pretty 
> self-motivated candidate, writing some great blog posts about his code, and 
> we still didn't manage to merge his PR. Perhaps the project was larger than 
> we can reasonably expect?
>
> Nice work on the descriptions there Andrew.
>
> Django Service Hooks
>>
>
> I think a key use case of this is background task processing. Nearly all 
> the Django integrated libraries need to remember to "connection.close()" / 
> "close_old_connections" at the end of requests. I've seen a couple in-house 
> ones that needed this.
>
> That said I can't think of much else to go inside the "service hook"? 
> There's not much else to "the end of a Django context" at the moment is 
> there?
>
> Evented Datastores
>>
>
> I'm not sure if other databases have it but MariaDB recently implemented 
> "temporal tables" which are an SQL standard way of doing historical views 
> on data:  https://mariadb.com/kb/en/library/temporal-data-tables/ 
>
> Admittedly not quite the same as event sourcing but perhaps easier to 
> implement given it would be limited to the ORM layer.
>
> Django Benchmarking
>>
>
> I love djangobench, and do wish it was maintained and expanded. Running on 
> CI would be amazing. 
>
>
> 2FA also sounds like a great idea.
>
> Other ideas:
>
>- Support MySQL/MariaDB storage engines. I think other databases tend 
>to support some table-level customizations to.
>- Official CORS middleware/view decorator. I took over maintenance of 
>https://github.com/adamchainz/django-cors-headers and its design is a 
>bit pants.
>
>
> On Sat, 14 Dec 2019 at 17:30, Andrew Godwin  > wrote:
>
>> Here's my take on each of these, leaving out async as that'd be more 
>> dependent on where we were:
>>
>> Secrets Manager
>> Many environments Django is deployed in use a separate secrets manager to 
>> store and provide secrets per environment - either as environment 
>> variables, files, or via a direct HTTP API. The project would be to design 
>> and add an abstraction interface over secrets managers that allows users to 
>> easily map to an external secret in a settings file. There's also room for 
>> giving Django a better, built-in per-environments settings option too, 
>> pulling from popular third-party patterns.
>>
>> Django Service Hooks
>> Django has a lot tied to the HTTP lifecycle, and if you run it outside of 
>> this, you miss out on some key things - like database connections being 
>> closed properly, or logging, or some middleware. The project would be to 
>> design and implement a separate way of calling Django from a service 
>> framework - even if that framework was itself HTTP based (basically, don't 
>> rely on Django having to run through WSGI/ASGI). Initial idea is to provide 
>> a context manager that replaces the wrapping of a request, but the project 
>> would have to include requirements-gathering and interviewing people who 
>> use Django to power microservices to work out what they want.
>>
>> Evented Datastores
>> Evented, or event-sourcing, database schemas are growing in popularity - 
>> essentially, a way to implement an append-only pattern on top of a 
>> relational database, where every single event that has happened is stored, 
>> but you can still efficiently retrieve the current state of an item. Given 
>> the way the pattern works, this would be possible to implement on top of 
>> Django models - likely as a whole new Model subclass - and implement with a 
>> matching QuerySet/Model API. It would require someone very skilled in 
>> database design, and it's also arguable if it should be in 

Re: Deprecate HttpRequest.is_ajax

[Asif Saif Uddin]

Not so sure though, but would like to know if 
https://github.com/python-hyper these libraries are of any use for django 
http?

On Thursday, November 21, 2019 at 5:52:12 AM UTC+6, James Bennett wrote:
>
> On Wed, Nov 20, 2019 at 3:44 PM Curtis Maloney  > wrote:
>
>>
>> Yeah, I expected DRF had this "solved" already. From my own 
>> experimentation, mapping `cgi.parse_header` over the the "Accept" header 
>> value, split by comma, gets a usable result; then sort that list by 'q' 
>> (defaulting to 1.0) and you have your priority.
>>
>
> Both the original and forks seem to've been abandoned now, but the 
> mimeparse library encapsulated this into a nice little function that took 
> an Accept header, and a list of content-types you could support in the 
> response, and told you which one was the best match. The code's still out 
> there and under a permissive license if somebody wants to pick it up again. 
>

-- 
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/1b5fde50-b61f-42b3-b59d-13c4fa4b5efb%40googlegroups.com.

Re: Deprecate HttpRequest.is_ajax

[Asif Saif Uddin]

any plan with 
https://github.com/django/deps/blob/master/draft/content-negotiation.rst 
one?

On Sunday, November 17, 2019 at 2:00:26 PM UTC+6, Adam Johnson wrote:
>
> Right - Flask's error message also points to something I was mistaken 
> about. XMLHttpRequest does not set this header. jQuery adds it ( 
> https://api.jquery.com/jquery.ajax/#jQuery-ajax-settings ), and 
> presumably some other JS libraries.
>
> In my opinion there are not many good reasons to have to change behaviour 
>> if a request is made via XHR. I think the most common usage is to have a 
>> single view that returns a JSON response or a HTML response depending on if 
>> XHR is used (
>> https://github.com/search?l=Python=request.is_ajax=Code), which 
>> isn’t great and isn’t reliable.
>>
>
> Riight too. A better way would be to check the Accept header. DRF does 
> this: https://www.django-rest-framework.org/api-guide/content-negotiation/ 
> . Django doesn't provide any tools at the moment for parsing Accept. We 
> could add an API like https://pypi.org/project/django-accept-header/ ?
>
> On Sat, 16 Nov 2019 at 16:16, Tom Forbes > 
> wrote:
>
>> I would agree. Flask has done the same:
>>
>> DeprecationWarning: Request.is_xhr is deprecated. Given that the 
>> X-Requested-With header is not a part of any spec, it is not reliable
>>
>> In my opinion there are not many good reasons to have to change behaviour 
>> if a request is made via XHR. I think the most common usage is to have a 
>> single view that returns a JSON response or a HTML response depending on if 
>> XHR is used (
>> https://github.com/search?l=Python=request.is_ajax=Code), which 
>> isn’t great and isn’t reliable.
>>
>>
>> On 16 Nov 2019, at 16:08, Adam Johnson > 
>> wrote:
>>
>> Django's HttpRequest.is_ajax method determines whether the request was 
>> made with the JS API XMLHttpRequest 
>> https://docs.djangoproject.com/en/2.2/ref/request-response/#django.http.HttpRequest.is_ajax
>>  
>> . It does so by checking the X-Requested-With header.
>>
>> The new way of making "AJAX" requests from the browser is the JavaScript 
>> fetch() API : https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API 
>> .
>>
>> I think the  is_ajax() documentation is at least a little misleading in 
>> pretending XMLHttpRequest is the only JS API. There also aren't any special 
>> headers set by fetch() so it's not possible to detect its requests.
>>
>> I propose deprecating is_ajax() with no replacement.
>>
>> Thoughts?
>>
>> -- 
>> 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-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CAMyDDM0i-p0ZxBj-fSheGs-2pMXH7K7Oka%3DCjy1YXx-emBu3mw%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-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/84DCD242-69A8-4B8D-9EB6-243312B5F77F%40tomforb.es
>>  
>> 
>> .
>>
>
>
> -- 
> Adam
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/48b34cca-02bf-4f2c-817d-65afbd1ab125%40googlegroups.com.

Re: Django Async DEP

[Asif Saif Uddin]

I have a separate question. Is it possible to get the django 3.0 asgi 
things into a different package to use with django 2.2?

Thanks for the great work.

On Friday, May 10, 2019 at 3:42:08 PM UTC+6, Patryk Zawadzki wrote:
>
> We've always considered that implicit queries on attribute access were an 
>> intractable problem. I said it on stage an DjangoCon US 2013. I'm now 
>> wondering if I was wrong all along! In an async ORM context, every time we 
>> traverse a relation, we could create a Future that would execute the query 
>> and resolve to its result. This would require one await per SQL query so 
>> we'd still get the benefit of making queries explicit, although to a lesser 
>> extent than with an explicit select/prefetch_related.
>>
>
> In theory there's nothing stopping you from turning prefetch_related int 
> on explicit fetch_related:
>
> queryset = Foo.objects.filter(Foo.publish_date <= datetime.date.today())
>
> queryset = fetch_related(queryset[:10], Foo.author)  # with a future
>
> results = await queryset.all()
>
> fetch_related(results, Foo.category)  # with a result set, returns identity
>
>

-- 
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/e738b8a8-89eb-4883-8e59-14647d0ecc17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Summer Internships

[Asif Saif Uddin]

This not the list you are looking for. This list is for development of 
django itself. django-users is the list you are looking for.

./auvipy

On Tuesday, May 7, 2019 at 7:57:57 PM UTC+6, Akshit Jain wrote:
>
> Hi all!
> I am Akshit Jain 2nd year cse undergraduate, I am an open source 
> contributor and works in django.
> I build 2-3 projects in django and now I am in search of summer internship 
> as per my skills, also I am ready to learn new skills as per requirements 
> I am ready to work remotely as well , so if there is any opportunity 
> please inform me, It will be a great help
>
> Thanks and regards,
> Akshit
>

-- 
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/e971b2ce-3e54-4e74-8193-eacb27325737%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC Proposal (FormSet Improvement)

[Asif Saif Uddin]

Congrats Parth. It would be great If your contributions could be accepted 
in the next versions of django, I have some od works related to declarative 
formsets. I will clean them up and bring to you so that you can move that 
forward with mentors/communities help.
Best of luck.

On Tuesday, May 7, 2019 at 7:15:45 PM UTC+6, PARTH PATIL wrote:
>
> Hello everyone,
>
> I would like to thank everyone here and everyone who helped me to improve 
> my project idea. This project has been accepted and I will try my best to 
> completewhatvI have promised.
>
> I was wondering what is the next step? Are there any kind of formalities 
> to be completed?
>
> Best Regards,
> PARTH PATIL
>
> On Mon, 8 Apr 2019, 3:05 am PARTH PATIL, > 
> wrote:
>
>> I have done some MAJOR changes/improvements to my proposal please have a 
>> look. I have added technical description and addressed more issues related 
>> to the forrmsets. Suggest any changes if needed.
>>
>>
>>
>> On Saturday, April 6, 2019 at 10:38:42 PM UTC+5:30, Asif Saif Uddin wrote:
>>>
>>> I will try to come up with an initial step for that hopefully by 
>>> tomorrow. In the meantime, I hope you will keep trying to improve your 
>>> proposal by analyzing open form/formset related issues, some of whom you 
>>> could try to fix to get more insight.
>>>
>>> On Saturday, April 6, 2019 at 10:30:02 PM UTC+6, PARTH PATIL wrote:
>>>>
>>>> Sure that would be nice, as I even mentioned in my abstract I 
>>>> definitely need help for that one.
>>>>
>>>> On Saturday, April 6, 2019 at 8:59:01 PM UTC+5:30, Asif Saif Uddin 
>>>> wrote:
>>>>>
>>>>> Regarding the declarative syntax, I might share some insights later 
>>>>> with you.
>>>>>
>>>>> On Tuesday, April 2, 2019 at 1:29:33 AM UTC+6, PARTH PATIL wrote:
>>>>>>
>>>>>> Here is a link to my GSoC proposal
>>>>>> Its a first draft so you are open to comment and suggest changes
>>>>>>
>>>>>>
>>>>>> https://docs.google.com/document/d/1JuoVOU5xMwXY7JrHJshezIyuIpFfoEM49rO3e0rfNhE/edit?usp=sharing
>>>>>>
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> PARTH PATIL
>>>>>>
>>>>>> SOFTWARE DEVELOPER, AUV-IITB
>>>>>>
>>>>>> CONVENOR, ELECTRONICS & ROBOTICS CLUB IIT BOMBAY.
>>>>>>
>>>>>> [image: Image result for FACEBOOK ROUND ICON] 
>>>>>> <https://www.facebook.com/parth.patil.77> [image: Image result for 
>>>>>> instagram ROUND ICON] <https://www.instagram.com/code_blooded18/> 
>>>>>> [image: 
>>>>>> Image result for linkedin ROUND ICON] 
>>>>>> <https://www.linkedin.com/in/parth-patil-256291117/>
>>>>>>
>>>>>> -- 
>> 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-d...@googlegroups.com .
>> To post to this group, send email to django-d...@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/8b9f7237-db7a-4bcb-949a-03197382eeb0%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/8b9f7237-db7a-4bcb-949a-03197382eeb0%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> 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/d2d55010-6032-4467-be66-3bc94e04731e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Allow ManyToMany using a intermediary table to be defined as symmetrical

[Asif Saif Uddin]

After reading your reasoning and code it seems logical for me. Let's create 
a pr for more input.

On Tuesday, April 23, 2019 at 6:13:35 PM UTC+6, Nadège Michel wrote:
>
> Hello,
>  
> We use self.referencing ManyToMany relationships with intermediate tables 
> in our work project 
> and I was wondering why we had to create ourselves the reverse link when 
> we need the relationship to be symmetrical.
> I looked at the 'symmetrical' attribute documentation and though we should 
> just set it to True instead of False, 
> but you may know that it triggers the error "fields.E332 Many-to-many 
> fields with intermediate tables must not be symmetrical.".
>
> I searched for a corresponding existing ticket a found this one which is 
> kind of related https://code.djangoproject.com/ticket/9475
> And you can see in the PR some discussion about the check 
> https://github.com/django/django/pull/8981#discussion_r247946460
> Thanks to the work of Collin Anderson in the previous PR I think we can 
> now remove that check.
>
> Questions I had:
>
>- retro compatibility?
>
> As the current behavior forces the user to set 'symmetrical=False', the 
> change is retro-compatible.
>
>- use 'through_defaults' when creating both objects or define a new 
>'through_reverse_defaults' to give different values for each row? 
>
> if you want symmetrical relationship, both objects should have the same 
> values 
> so I chose to use 'through_defaults' for both objects. Which was also what 
> was done in the #8981 
>  PR in 
> the first place.
>
> I have a patch 
> 
>  
> with theses changes:
>
>- removed the check 
>- removed tests for that check
>- added tests (tests/m2m_through, tests/m2m_recursive)
>- updated documentation (may need a bit more work)
>- added back the use of 'through_defaults' of #8981 
> in 
>the:
>
> if self.symmetrical:  
> self  ._add_items(...) 
>
> Tests suite runs fine.
>
> Any thoughts on this design change / new feature?  
> I'll be happy to create a ticket and submit my patch for reviews :) 
>

-- 
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/50952d85-8a8d-4f0d-9f7d-54322e512d1d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC Proposal: Add Cross-DB JSONField, ArrayField, and HStoreField

[Asif Saif Uddin]

Hi Sage,

Would you mind opening a draft proposal at django/dep repo? If you can 
implement the POC cross db JSON field, I as a maintainer of 
django-activity-stream would like to try this with that package.

Looking forward to try your POC. 

Thanks,
Asif

On Tuesday, April 16, 2019 at 5:36:04 PM UTC+6, Sage M.A. wrote:
>
> Hi, Raphael.
> Ah, yes, I have seen your project, but I guess I forgot to link it in my 
> proposal.
> It *is* very interesting, and I believe it will be helpful for anyone who 
> wants to implement
> this. Let's hope we can make this happen. Thanks for the feedback!
>
> Regards,
> Sage
>
> On Tuesday, 16 April 2019 16:44:18 UTC+7, Raphael Michel wrote:
>>
>> Hi Sage, Hi everyone, 
>>
>> I lacked the time to read this mailing list in the past months, and 
>> someone at DjangoCon Europe just pointed me to this thread, so just for 
>> reference, I want to add some prior work that I did to the list: 
>>
>> At DjangoCon US and thereafter, I developed a third-party 
>> implementation that does a little more than the ones that are more 
>> well-known and mentioned in the proposal: 
>>
>> https://github.com/raphaelm/django-jsonfallback 
>>
>> django-jsonfallback supports native JSON fields on PostgreSQL, MariaDB 
>> *and* MySQL (which are quite different in that regard). On all other 
>> databases, it falls back to the behaviour of just storing strings in 
>> text fields. Therefore, it's still different from what is being 
>> proposed here, and also the implementation is quite unclean in the 
>> sense that it needs to check for database backends on the level of 
>> database fields. When implemented in core, this could be done much more 
>> nicely. 
>>
>> Still, it might be an interesting thing to look at when doing this, if 
>> only for the test cases and the weird MySQL/MariaDB things. I'd love to 
>> see this in core and are happy to help wherever I can with my expertise. 
>>
>> Best 
>> Raphael 
>>
>> Am Tue, 2 Apr 2019 04:41:36 -0700 (PDT) 
>> schrieb "Sage M.A." : 
>>
>> > Hello, everyone! My name is Sage. I'm a 19-year-old computer science 
>> > student from Indonesia. I'm planning to join the Google Summer of 
>> > Code (GSoC) this year, and I want to contribute to Django. I have 
>> > written a draft for my proposal in this gist 
>> > . 
>> > I have submitted two small patches for Django, and I hope to 
>> > contribute more in the future. Feedbacks are much appreciated, 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 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/40898a98-a9a5-457d-b105-47c2fc95e5cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google "Season of Docs"

[Asif Saif Uddin]

Was looking into the docs issues and suddenly this come!!

On Thursday, April 11, 2019 at 12:08:27 PM UTC+6, Carlton Gibson wrote:
>
> Hi William. 
>
> A few people have shown interest so I will apply as an org for us. Then 
> candidates can apply. (I’m hopeful we could get multiple slots but it’s a 
> new programme so I don’t really know.)
>
> C.
>
> On Wed, 10 Apr 2019 at 21:03, William Hakizimana  > wrote:
>
>> Just out of curiosity, I was wondering if we got any traction on this.
>>
>> On Monday, March 18, 2019 at 5:27:47 AM UTC-5, Carlton Gibson wrote:
>>>
>>> Hi all, 
>>>
>>> Parallel to GSoC, Google now have this "Season of Docs" programme: 
>>>
>>> https://developers.google.com/season-of-docs/
>>>
>>> The idea is experienced technical writers can get funding to work with 
>>> open source projects on their docs. 
>>>
>>> There are a lot of open Documentation issues 
>>> 
>>> . 
>>>
>>> As such if you have, or if you know someone with, strong writing skills 
>>> and you 
>>> (they) might be interested here let me know and we can look into this. 
>>>
>>> I can't quite work out whether if we just apply we might attract a 
>>> writer, but it would be 
>>> awesome if already someone in the community was keen for this.
>>>
>>> Thanks. 
>>>
>>> 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-d...@googlegroups.com .
>> To post to this group, send email to django-d...@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/4fc398b3-151f-49fc-8279-9b2f300aa348%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/c070358d-f7b8-44c5-a114-c40a0529e39d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

[Asif Saif Uddin]

yes, there wasn't anyone selected.

On Wednesday, April 10, 2019 at 3:24:50 AM UTC+6, makina wrote:
>
> Hello, 
>
> Django doesn't have any projects in 2018. 
> https://summerofcode.withgoogle.com/archive/2018/organizations/5080222944722944/
> Does it mean there were no quality applicants in 2018?
>
> 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/0b824e47-e9e0-4ebd-ab8f-44507b7977e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Queries about the project idea Improving the Less Popular Backends

[Asif Saif Uddin]

You are too late to propose the proposal for review. Now it's your call fix 
as many good issues related to your proposal so that the core mentors can 
gauge your ability to be selected for gsoc this year. if you could 
contribute some good patches you might be a very good candidate for gsoc 
next year with your contribution history and might get early helps to 
prepare a solid proposal.

good luck!

On Tuesday, April 9, 2019 at 10:05:23 PM UTC+6, Dingfan Zhao wrote:
>
> Hello, 
>
> Thanks for your reply! I am working on the proposal now since the deadline 
> is quite tight. I finished the proposal just now and hope you could give me 
> some advice on it. 
>
>
> https://docs.google.com/document/d/1tlGWuf_uBS-1GvxwMoSyyh5xUmB4b5gVg4vRFGaMDZg/edit
>
> I will start contributing to some issues during these days to convince 
> other contributors in the community, but maybe after the deadline for 
> submitting the proposal since the deadline is just 2 hours later :)
>
> Regards,
> Dingfan
>
> On Tuesday, 9 April 2019 09:57:52 UTC+8, Asif Saif Uddin wrote:
>>
>> yes, you can select some relevant issues which help to fix a much bigger 
>> problem. so try to understand the bigger ideas coming out of some of the 
>> related issues. deadline is very close. it would be better to have the 
>> draft submitted here and fix at least one or two related issues to convince 
>> the core team and the community that ypu are capable to complete what you 
>> are proposing.
>>
>> Cheers!
>>
>> Asif
>>
>> On Monday, April 8, 2019 at 5:24:06 PM UTC+6, Dingfan Zhao wrote:
>>>
>>> Hello guys, 
>>>
>>> I am year 4 students in Singapore and I would like to contribute to 
>>> Django in GSoC this summer. The project idea that I am interested in is 
>>> Improving the less popular backends. However, the project description is 
>>> kind of vague and I am not able to catch the exact requirements for this 
>>> project. 
>>>
>>> In my view, the key for this project is to build some features for less 
>>> popular backends to make it support equal operations with other backends. I 
>>> appreciate if someone can give me some advice. 
>>>
>>> For example, I did a search in Django raising ticket page and I set up 
>>> some filters: 
>>> https://code.djangoproject.com/query?status=new=Database+layer+(models%2C+ORM)=id=summary=status=owner=type=component=version=1=id
>>>
>>> May I understand it like I would select some issues from these tickets 
>>> and solve them in order to fulfill this project idea? 
>>>
>>> Any advice is appreciated in advance! Thanks a lot. 
>>>
>>> Regards
>>>
>>

-- 
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/25cb899e-3aee-4123-a8b9-00434b47396e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Queries about the project idea Improving the Less Popular Backends

[Asif Saif Uddin]

yes, you can select some relevant issues which help to fix a much bigger 
problem. so try to understand the bigger ideas coming out of some of the 
related issues. deadline is very close. it would be better to have the 
draft submitted here and fix at least one or two related issues to convince 
the core team and the community that ypu are capable to complete what you 
are proposing.

Cheers!

Asif

On Monday, April 8, 2019 at 5:24:06 PM UTC+6, Dingfan Zhao wrote:
>
> Hello guys, 
>
> I am year 4 students in Singapore and I would like to contribute to Django 
> in GSoC this summer. The project idea that I am interested in is Improving 
> the less popular backends. However, the project description is kind of 
> vague and I am not able to catch the exact requirements for this project. 
>
> In my view, the key for this project is to build some features for less 
> popular backends to make it support equal operations with other backends. I 
> appreciate if someone can give me some advice. 
>
> For example, I did a search in Django raising ticket page and I set up 
> some filters: 
> https://code.djangoproject.com/query?status=new=Database+layer+(models%2C+ORM)=id=summary=status=owner=type=component=version=1=id
>
> May I understand it like I would select some issues from these tickets and 
> solve them in order to fulfill this project idea? 
>
> Any advice is appreciated in advance! Thanks a lot. 
>
> Regards
>

-- 
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/449e90b3-9665-4bdb-b8e6-a5f702587ae2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC Proposal: Add Cross-DB JSONField, ArrayField, and HStoreField

[Asif Saif Uddin]

You can open a work in progress pr to fix them one by one gradually and 
trying to fix some of them will give you a much better understanding of 
django orm internals as it is considered the most complex part of the 
framework. This will also improve your chance to represent yourself as a 
much stronger candidate and you will be able to interact with the community 
in a very meaningful way. Just my 2 cents. 

On Sunday, April 7, 2019 at 12:27:51 PM UTC+6, Sage M.A. wrote:
>
> Oh, I forgot, one of them is not related to datetime functions: 
> test_unsupported_backend.
>
> On Sunday, 7 April 2019 13:26:10 UTC+7, Sage M.A. wrote:
>>
>> Hi Asif,
>> That's a good idea! I've installed the latest stable release of MariaDB 
>> (10.3.14) on my machine and ran Django test suits with it.
>> The results 
>> <https://gist.github.com/laymonage/a6beb3ec49b2633a508e40d2862ce875> (I've 
>> truncated them to only contain the failures and errors) show 19 failures 
>> and 15 errors, all of which seem to be
>> related to datetime functions. I suppose that'll be enough for me to work 
>> on if my GSoC project finishes early. I'll also need to
>> write docs about the new support for MariaDB.
>>
>> On a side note, setting up and destroying the database for the test took 
>> hours on my machine. Is that normal? I had to use
>> verbosity=2 to find out that it was not freezing, just really slow.
>>
>> On Saturday, 6 April 2019 22:32:53 UTC+7, Asif Saif Uddin wrote:
>>>
>>> Sage, regarding MariaDB, I have a little suggestion with you. If you 
>>> could setup a latest version of mariadb locally and try to run Django test 
>>> suits with that, you might have some ideas of remaining issues analyzing 
>>> the test failures initially.
>>>
>>> On Thursday, April 4, 2019 at 11:30:48 AM UTC+6, Sage M.A. wrote:
>>>>
>>>> Hi, Carlton.
>>>>
>>>> Thanks a lot for the feedback!
>>>> Ah, yes, looks like I missed that Oracle implementation. I've updated 
>>>> my proposal accordingly.
>>>> To summarize:
>>>>
>>>>- Added info about Oracle implementation (see 1.1)
>>>>- Replaced 1 week of research with 1 week of writing tests and docs 
>>>>for POC SQLite JSONField (see 3.1.1 and 3.1.2)
>>>>- Replaced the idea of implementing HStoreField with writing 
>>>>documentation for ArrayField, migration path, and SQLite+JSON1 (see 
>>>> 3.3.2)
>>>>- Took half a week from the merging process into writing the 
>>>>aforementioned docs.
>>>>- Wrote about the possibility of merging the first and second 
>>>>milestones so the final milestone would not be so big to merge. (see 
>>>> 3.1.2 
>>>>and 3.2.2)
>>>>- Wrote about the possibility of finishing the project early (see 
>>>>3.4)
>>>>
>>>> About #29548 <https://code.djangoproject.com/ticket/29548>, it seems 
>>>> interesting to me but I'm not quite sure what's left to be done.
>>>>
>>>> Regards,
>>>> Sage
>>>>
>>>> On Wednesday, 3 April 2019 21:40:09 UTC+7, Carlton Gibson wrote:
>>>>>
>>>>> Hi Sage. 
>>>>>
>>>>> Thanks for the proposal. It's looking OK. Couple of points: 
>>>>>
>>>>>
>>>>>- There IS an Oracle implementation. See the ticket here: 
>>>>>https://code.djangoproject.com/ticket/29821
>>>>>- Something that looks like an ArrayField, yes. HStore... not so 
>>>>>sure it's worth mimicking. 
>>>>>- On the timeline: I think you've spread the coding bit too thin 
>>>>>and not allocated enough for Documenting.
>>>>>   - I think you if you want full-guns at the SQLite PoC in week 1 
>>>>>   and 2 you'd have something in place quite quickly. 
>>>>>  - The base field should be simple enough™
>>>>>  - The SQLite only lookups shouldn't be too complicated. 
>>>>>   - As I commented on the other thread on this topic, we'll need 
>>>>>   to advise on getting people set up with SQLite with the JSON 
>>>>> extension. 
>>>>>   - There's more in this that you think I'd guess. No harm in 
>>>>>  putting time in the schedule for it. 
>>>>>   - Allow for the possibility you complete early and have time to 
>>>>>   work 

Re: GSoC Proposal (FormSet Improvement)

[Asif Saif Uddin]

I will try to come up with an initial step for that hopefully by tomorrow. 
In the meantime, I hope you will keep trying to improve your proposal by 
analyzing open form/formset related issues, some of whom you could try to 
fix to get more insight.

On Saturday, April 6, 2019 at 10:30:02 PM UTC+6, PARTH PATIL wrote:
>
> Sure that would be nice, as I even mentioned in my abstract I definitely 
> need help for that one.
>
> On Saturday, April 6, 2019 at 8:59:01 PM UTC+5:30, Asif Saif Uddin wrote:
>>
>> Regarding the declarative syntax, I might share some insights later with 
>> you.
>>
>> On Tuesday, April 2, 2019 at 1:29:33 AM UTC+6, PARTH PATIL wrote:
>>>
>>> Here is a link to my GSoC proposal
>>> Its a first draft so you are open to comment and suggest changes
>>>
>>>
>>> https://docs.google.com/document/d/1JuoVOU5xMwXY7JrHJshezIyuIpFfoEM49rO3e0rfNhE/edit?usp=sharing
>>>
>>>
>>> Best Regards,
>>>
>>> PARTH PATIL
>>>
>>> SOFTWARE DEVELOPER, AUV-IITB
>>>
>>> CONVENOR, ELECTRONICS & ROBOTICS CLUB IIT BOMBAY.
>>>
>>> [image: Image result for FACEBOOK ROUND ICON] 
>>> <https://www.facebook.com/parth.patil.77> [image: Image result for 
>>> instagram ROUND ICON] <https://www.instagram.com/code_blooded18/> [image: 
>>> Image result for linkedin ROUND ICON] 
>>> <https://www.linkedin.com/in/parth-patil-256291117/>
>>>
>>>

-- 
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/eba76e1d-f601-4f36-bfc5-ee808ea5cdf0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC Proposal: Add Cross-DB JSONField, ArrayField, and HStoreField

[Asif Saif Uddin]

Sage, regarding MariaDB, I have a little suggestion with you. If you could 
setup a latest version of mariadb locally and try to run Django test suits 
with that, you might have some ideas of remaining issues analyzing the test 
failures initially.

On Thursday, April 4, 2019 at 11:30:48 AM UTC+6, Sage M.A. wrote:
>
> Hi, Carlton.
>
> Thanks a lot for the feedback!
> Ah, yes, looks like I missed that Oracle implementation. I've updated my 
> proposal accordingly.
> To summarize:
>
>- Added info about Oracle implementation (see 1.1)
>- Replaced 1 week of research with 1 week of writing tests and docs 
>for POC SQLite JSONField (see 3.1.1 and 3.1.2)
>- Replaced the idea of implementing HStoreField with writing 
>documentation for ArrayField, migration path, and SQLite+JSON1 (see 3.3.2)
>- Took half a week from the merging process into writing the 
>aforementioned docs.
>- Wrote about the possibility of merging the first and second 
>milestones so the final milestone would not be so big to merge. (see 3.1.2 
>and 3.2.2)
>- Wrote about the possibility of finishing the project early (see 3.4)
>
> About #29548 , it seems 
> interesting to me but I'm not quite sure what's left to be done.
>
> Regards,
> Sage
>
> On Wednesday, 3 April 2019 21:40:09 UTC+7, Carlton Gibson wrote:
>>
>> Hi Sage. 
>>
>> Thanks for the proposal. It's looking OK. Couple of points: 
>>
>>
>>- There IS an Oracle implementation. See the ticket here: 
>>https://code.djangoproject.com/ticket/29821
>>- Something that looks like an ArrayField, yes. HStore... not so sure 
>>it's worth mimicking. 
>>- On the timeline: I think you've spread the coding bit too thin and 
>>not allocated enough for Documenting.
>>   - I think you if you want full-guns at the SQLite PoC in week 1 
>>   and 2 you'd have something in place quite quickly. 
>>  - The base field should be simple enough™
>>  - The SQLite only lookups shouldn't be too complicated. 
>>   - As I commented on the other thread on this topic, we'll need to 
>>   advise on getting people set up with SQLite with the JSON extension. 
>>   - There's more in this that you think I'd guess. No harm in 
>>  putting time in the schedule for it. 
>>   - Allow for the possibility you complete early and have time to 
>>   work on other things...
>>   - This stuff is difficult to get right. It's more balance that 
>>   exact times: 
>>  - The actual timeline won't match the plan ever. 
>>  - you don't need to worry about two days off for holiday 
>>   
>> Your contributions so far have been super. Thank you. 
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Tuesday, 2 April 2019 13:41:37 UTC+2, Sage M.A. wrote:
>>>
>>> Hello, everyone! My name is Sage. I'm a 19-year-old computer science 
>>> student from Indonesia. I'm planning to join the Google Summer of Code 
>>> (GSoC) this year, and I want to contribute to Django. I have written a 
>>> draft for my proposal in this gist 
>>> . I 
>>> have submitted two small patches for Django, and I hope to contribute more 
>>> in the future. Feedbacks are much appreciated, 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 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/7b4ec564-82ef-4c38-a5b8-8b2ba1e1a938%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC Proposal (FormSet Improvement)

[Asif Saif Uddin]

Regarding the declarative syntax, I might share some insights later with 
you.

On Tuesday, April 2, 2019 at 1:29:33 AM UTC+6, PARTH PATIL wrote:
>
> Here is a link to my GSoC proposal
> Its a first draft so you are open to comment and suggest changes
>
>
> https://docs.google.com/document/d/1JuoVOU5xMwXY7JrHJshezIyuIpFfoEM49rO3e0rfNhE/edit?usp=sharing
>
>
> Best Regards,
>
> PARTH PATIL
>
> SOFTWARE DEVELOPER, AUV-IITB
>
> CONVENOR, ELECTRONICS & ROBOTICS CLUB IIT BOMBAY.
>
> [image: Image result for FACEBOOK ROUND ICON] 
>  [image: Image result for 
> instagram ROUND ICON]  [image: 
> Image result for linkedin ROUND ICON] 
> 
>
>

-- 
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/543b829a-1912-4d4a-8d70-5b1980b1afcb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC Proposal (FormSet Improvement)

[Asif Saif Uddin]

I checked your contribution Parth, really good one! once you improve 
your proposal, try to focus more on form/formfield/formset/widget/admin/ 
related issues so that you have a better insight into what your proposal 
going to improve in those areas. And popular and useful extensions could be 
benefited from x features to be implemented in that way etc. triaging the 
related area based tickets and fixing some more related issues not only 
improve your chance to get selected but help you understand the related 
areas much better. good luck for GSoC this year.

On Wednesday, April 3, 2019 at 10:06:26 PM UTC+6, PARTH PATIL wrote:
>
> Yes sure I will try to update my proposal by tomorrow (4th April) night 
> (IST +5:30), So  please have a look at it once again, and suggest changes.
>
>
> Best Regards,
> PARTH PATIL
>
> On Wed, 3 Apr 2019, 9:23 pm Carlton Gibson,  > wrote:
>
>> Yes, just pseudo code — so when reviewing your proposal next week it's 
>> easy to see that it'll be the right approach. 
>>
>> On Wednesday, 3 April 2019 17:51:18 UTC+2, PARTH PATIL wrote:
>>>
>>>
>>>
>>> On Wednesday, April 3, 2019 at 8:58:26 PM UTC+5:30, Carlton Gibson wrote:

 Hey Parth. 

 Right. So, thanks for making the effort so far. Good. 

 Can you add more detail about yourself. You've not contributed to 
 Django right? So the concern at this point would be whether you're able to 
 fulfil the project. 

>>>
>>> I have contributed to Django (see #30189 
>>> ), I have mentioned it at 
>>> the end of my proposal, I would try to highlight that. 
>>>
>>>  
>>>
 What's your experience with Django? (and if you want to implement a 
 declarative formset syntax, Python more generally?)
 (Perhaps you said this, but it needs to be in the proposal.) 

>>>
>>> Sure I will add some of my projects in the proposal. 
>>>

 You don't necessarily need to have ideas for the final code, but what 
 does e.g. the usage look like with your idea (i.e. adding the request 
 parameter)? 
 (So the formset gets the request and this is available where...? and so 
 on: can you SHOW in your proposal that this WILL address the issues?)

>>>
>>> I'm a little bit confused here, What you mean by "SHOW that this works"? 
>>>
>>>- Do you just write some pseudo code, and say this will work?
>>>- Or I have to prove in some way that this will work??
>>>
>>>
 HTH.

 Kind Regards,

 Carlton


 On Monday, 1 April 2019 21:29:33 UTC+2, PARTH PATIL wrote:
>
> Here is a link to my GSoC proposal
> Its a first draft so you are open to comment and suggest changes
>
>
> https://docs.google.com/document/d/1JuoVOU5xMwXY7JrHJshezIyuIpFfoEM49rO3e0rfNhE/edit?usp=sharing
>
>
> Best Regards,
>
> PARTH PATIL
>
> SOFTWARE DEVELOPER, AUV-IITB
>
> CONVENOR, ELECTRONICS & ROBOTICS CLUB IIT BOMBAY.
>
> [image: Image result for FACEBOOK ROUND ICON] 
>  [image: Image result for 
> instagram ROUND ICON]  [image: 
> Image result for linkedin ROUND ICON] 
> 
>
> -- 
>> 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-d...@googlegroups.com .
>> To post to this group, send email to django-d...@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/deae8484-5a5c-4158-b5ef-f262f30eb6eb%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/f1623bf9-a6e1-435b-9a10-8cb998ba0009%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC Proposal (FormSet Improvement)

[Asif Saif Uddin]

It would be great if you could find out 12 weeks of work with formset 
improvement. please try to include for improvements and add more technical 
aspects you are going to fix or include.

On Tuesday, April 2, 2019 at 1:29:33 AM UTC+6, PARTH PATIL wrote:
>
> Here is a link to my GSoC proposal
> Its a first draft so you are open to comment and suggest changes
>
>
> https://docs.google.com/document/d/1JuoVOU5xMwXY7JrHJshezIyuIpFfoEM49rO3e0rfNhE/edit?usp=sharing
>
>
> Best Regards,
>
> PARTH PATIL
>
> SOFTWARE DEVELOPER, AUV-IITB
>
> CONVENOR, ELECTRONICS & ROBOTICS CLUB IIT BOMBAY.
>
> [image: Image result for FACEBOOK ROUND ICON] 
>  [image: Image result for 
> instagram ROUND ICON]  [image: 
> Image result for linkedin ROUND ICON] 
> 
>
>

-- 
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/15115e46-435b-4513-aff9-71db589ba61f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: De-assigning "Easy pickings" tickets

[Asif Saif Uddin]

Got 800 tickets with no one assigned!! 
https://code.djangoproject.com/query?status=!closed=nobody I think 
the GSOC candidates could choose lots of issues related to any specific 
area/areas or certain big problems by searching these issues?

On Saturday, March 9, 2019 at 1:30:11 AM UTC+6, Carlton Gibson wrote:
>
> Hi all. 
>
> We don't have many Easy Pickings tickets, they're all assigned, and get 
> assigned quickly, but don't often get closed. 
>
> Looking at the current batch...
>
>
> https://code.djangoproject.com/query?status=assigned=new=1=id=status=changetime=1=changetime
>
> ... I'd like to suggest that after 2 months we de-assign them, so they can 
> get picked up by people looking, who are likely not willing/able/whatever 
> to take over an assigned ticket themselves. 
>
> Any thoughts/objections to that as a policy? 
>
> Thanks. 
>
> 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 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/f119ba5d-889c-404f-968a-fb734a2de61f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2019 proposal - Dashboard

[Asif Saif Uddin]

How you plan to implement the features? new or on top of 
existing django admin extension?

On Sunday, March 3, 2019 at 8:01:12 PM UTC+6, Mainak Dutta wrote:
>
> I have been thinking of implementing a uniform Dashboard which can be 
> implemented into the Django framework using just one line. Every 
> organization uses Dashboard. So, creating a dashboard can be very useful. 
>
> The features will include - 1] Variable no of sections and Custom section 
> names
>   2] Inclusion of links in the 
> section 
>   3] Database and table from 
> database we will populate the dashboard entry automatically
>   4] Choice of fonts
>   5] Choice of Color
>   6] Choice of height and width of 
> the section. 
>
> In fact ,We can extend this concept to create custom page. And give the 
> user the option of custom pages having variable number of entries in the 
> navigation bar and Variable number of sections and Presence or absence of 
> images in the Section. With all this ready made, users can create a running 
> website very very quickly.  
>
>

-- 
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/c012f86a-5737-4c43-acd9-084e90e73546%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help needed on Django-Guardian.

[Asif Saif Uddin]

Hi Carlton,

If needed I could be a collaborator of that. I get some monthly payment for 
my open source python works :)

On Monday, February 4, 2019 at 3:01:38 AM UTC+6, Carlton Gibson wrote:
>
> Hi all. 
>
> Adam Dobrawy who runs Django-Guardian, could do with some help maintaining 
> there. 
>
> The project seems to be in good shape. (It's up to date) But needs a bit 
> of help keeping on top of the issues, dropping old-versions, and the rest 
> of it. 
>
> I see the project has some regular contributors. If you're one of them, do 
> you have a small amount extra to help with the maintenance?
>
> If you're not a contributor but use it, would you be able to lend a hand? 
>
> As ever, first step if hanging out on the repo and helping with any 
> incoming.
>
> https://github.com/django-guardian/django-guardian
>
> Thanks. 
>
> 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 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/fdb10e33-ab6a-466b-b209-4cbed1bdc7df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Potential suspension of Channels development

[Asif Saif Uddin]

Hi Andrew!! I would love to help as a co-maintainer of the projects related 
to django-channels. my github: auvipy

On Thursday, January 31, 2019 at 4:18:57 AM UTC+6, Andrew Godwin wrote:
>
> Just to update on this - nobody has individually come forward to help 
> full-time, though I have seen Carlton help out on a few issues (thanks for 
> that).
>
> I've added the PySlackers group into the support docs, as well - thanks 
> for that offer.
>
> I'm still planning to remove myself from watching all the repos come Feb 
> 1st, and barring positive confirmation someone else is going to actively 
> take over I'll put up notices on all the projects that they are actively 
> unmaintained apart from security issues.
>
> Andrew
>
>
> On Thu, Jan 17, 2019 at 10:06 AM Andrew Godwin  > wrote:
>
>> Hi all,
>>
>> I'm writing to you all to update you on the current situation of Channels 
>> and related libraries (channels-redis and Daphne) and potentially ask for 
>> help.
>>
>> I've been the sole maintainer of these projects for quite a while and it 
>> has become unsustainable - all of my energy is taken up fielding issues and 
>> support requests and I haven't been able to even get myself to start 
>> looking at Django async stuff because of it.
>>
>> Given that, if nobody else can step forward to take over, I'll have to 
>> put those three projects (Channels, channels-redis, and Daphne) into an 
>> explicit maintenance mode where they only accept security requests via the 
>> normal security@ route, and start the process of retiring them as active 
>> Django projects, as I don't want to give the impression they're still 
>> maintained if they're not.
>>
>> (note: the asgiref project is still fine and should probably move out of 
>> Django to its own effort at some point giving the growing set of ASGI tools)
>>
>> If people are willing to take over maintenance, I'm happy to help explain 
>> some things but I don't have the bandwidth to bring someone completely up 
>> from scratch, so I can't help mentor someone who is totally new to 
>> maintaining open-source Python (sorry!).
>>
>> Once I recover a bit from the burnout I'll be able to come back and help 
>> with the really complex bugs; the main thing I need out of is the seemingly 
>> endless support requests and weird WebSocket client bugs.
>>
>> My personal deadline for this is two weeks, on February 1st. If you want 
>> to help out, please feel free to reply either here or get in touch with me 
>> personally to chat about what's involved.
>>
>> Andrew
>>
>

-- 
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/92585b46-0e1d-4d34-b3a9-42815b590012%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.