Re: CONTRIBUTION TO DJANGO

[Asif Saifuddin]

Hi Heba khan,

you could give a look on this old PR of mine to have some idea about what 
was suggested to you.

https://github.com/encode/django-rest-framework/pull/4824 

This type of patch to some popular django 3rd party packages would be 
easier for you to get started to open source contrib.

Hope that would help.

Thanks,

./auvipy

twitter.com/auvipy

On Friday, September 22, 2017 at 8:09:30 PM UTC+6, Heba Khan wrote:
>
> Hi Tom! 
>  
> Thank you so much for taking time out and answering my queries. However, 
> I'm still unclear about how to move ahead with all the guidelines suggested 
> by you. I would be extremely grateful if you could guide me a bit more with 
> respect to all your suggestions.
>
> On Friday, 22 September 2017 14:51:46 UTC+5:30, Tom Forbes wrote:
>>
>> Hey Heba,
>> For a few popular packages on Github it could be as simple as making a 
>> merge request and changing their tox.ini or travis.yml file. Once the 
>> django 2.0 alpha is published on PyPi (sometime very soon) you could make a 
>> merge request to run the projects tests with the alpha, and inspect the CI 
>> output for any failures, then fix those. Alternatively, clone each project 
>> and run the tests locally (but this can get tiring for lots of individual 
>> different projects).
>>
>> For example, django-reversion has a tox.ini here: 
>> https://github.com/etianen/django-reversion/blob/master/tox.ini - If you 
>> make a merge request to that project adding Django 2.0 alpha to the `deps` 
>> section (line ~16) and the `test` section (line 4) it will run the tests on 
>> Travis CI and report any failures. You could post on the django-users 
>> mailing list for some ideas of what packages to make changes for (and for 
>> more help with specific things like tox/travis), but I would recommend: 
>> django-reversion, django-mptt, silk and django-debug-toolbar:
>>
>> https://github.com/etianen/django-reversion/blob/master/tox.ini
>> https://github.com/django-mptt/django-mptt/blob/master/tox.ini
>> https://github.com/jazzband/silk/blob/master/.travis.yml
>> https://github.com/jazzband/django-debug-toolbar/blob/master/tox.ini
>>
>> An initial merge request testing on Django 2.0 alpha is the first step, 
>> then fixing any issues that are discovered is the next (and harder) one.
>>
>> On Thu, Sep 21, 2017 at 6:55 PM, Heba Khan  wrote:
>>
>>> Can you suggest a way of how to test Django projects ad third party 
>>> packages please?
>>>
>>> On Thursday, 21 September 2017 21:00:36 UTC+5:30, Adam Johnson wrote:

 There's a whole documentation page on this: 
 https://docs.djangoproject.com/en/dev/internals/contributing/

 There aren't many easy pickings tickets, plus most of the effort right 
 now is being put into features for the 2.0 feature freeze. I'd suggest the 
 biggest contribution you can make right now is testing Django projects or 
 third party packages with 2.0 and finding bugs or helping them become 
 compatible.

 On 21 September 2017 at 15:17, Heba Khan  wrote:

> Hello! 
>
> I'm an undergrad student of B.Tech. in Computer Science and we've been 
> assigned a project to contribute in an open source project. My team 
> members 
> and I decided to pick Django since it is one of the most well known and 
> widely used open source projects. We need help in deciding what 
> contributions to make to the repository and how to go about it. Please 
> keep 
> the following in mind:
>
> 1. We're students with Intermediate coding skills and intermediate 
> knowledge of Python along with a good hold on HTML, CSS, JavaScript and 
> JQuery.
> 2. We need some easy contribution ideas which can be executed in a 
> short span of time. 
> 3. We will be needing guidance and future help from the community as 
> well. 
>
> Thank you in advance. 
>
> -- 
> 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 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/236511d3-54de-441a-a423-57cc01143be0%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 

Re: Easy pickings are not that easy for a new contributor

[Asif Saifuddin]

You should read the comments on the specific tickets opened for long under 
specific components first. and if there isn't any activities for long ask 
for take over the issue if that suits you.

On Wednesday, September 6, 2017 at 4:44:19 PM UTC+6, Alexander Lyabah wrote:
>
> > look at tests, as you suggest 
>
> A quick question around this one.
>
> If someone accept the ticket and working on it, what is the best way to 
> join and start working on tickets? Should I ask directly on github?
>
> On Tuesday, September 5, 2017 at 5:06:20 PM UTC+3, Daniele Procida wrote:
>>
>> On Tue, Sep 5, 2017, Alexander Lyabah  wrote: 
>>
>> >A lot of articles that I've read say that I should start with ticket 
>> from 
>> >Easy pickings. 
>>
>> >The problem is that there are not that many tickets I can choose from. 
>> All 
>> >of them are already assign. 
>> > 
>> >Maybe I can start with writing tests? 
>> > 
>> >What should be my next step after I read all the documentation about 
>> >contribution? 
>> > 
>> >Thank you, and sorry for, possibly, stupid question. 
>>
>> It's not a stupid question at all. As Django has matured, the low-hanging 
>> fruit has all but disappeared from the tree. 
>>
>> It's a shame as well as being a good thing. We don't want to have open 
>> issues that could easily be remedied, but at the same time they are useful 
>> ways for new contributors to start. 
>>
>> Until we find a solution to this dilemma, I would: 
>>
>> * look at tests, as you suggest 
>> * find parts of the documentation that seem unsatisfactory or lacking 
>> * see if you can collaborate with somone who is already working on 
>> something, so that even if the issue is a larger one, there might be a more 
>> manageable part of it you can tackle. 
>>
>> Daniele 
>>
>>

-- 
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/614d76de-9193-43fd-a303-bf1283632d3c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: django.contrib.mysql

[Asif Saifuddin]

Hi Adam,

How about making the package official extension and bring under django org?

Thanks,

Asif

On Monday, May 8, 2017 at 9:22:04 PM UTC+6, Adam Johnson wrote:
>
> Update: I decided not to try merge django-mysql as django.contrib.mysql 
> because I think it's an advantage to have it as a separate package. As it 
> stands, it supports Django 1.8 to 1.11 for all features, so people who 
> aren't on cutting edge Django can still use all its features. Contrast that 
> with django.contrib.postgres, where new features are only available on 
> new Django versions, with their fixed release cycle.
>
> Sérgio, django-mysql already fully supports MySQL 5.7's JSON type with 
> its JSONField: 
> https://django-mysql.readthedocs.io/en/latest/model_fields/json_field.html 
> . Try that.
>
> On 4 May 2017 at 18:41, johannes mtwengi  > wrote:
>
>> i would like to be part and start foundations coding giving back 
>>
>> On Friday, March 4, 2016 at 1:09:00 AM UTC+2, Adam Johnson wrote:
>>>
>>> The *django.contrib.postgres* docs state:
>>>
>>> There is no fundamental reason why (for example) a contrib.mysql module 
 does not exist
>>>
>>>
>>> *Well...* over the past year and a bit I've been developing 
>>> Django-MySQL. It has a ton of features specific to MySQL and/or MariaDB. 
>>> For a quick tour of the features, see the exposition in the documentation: 
>>> https://django-mysql.readthedocs.org/en/latest/exposition.html (it's 
>>> not all suitable for Django core, some is kinda hacky (but well tested!))
>>>
>>> At DUTH in November I talked with Josh Smeaton about posting a 
>>> suggestion here for *django.contrib.mysql*. Since then, I've simply 
>>> been lazy/forgetful, but now I'm here getting round to it.
>>>
>>> I'm also a bit motivated by my recent completion of its *JSONField* for 
>>> MySQL 5.7+ which is very similar to the *contrib.postgres* one, copying 
>>> and adapting large parts of code from Marc Tamlyn's work. We all know how 
>>> much everyone loves JSON these days. If anything, this could be a core 
>>> field rather than a *contrib* one - Oracle and SQLite also have JSON 
>>> capabilities now. JSON everywhere!
>>>
>>> Anyway... what's the interest in *django.contrib.mysql*? And where 
>>> woudl we go from here...
>>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/django-developers/sAgYOqBUvgI/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> django-develop...@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/274f0162-f345-4946-ad56-328c20bdafff%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Adam
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a296f932-9399-4907-92ed-8054215d087c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: proposal: add special subclass of ForeignKey for storing ContentTypes

[Asif Saifuddin]

Hi Sergey,

I was also wondering why GenericForeignKey don't have direct subclass of 
ForeignKey while writing a dep about field API improvement. Though I am not 
100% sure your implementation.

Thanks for bringing it up.



On Wednesday, April 5, 2017 at 2:46:31 AM UTC+6, Sergey Fedoseev wrote:
>
> Hi all,
>
> Some time ago I created 'new feature` ticket 
>  and Tim Graham asked me to 
> write here to get some feedback on the idea. So here it is.
>
> ContentType model is quite specific, so we could add the subclass of 
> ForeignKey with some specific features.
>
>
> For example, we have a model:
>
>
> class ModelWithContentType(models.Model):
> ct = ContentTypeField(on_delete=models.CASCADE)
>  
>
> In comparison with ForeignKey ContentTypeField will have these features:
>
>1. ModelWithContentType.objects.first().ct will use content types 
>cache 
>
>
>1. ContentTypeField will support lookups on the model classes (on 
>model instances too?):
>
> ModelWithContentType.objects.filter(ct=FooModel) vs.
>
>
> ModelWithContentType.objects.filter(ct=ContentType.objects.get_for_model(FooModel))
>
>
> ModelWithContentType.objects.filter(ct__in=[FooModel, BarModel]) vs.
> ModelWithContentType.objects.filter(ct__in=[ContentType.objects.get_for_model(model)
>  
> in [FooModel, BarModel]])
>
>1. Creation using a model class as a value (not sure if it's useful 
>actually): 
>
> ModelWithContentType.objects.create(ct=FooModel)
>
>
> Here's ​rough implementation 
> .
>

-- 
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/0764f9bc-be05-47ac-8201-b419a93d3061%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Composite key development

[Asif Saifuddin]

Hi Julien,

actually I am following ansi and michals works and suggestions regarding 
this issues so my plan is quite in line with their suggested plan of 
implementation.

I have opened a PR in dep which is very very WIP right now. I haven't been 
able to address everything nicely till now, but you could check you the dep 
and put some questions/suggestion there so that I can address them well.

Currently I am working on first steps [Fields/Relations API clean 
up+VirtualField based refactor, composite key might come after that of may 
be initial work of composite key based on virtualField could also be 
addressed]

I will work on next few days to complete it.

Thanks,
Asif

On Saturday, March 25, 2017 at 2:47:46 AM UTC+6, Julien Phalip wrote:
>
> Thank you Anssi. It’s very useful to have your perspective as you’ve done 
> a lot of oversight work on this specific feature before and have lots of 
> experience working with the ORM internals.
>
> So it seems like the consensus at this point is to use Michal’s original 
> work as a basis. I like the way you’ve broken down the different steps. 
> This makes sense and would likely increase chances for eventually reaching 
> the end goal. Each one of those steps could potentially be fleshed out as 
> independent DEPs at some point.
>
> Personally I’m also very keen to make this happen so I’m volunteering to 
> provide oversight and help with documentation, testing and code reviews.
>
> This approach also seems in line with what Asif mentioned earlier about 
> his own work. Let’s give him a chance to provide some updates on this when 
> he’s ready, and then we can take it from there.
>
> Thanks all!
>
> Julien
>
> On Mon, Mar 20, 2017 at 1:14 AM, Anssi Kääriäinen <akaa...@gmail.com 
> > wrote:
>
>> Just my late 2 cents to this...
>>
>> First, I wouldn't put too much weight on the DEP proposals. Looking back 
>> to them now, I don't think they went to the right direction.
>>
>> For Michal Petrucha's work, it was really close to being merged some 
>> years ago. The problem was that migrations happened at the same time, and 
>> that resulted in need of substantial changes to Michal's work, and 
>> unfortunately this never happened. So, I'd put a lot of weight on this work.
>>
>> If I'd were to take on this task, I'd try to develop the feature with the 
>> idea of merging the work in multiple batches. For example this might be a 
>> possible plan:
>>   1. Introduce virtual/composite field, only CREATE TABLE migrations 
>> support at this point, not documented as public API
>>   2. Add support for primary key and unique composite fields, again 
>> non-public
>>   3. Work on foreign keys, again non-public
>>   4. Migrations support
>>   5. Make the work public API (that is, document the work)
>>
>> This would give a chance to get the work done in incremental pieces. 
>> Doing this all in one go is such a large task that there is a big risk of 
>> not getting this done at all.
>>
>> Whatever approach you take, I really hope you'll be able to work on this 
>> and get this long waited feature in to Django.
>>
>>  - Anssi
>>
>> On Wednesday, March 1, 2017 at 7:08:35 AM UTC+2, Asif Saifuddin wrote:
>>>
>>> Hi Julien,
>>>
>>> I will publish it very soon.
>>>
>>> Thanks
>>>
>>> On Wednesday, March 1, 2017 at 5:58:50 AM UTC+6, Julien Phalip wrote:
>>>>
>>>> Hi Asif,
>>>>
>>>> That sounds good. On first look I did have some reservations about some 
>>>> of the design details in the current DEP, especially around the observer 
>>>> pattern for data binding. But I’m going to have to dig deeper into the 
>>>> implementation to get a clearer idea.
>>>>
>>>> It’d be great if you could publish your work-in-progress at some point 
>>>> so we can discuss the approach in more detail.
>>>>
>>>> Thanks,
>>>>
>>>> Julien
>>>>
>>>> On Mon, Feb 27, 2017 at 9:03 PM, Asif Saifuddin <auv...@gmail.com> 
>>>> wrote:
>>>>
>>>>> Hi Julian,
>>>>>
>>>>> I have been also reviewing and studying the previous works, deps, 
>>>>> discussions, codes and tickets. I have also been working to prepare a new 
>>>>> dep based on the previous works.
>>>>>
>>>>> Like what Michal said, from my observation, I found the works and 
>>>>> approaches of Michal is quite better and it's possible to break the work 
>>>>> 

Re: Django ORM query syntax enhancement

[Asif Saifuddin]

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
>>> approaches. Finally I came up with solution to extend Q objects with dot
>>> expression syntax:
>>>
>>> >>> GameSession.objecs.filter(Q.user.profile.last_login_date >= 
>>> yesterday)
>>>
>>> Q is a factory instance for old-style Q objects. Accessing attribute by 
>>> dot
>>> returns a child factory, calling factory will instantiate old-style Q 
>>> object.
>>>
>>> >>> Q
>>> 
>>>
>>> >>> Q.user.profile
>>> 
>>>
>>> >>> Q(user__name='Bob')
>>> 
>>>
>>> It overrides operators, so comparing factory with value returns a 
>>> related Q
>>> object:
>>>
>>> >>> Q.user.name == 'Bob'
>>> 
>>>
>>> Factory has several helper functions for lookups which aren't related to 
>>> 

Re: HMVC implementation on django

[Asif Saifuddin]

Hi,
This question should be posted in django-users mailing list, as this list 
is for discussing about django internals.

Anyway, you could read the answer 
here 
http://stackoverflow.com/questions/31914098/djangos-equivalent-of-php-codeigniters-hmvc

Thanks

On Tuesday, March 21, 2017 at 7:20:58 PM UTC+6, Shiwam Pd wrote:
>
> Can django be like HMVC framework? 
>
>

-- 
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/39486205-5bd0-49cd-aea2-b060cf076c28%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2017 Project Idea - Improve ORM by introducing real VirtualField and related field clean up

[Asif Saifuddin]

I have been working to understand the complexity for few months.

I will try to share my findings very soon. Lets see where I can reach
before the deadline.

On Mon, Mar 20, 2017 at 12:26 AM, Tim Graham <timogra...@gmail.com> wrote:

> It could be a suitable project, however, it's too late to develop a
> proposal of that complexity for this summer. A prospective student would
> need to demonstrate significant understanding of the ORM before I would
> advise them to tackle that topic.
>
> On Sunday, March 19, 2017 at 1:16:02 PM UTC-4, Asif Saifuddin wrote:
>>
>> Hi,
>>
>> I have been working on understanding previous works related to composite
>> ForeiegnKey/PrimaryKey support/ VirtualField support, works/tickets on
>> Fields API/RelationField API improvement/clean ups etc.
>>
>> Is it a good idea to prepare something like this for gsoc this year?
>>
>> I have also trying to prepare a dep for my plans of improvements.
>>
>> Thanks,
>>
>> Asif
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/django-developers/EWJdT4EVqbg/unsubscribe.
> To unsubscribe from this group and all its topics, 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/6a60f20a-8b15-49f4-9c15-
> ea7c17003bde%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/6a60f20a-8b15-49f4-9c15-ea7c17003bde%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/CAKAqTgpvV8y%2ByMUOKkBPvvbQJW9nc2sDsmY3B1BSAD-muE23kg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

GSOC 2017 Project Idea - Improve ORM by introducing real VirtualField and related field clean up

[Asif Saifuddin]

Hi,

I have been working on understanding previous works related to composite 
ForeiegnKey/PrimaryKey support/ VirtualField support, works/tickets on 
Fields API/RelationField API improvement/clean ups etc.

Is it a good idea to prepare something like this for gsoc this year?

I have also trying to prepare a dep for my plans of improvements.

Thanks,

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 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/372c3bc6-c618-43a7-aed7-da099c63e31d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Composite key development

[Asif Saifuddin]

Hi Julien,

I will publish it very soon.

Thanks

On Wednesday, March 1, 2017 at 5:58:50 AM UTC+6, Julien Phalip wrote:
>
> Hi Asif,
>
> That sounds good. On first look I did have some reservations about some of 
> the design details in the current DEP, especially around the observer 
> pattern for data binding. But I’m going to have to dig deeper into the 
> implementation to get a clearer idea.
>
> It’d be great if you could publish your work-in-progress at some point so 
> we can discuss the approach in more detail.
>
> Thanks,
>
> Julien
>
> On Mon, Feb 27, 2017 at 9:03 PM, Asif Saifuddin <auv...@gmail.com 
> > wrote:
>
>> Hi Julian,
>>
>> I have been also reviewing and studying the previous works, deps, 
>> discussions, codes and tickets. I have also been working to prepare a new 
>> dep based on the previous works.
>>
>> Like what Michal said, from my observation, I found the works and 
>> approaches of Michal is quite better and it's possible to break the work 
>> down into smaller parts to implement gradually.
>>
>> I am not quite sure how much work or which approaches of  Thomas 
>> Stephenson in 2015 could be mixed or needed with Michal's approach. In my 
>> humble opinion Michal spent more time in working on this and I also found 
>> his insights and suggestions on this topic more sensible.
>>
>> I would also like to work on this. My Dep is not yet ready for a push.
>>
>> You could certainly review and give you input on the Dep. Some core 
>> members suggested me to finalize a Dep before div into code.
>>
>> Let me know what your thoughts.
>>
>> Regards,
>>
>> Asif
>>
>> I have also contact with 
>>
>> On Tuesday, November 29, 2016 at 6:10:38 PM UTC+6, Craig Kerstiens wrote:
>>>
>>> Hi all,
>>>
>>> My company (Citus Data) is interested in sponsoring some Django work. In 
>>> particular work on support for composite primary keys. From what I 
>>> understand this wouldn't be the first time the work has been explored and 
>>> it sounds like it has a number of intricacies to it (
>>> https://github.com/django/deps/blob/master/draft/0191-composite-fields.rst 
>>> and 
>>> https://github.com/django/deps/blob/master/draft/0192-standalone-composite-fields.rst).
>>>  
>>> Our hope here is that it would be done in line with something that could 
>>> eventually become part of an official Django release vs. a one-off work 
>>> around. 
>>>
>>> While we know there's no guarantee of it being accepted, we'd love to 
>>> find someone with some knowledge of all the existing areas that would have 
>>> to be touched and has some experience contributing to Django core to 
>>> improve that likelihood. As part of the work, we would want the two 
>>> existing DEPs to be completed and work towards getting those accepted by 
>>> the broader community. And hopefully it goes without saying, but we'd fully 
>>> expect all the work to done in the open similar to other Django 
>>> development. 
>>>
>>> If you're interested in doing this work please reach out as we'd love to 
>>> discuss further. And if we have enough interest we'll be doing a full CFP 
>>> for the work to try to keep the process as fair as possible. 
>>>
>>> ~ Craig
>>>
>>> -- 
>> 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 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/cc29383b-b930-4d4c-9f48-51fa10909ecd%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/cc29383b-b930-4d4c-9f48-51fa10909ecd%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/1decacfd-667a-4b66-993d-48cf06f3599a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Composite key development

[Asif Saifuddin]

Hi Roger,

I do agree with your points. I have some thoughts which I will share in 
Dep/mailing list soon.

Thanks

On Tuesday, November 29, 2016 at 6:10:38 PM UTC+6, Craig Kerstiens wrote:
>
> Hi all,
>
> My company (Citus Data) is interested in sponsoring some Django work. In 
> particular work on support for composite primary keys. From what I 
> understand this wouldn't be the first time the work has been explored and 
> it sounds like it has a number of intricacies to it (
> https://github.com/django/deps/blob/master/draft/0191-composite-fields.rst 
> and 
> https://github.com/django/deps/blob/master/draft/0192-standalone-composite-fields.rst).
>  
> Our hope here is that it would be done in line with something that could 
> eventually become part of an official Django release vs. a one-off work 
> around. 
>
> While we know there's no guarantee of it being accepted, we'd love to find 
> someone with some knowledge of all the existing areas that would have to be 
> touched and has some experience contributing to Django core to improve that 
> likelihood. As part of the work, we would want the two existing DEPs to be 
> completed and work towards getting those accepted by the broader community. 
> And hopefully it goes without saying, but we'd fully expect all the work to 
> done in the open similar to other Django development. 
>
> If you're interested in doing this work please reach out as we'd love to 
> discuss further. And if we have enough interest we'll be doing a full CFP 
> for the work to try to keep the process as fair as possible. 
>
> ~ Craig
>
>

-- 
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/a97f240d-af26-4de4-9624-d2455e06eeba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Composite key development

[Asif Saifuddin]

Hi Julian,

I have been also reviewing and studying the previous works, deps, 
discussions, codes and tickets. I have also been working to prepare a new 
dep based on the previous works.

Like what Michal said, from my observation, I found the works and 
approaches of Michal is quite better and it's possible to break the work 
down into smaller parts to implement gradually.

I am not quite sure how much work or which approaches of  Thomas Stephenson 
in 2015 could be mixed or needed with Michal's approach. In my humble 
opinion Michal spent more time in working on this and I also found his 
insights and suggestions on this topic more sensible.

I would also like to work on this. My Dep is not yet ready for a push.

You could certainly review and give you input on the Dep. Some core members 
suggested me to finalize a Dep before div into code.

Let me know what your thoughts.

Regards,

Asif

I have also contact with 

On Tuesday, November 29, 2016 at 6:10:38 PM UTC+6, Craig Kerstiens wrote:
>
> Hi all,
>
> My company (Citus Data) is interested in sponsoring some Django work. In 
> particular work on support for composite primary keys. From what I 
> understand this wouldn't be the first time the work has been explored and 
> it sounds like it has a number of intricacies to it (
> https://github.com/django/deps/blob/master/draft/0191-composite-fields.rst 
> and 
> https://github.com/django/deps/blob/master/draft/0192-standalone-composite-fields.rst).
>  
> Our hope here is that it would be done in line with something that could 
> eventually become part of an official Django release vs. a one-off work 
> around. 
>
> While we know there's no guarantee of it being accepted, we'd love to find 
> someone with some knowledge of all the existing areas that would have to be 
> touched and has some experience contributing to Django core to improve that 
> likelihood. As part of the work, we would want the two existing DEPs to be 
> completed and work towards getting those accepted by the broader community. 
> And hopefully it goes without saying, but we'd fully expect all the work to 
> done in the open similar to other Django development. 
>
> If you're interested in doing this work please reach out as we'd love to 
> discuss further. And if we have enough interest we'll be doing a full CFP 
> for the work to try to keep the process as fair as possible. 
>
> ~ Craig
>
>

-- 
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/cc29383b-b930-4d4c-9f48-51fa10909ecd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to Integrate Django with Angular 2

[Asif Saifuddin]

This is not the place to ask such kind of questions, please post to 
django-users as this list is for discussing django internals.

On Thursday, January 12, 2017 at 1:08:29 AM UTC+6, Mohit Saran wrote:
>
> How to Integrate Django with Angular 2
>

-- 
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/37ee7bd4-fcd8-426b-a5f0-b0c3a621302e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.0 Python version support (Python 3.6+ only?)

[Asif Saifuddin]

Hi Josh,

How about keeping 3.5 support in 2.0.0? say the users of ubuntu 16.04 using 
systems python3.5 and update to 2.0 or started a new project with dj2.0.0 
in ubuntu 16.04.

About pyenv, it take care of installing and using different versions of 
python in a system without hampering the system python. There could be some 
pointer about possible alternatives IMHO.

I use pyenv regularly and it makes like of a python developer really great.

Thanks

On Sunday, January 8, 2017 at 6:00:08 PM UTC+6, Josh Smeaton wrote:
>
> Apparently I'm dumb and didn't read enough. pyenv *does* take care of 
> installation too. I'm not familiar enough with it (obviously..) to know 
> whether or not we should be encouraging its use.
>
> On Sunday, 8 January 2017 22:33:44 UTC+11, Josh Smeaton wrote:
>>
>> I don't think pyenv is really relevant to this discussion and not 
>> something we really need to promote. pyenv deals with making a particular 
>> installed python *available*, it doesn't handle the installation of that 
>> python.
>>
>> On Sunday, 8 January 2017 22:30:44 UTC+11, Asif Saifuddin wrote:
>>>
>>> Hi Josh,
>>>
>>> I do agree and support your idea's. How about pointing/recommend pyenv 
>>> for deployment in the doc?
>>>
>>> Thanks,
>>> Asif
>>>
>>> On Sunday, January 8, 2017 at 4:38:52 PM UTC+6, Josh Smeaton wrote:
>>>>
>>>> I guess I don't really see how we'd be helping users in any meaningful 
>>>> way by supporting python 3.4 with Django 2.0. Django 2.0's defining change 
>>>> is dropping Python 2. We have no idea what else will land in 2.0.
>>>>
>>>> If we're trying to consider Enterprise users on "older" Distros:
>>>>
>>>> - 1.11 will be LTS and will be supported for **longer** than Django 2.0 
>>>> will be.
>>>> - 1.11 supports 2.7 through to 3.6.
>>>> - The next LTS, which is likely the next version of Django for these 
>>>> Users, will support 3.6+
>>>>
>>>> If we're wanting users to upgrade their code bases to run on Python 3, 
>>>> then they certainly won't be doing it on Django 2.0. If they plan to move 
>>>> to Python 3 at all, it'll be on 1.11 or 2.2.
>>>> And if they want to be running on the latest and greatest Django, then 
>>>> why shouldn't that extend to adding an RPM repo or RedHat-SCL and 
>>>> installing the latest Python?
>>>>
>>>> I admit to a lack of knowledge on how to install new versions of Python 
>>>> on Ubuntu-likes. But https://ius.io/ is a great Redhat/Centos repo for 
>>>> installing newer Python versions.
>>>>
>>>>
>>>>
>>>>

-- 
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/4b54d28a-a4f2-469d-b096-dbbf7b362e9d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.0 Python version support (Python 3.6+ only?)

[Asif Saifuddin]

Hi Josh,

I do agree and support your idea's. How about pointing/recommend pyenv for 
deployment in the doc?

Thanks,
Asif

On Sunday, January 8, 2017 at 4:38:52 PM UTC+6, Josh Smeaton wrote:
>
> I guess I don't really see how we'd be helping users in any meaningful way 
> by supporting python 3.4 with Django 2.0. Django 2.0's defining change is 
> dropping Python 2. We have no idea what else will land in 2.0.
>
> If we're trying to consider Enterprise users on "older" Distros:
>
> - 1.11 will be LTS and will be supported for **longer** than Django 2.0 
> will be.
> - 1.11 supports 2.7 through to 3.6.
> - The next LTS, which is likely the next version of Django for these 
> Users, will support 3.6+
>
> If we're wanting users to upgrade their code bases to run on Python 3, 
> then they certainly won't be doing it on Django 2.0. If they plan to move 
> to Python 3 at all, it'll be on 1.11 or 2.2.
> And if they want to be running on the latest and greatest Django, then why 
> shouldn't that extend to adding an RPM repo or RedHat-SCL and installing 
> the latest Python?
>
> I admit to a lack of knowledge on how to install new versions of Python on 
> Ubuntu-likes. But https://ius.io/ is a great Redhat/Centos repo for 
> installing newer Python versions.
>
>
>
>

-- 
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/f74d4ef9-07b9-4bae-b8a7-4fefbc6cb0cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.0 Python version support (Python 3.6+ only?)

[Asif Saifuddin]

Hi,

django 2.0 will be released in december 2017 and ubuntu 18.04 will be 
released in april 2018 which will default atleast 3.6, so I think this 
should also be taken as consideration while deciding.

Thanks 

On Wednesday, January 4, 2017 at 1:00:00 AM UTC+6, Tim Graham wrote:
>
> August 2016: PyPy gets funding from Mozilla for Python 3.5 support
> "Within the next year, we plan to use the money to pay four core PyPy 
> developers half-time to work on the missing features and on some of the big 
> performance and cpyext issues. This should speed up the progress of 
> catching up with Python 3.x significantly. "
>
> https://morepypy.blogspot.com/2016/08/pypy-gets-funding-from-mozilla-for.html
>
> According to http://pypy.org/py3donate.html, it seems that anyone who 
> cares can donate to the effort of porting PyPy to Python 3. Django 
> 1.11/Python 2 will be supported until 2020 anyway.
>
> On Tuesday, January 3, 2017 at 1:04:02 PM UTC-5, Florian Apolloner wrote:
>
>> Mhm, just thought about the fact that this means we are also dropping 
>> support for PyPy and Jython -- not sure about the Jyton usage, but loosing 
>> PyPy sounds sad, how far along are there python 3 efforts? It looks like it 
>> is/was close to 3.3 according to 
>> https://morepypy.blogspot.co.at/2016/08/pypy-gets-funding-from-mozilla-for.html
>>
>> Cheers,
>> Florian
>>
>> On Tuesday, December 27, 2016 at 11:03:22 PM UTC+1, Tim Graham wrote:
>>>
>>> Yes, Django 1.11 is the last version to support Python 2.7. This is 
>>> documented in the 1.11 release notes, in 
>>> https://www.djangoproject.com/download/#supported-versions, and 
>>> elsewhere. 
>>>
>>> On Tuesday, December 27, 2016 at 4:37:06 PM UTC-5, MMeent wrote:

 I won't mind dropping support for Python versions that are not 
 supported up to the end of the support period of the next LTS (2.2 in this 
 case). If you want to use long-term stability and/or support for current 
 Python versions, you should use the current django LTS version, which will 
 be 1.11. I am perfectly fine with django dropping support for a python 
 version that won't be supported for over 1 1/2 years of that (major) 
 versions support cycle.

 Noting that python 2.x also has an EOL in 2020, this one being half a 
 year earlier (March 16th vs September 13th), will django 2.0 drop 
 python 2.7 support, or will the 2.x series continue support for 2.7? I 
 cant 
 really find definite docs on that. 
 (https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ talks about 
 it but is not completely clear)

 If django drops 2.7 for django 2.x, a lot of code will probably be 
 reworked, and seeing the 3.6 features I would love to see those available 
 directly while removing/refactoring the compat-layer. e.g. f-strings 
 instead of "{}".format or %-formatting, as it is less prone to random 
 bugs like https://code.djangoproject.com/ticket/6343 .


 -Matthias

 On 27 Dec 2016 21:25, "Florian Apolloner"  wrote:

> Imo we should not drop Python versions overeagerly. After all I do not 
> wanna compile our own python for djangoproject.com :D Given that 
> Redhat is on Python 3.4 for the foreseeable future, I'd actually even 
> like 
> to see 3.4 still supported in Django 2.0 unless there is a good reason to 
> drop it. Fwiw, Ubuntu Trusty which is LTS and still supported also is on 
> Python 3.4. So unless there are compelling arguments to drop 3.4, lets 
> keep 
> it as long as it is not too much work.
>
> Either way, I am completely against dropping Python 3.5 now -- lets 
> make the Django 2.0 migration not more painful than it has to be (ie I do 
> not want to force people to upgrade existing supported systems just to 
> get 
> the latest python and therefor Django).
>
> Cheers,
> Florian
>
> On Tuesday, December 27, 2016 at 4:12:57 PM UTC+1, Tim Graham wrote:
>>
>> When I drafted the 1.11 release notes in May, I wrote, "The next 
>> major release, Django 2.0, will only support Python 3.5+."
>>
>> Our Python version support policy is "Typically, we will support a 
>> Python version up to and including the first Django LTS release whose 
>> security support ends after security support for that version of Python 
>> ends."
>>
>> Python 3.5's EOL is September 2020 which I think is sufficiently 
>> close to Django 1.11's EOL of April 2020 that we could say Django 2.0 is 
>> Python 3.6+. The alternative is not to drop Python 3.5 compatibility 
>> until 
>> Django 2.2 LTS which is supported until April 2022. I don't see much 
>> advantage to that. Any objections?
>>
>> p.s. There is already a ticket suggesting to take advantage of a 
>> Python 3.6 feature:
>> https://code.djangoproject.com/ticket/27635* - *django.utils.crypto 
>> 

Re: Error after installing django-tracking2 package for tracking user activity

[Asif Saifuddin]

Hi,

This mailing list for for discussing the development of django internals. 
For your queries please post in django-users list.

Thanks

On Wednesday, January 4, 2017 at 6:30:33 PM UTC+6, Gunwant Suryawanshi 
wrote:
>
> Hi,
> I am trying to track user activity on my website, for that purpose I am 
> using django-tracking2 package. But after successfully installation I am 
> getting following error:-
>
> relation "tracking_visitor" does not exist 
>
> LINE 1: ...time_on_site", "tracking_visitor"."end_time" FROM "tracking_...
>   
>
> So anyone having idea how to resolve it?
>

-- 
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/df2a6721-dc64-4f3c-8fae-cc4ec50a7a6c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Working towards a simpler GCBV implementation?

[Asif Saifuddin]

Hi,

I will update the doc pointing vanilla views as simpler alternative 
implementation.

Thanks

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 <auv...@gmail.com 
> > 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-develop...@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/5792872e-157c-4ba6-87c1-bf0f5a07d981%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/5792872e-157c-4ba6-87c1-bf0f5a07d981%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Adam
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/830ad07c-c539-4553-a1a9-69e53c25af0d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Working towards a simpler GCBV implementation?

[Asif Saifuddin]

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.

Re: status of 1.11 release blockers

[Asif Saifuddin]

Hi,

this feature https://github.com/django/django/pull/7482 will also be a very 
good inclusion.

Thanks

On Thursday, December 22, 2016 at 5:16:51 AM UTC+6, Tim Graham wrote:
>
> Time to kickoff the progress tracker for the next major release!
>
> The 1.11 alpha is currently scheduled for January 16. My brother is 
> getting married on the 15th, so it's unlikely I'll be doing much merging 
> over that weekend. Maybe we can freeze at the end of the day on Friday and 
> do the alpha release on Monday or Tuesday. The week before, I'll give 
> review priority to any tickets marked "ready for checkin" by Monday, 
> January 9. Please don't complain to me that your patch isn't included in 
> 1.11 if you miss that deadline. :-)
>
> The only "major feature" on the 1.11 roadmap [0] is template-based widget 
> rendering which is (hopefully) in final reviews [1]. There are still plenty 
> of "patches needing review" [2] if you want to help there.
>
> There aren't any known release blockers at this time.
>
> [0] https://code.djangoproject.com/wiki/Version1.11Roadmap
> [1] https://github.com/django/django/pull/6498
> [2] 
> https://code.djangoproject.com/query?status=!closed_better_patch=0_tests=0_docs=0_patch=1=Accepted
>

-- 
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/449b82f1-dadd-4aac-bfa8-bfebc1ad4912%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django-formtools is neglected/unmaintained

[Asif Saifuddin]

Hi Tim,

In case there is lack of active maintainers for the project then you could 
add me to the list of maintainers. I do contribute to django eco system 
regularly.

my github activities:

github.com/auvipy


And about moving to jazzband, I do take part in django-admin2 maintenance 
there with the two other old maintainers, The fact is moving it to jazzband 
haven't increased the active co maintainers.

Thanks,

Asif

On Tuesday, November 29, 2016 at 5:45:59 AM UTC+6, Tim Graham wrote:
>
> Hi,
>
> django-formtools seems neglected. It's been several months since the 
> release of Django 1.10 but a compatible version of formtools hasn't been 
> released to PyPI.
>
> Personally, I don't know if it's important to maintain it as an "official 
> project." An alternative could be to "donate" it to JazzBand (
> https://jazzband.co/) and see if the community maintains it.
>
> If you have an interest in this package (especially if you want to 
> maintain it), let us know.
>

-- 
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/548e6564-5bc8-45be-92db-3fe05d592c11%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Working towards a simpler GCBV implementation?

[Asif Saifuddin]

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/fc65b52a-df29-48be-8bef-fb6fabb19d97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: I'm looking for a part-time job in Django

[Asif Saifuddin]

Hi uri,

this list is for development of django internals/itself only.

Reagrds,
Asif

On Sunday, August 14, 2016 at 1:27:19 PM UTC+6, uri wrote:
>
> To django-d...@googlegroups.com ,
>
> I'm looking for a part-time job in Django, do you know anything? I live in 
> Herzliya, Israel. I can't relocate but I can work from home. I can also 
> help developing the next versions of Django. You can see my CV on LinkedIn. 
> Please let me know if you have any job for me.
>
> Thanks,
> Uri.
>
> *Uri Even-Chen*   
> [image: photo] Phone: +972-54-3995700
> Email: u...@speedy.net 
> Website: http://www.speedysoftware.com/uri/en/
>   
>   
>   
>

-- 
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/1963b463-8d10-48d5-b5cd-d29e412e2fa0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using "py2" Trac keyword to tag Python 2-specific issues

[Asif Saifuddin]

Hi Tim,

If you need help while removing support of python2 from code base you could 
knock me.

Thanks

On Tuesday, May 31, 2016 at 12:34:23 AM UTC+6, Tim Graham wrote:
>
> I've started tagging Python 2-specific Trac tickets with the "py2" 
> keyword. You can view such issues using:
>
> https://code.djangoproject.com/query?status=!closed=~py2
>
> Since Django 1.11 will be the last version of Django to support Python 2, 
> my plan is to close these issues if they don't receive any attention by the 
> 1.11 beta release, scheduled for February 20, 2017.
>

-- 
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/56f6a134-dbea-470b-9266-0ca3a61f6fc2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: SQL ALchemy support on django

[Asif Saifuddin]

Hi,

I failed to apply for gsoc, but I planned to give some effort on this 
whenever I get some time. Anyone having interest and time could help he 
with some tecnical guidence. Much more to do there. 

Thanks

https://github.com/TrendBreaker/django-alchemy

On Friday, March 4, 2016 at 2:00:11 PM UTC+6, Asif Saifuddin wrote:
>
> Hi,
>
> I will be working on preparing a proposal for sql-alchemy support on 
> django. [thorugh model meta]. 
>
> Thanks
>
> On Wednesday, September 16, 2015 at 2:35:15 PM UTC+6, Asif Saifuddin wrote:
>>
>> Hi,
>>
>>
>> How much difficult it will be to add SQLalchemy support to django? what 
>> are the technical difficulties? And which are the ways to add sqlalchemy 
>> support to django?
>>
>> As SQLalchemy is separated in core and orm will it be wise to use 
>> sqlalchemy core as the backend for django orm? Or  through the meta api? 
>> any suggestion or direction to the solutions?
>>
>> The available 3rd party packages seems to be incomplete.
>>
>>
>> Regards
>>
>> 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 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/e08e4be5-372e-4a8c-8505-f1e2fa91ef57%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Rewriting admin internals

[Asif Saifuddin]

Hi Tom,

> I'd suggest that a side-project of redesigning the Django Admin from 
scratch isn't a realistic goal.

I also think that working on existing outstanding ticket first and trying 
to solve issues incrementally would be a good approach?

Thanks

On Thursday, May 26, 2016 at 3:28:09 PM UTC+6, Tom Christie wrote:
>
> > But for the money I don't have any initial source to manage It.
>
> Jacob is using the figure more to give an idea of the amount of effort he 
> believes it would involve, rather than suggesting that we should make a 
> serious attempt to raise that amount of money.
>
> > can you guide/ show me any previous work/discussion/technical specs etc?
>
> I'd search for DjangoCon and Django Under the Hood videos if you want to 
> find some technical discussions on the subject.
>
> Searching through outstanding django tickets related to the admin and 
> attempting to fully understand them would also be a good way of learning 
> about what pain points exist with the admin.
>
> > I would like to hear from core members about the works right directions
>
> I'd suggest that a side-project of redesigning the Django Admin from 
> scratch isn't a realistic goal.
>
>

-- 
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/c99c3549-3e7f-40d7-9223-73cfd09089aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Rewriting admin internals

[Asif Saifuddin]

Hi jacob,

happy to see your insightful reply. I think I'm going to start the process 
with a draft dep soon and I'm planning to devote my engagement in the 
development too.

Will keep you suggestions in mind :)

thanks,

Asif

On Wednesday, May 25, 2016 at 2:45:42 PM UTC+6, Asif Saifuddin wrote:
>
> Hi,
> the admin app of django is consists of many old day codes. How about 
> rewriting it with present day approaches? adopting ideas from django-admin2 
> where possible? and how about using jinja2 templates as default for admin? 
>
> thanks,
>
> 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 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/38fc9cbb-d82a-4665-bab5-ba68b8249316%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Rewriting admin internals

[Asif Saifuddin]

Hi is_null,

form refactor is an important part but that shouldn't stop us from starting 
the process.

thanks

On Wednesday, May 25, 2016 at 3:19:36 PM UTC+6, is_null wrote:
>
> Shouldn't the forms refactor happen first ? 
>

-- 
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/94bcf3fb-8bb1-4569-b5b5-b879e5c8887a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Rewriting admin internals

[Asif Saifuddin]

Hi,
the admin app of django is consists of many old day codes. How about 
rewriting it with present day approaches? adopting ideas from django-admin2 
where possible? and how about using jinja2 templates as default for admin? 

thanks,

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 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/b0c8ff85-fe32-4c91-95ad-f192246b2049%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Better form fields for django.contrib.postgres.fields

[Asif Saifuddin]

Hi,

The first step is the ticket need to be accepted and then push the change 
as pull request on master branch.

Thanks

On Monday, May 23, 2016 at 6:56:43 PM UTC+6, Paul Martin wrote:
>
> Hi,
>
> This is my first time contributing to Django. It's a lot of different 
> features in one to improve how form fields are produced for ArrayField, 
> HStoreField and JSON FIeld.
>
> I opened a ticket here with more details and a screenshot of the admin for 
> a sample model.
>
> https://code.djangoproject.com/ticket/26654
>
> I guess the next step is to push my code as a new branch?
>

-- 
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/1eba0104-acff-4c15-80ff-5e82c9b479e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: URL dispatching framework: feedback requested

[Asif Saifuddin]

Can we expect this to be merged on 1.10 alpha? after that the minor 
imporvements could be take place.

Thanks

On Monday, December 28, 2015 at 10:23:19 PM UTC+6, Marten Kenbeek wrote:
>
> Hi everyone,
>
> This past week I've made some great progress in rewriting the URL 
> dispatcher framework and iterating on my implementation. A big part of my 
> effort to refactor my original code was to increase the performance of 
> reverse() to a level similar to the legacy dispatcher, and to decouple 
> the various parts of the code. I think I have now achieved both goals, so 
> I'd like to get some feedback on the result. 
>
> The current code can be found at 
> https://github.com/django/django/pull/5578.
>
> I will be cleaning up the code and shuffling around some of it. There's 
> still a lot to be done, but the high-level design and public API are pretty 
> much finished and ready for review. 
>
> The API consists of 4 parts, most of which are extendible or replaceable: 
> a Dispatcher, a set of Resolvers, Constraints and the URL configuration. 
>
> The main entry point for users is the Dispatcher class. The dispatcher is 
> responsible for resolving namespaces and reversing URLs, and handles some 
> of the utility functions available to users (some more may be moved here, 
> such as is_valid_path() or translate_url()). It is a thin wrapper around 
> the root Resolver to allow a single entry point for both reversing and 
> resolving URLs. It currently provides the following public API:
>
>- Dispatcher.resolve(path, request=None) -> Resolve path to a 
>ResolverMatch, or raise Resolver404. 
>- Dispatcher.resolve_namespace(viewname, current_app=None) -> Resolve 
>the namespaces in viewname, taking current_app into account. Returns 
>resolved lookup in a list.
>- Dispatcher.reverse(lookup, *args, **kwargs) -> Reverse lookup, 
>consuming *args and **kwargs. Returns a full URL path or raises 
>NoReverseMatch. 
>- Dispatcher.resolve_error_handler(view_type) -> Get error handler for 
>status code view_type from current URLConf. Fall back to default error 
>handlers. 
>- Dispatcher.ready -> (bool) Whether the dispatcher is fully 
>initialized. Used to warn about reverse() where reverse_lazy() must be 
>used. 
>
> I'm currently looking into possible thread-safety issues with 
> Dispatcher.load_namespace(). There are some parts of Django that depend 
> on private API's of Dispatcher and other parts of the dispatching 
> framework. To maximize extensibility, I'll look if these can use public 
> API's where appropriate, or gracefully fail if a swapped-in implementation 
> doesn't provide the same private API. One example is admindocs, which uses 
> the Dispatcher._is_callback() function for introspection. 
>
> If a developer wishes to completely replace the dispatcher framework, this 
> would be the place to do it. This will most likely be possible by setting 
> request.dispatcher to a compatible Dispatcher class. 
>
> The BaseResolver class currently has two implementations: Resolver and 
> ResolverEndpoint. The resolver's form a tree structure, where each 
> resolver endpoint is a leaf node that represents a view; it's job is to 
> resolve a path and request to a ResolverMatch. Users will mostly use this 
> through Dispatcher.resolve(), rather than using it directly. Its public 
> API consists of two functions:
>
>- BaseResolver.resolve(path, request=None) -> Return a ResolverMatch or 
>raise Resolver404.
>- BaseResolver.describe() -> Return a human-readable description of 
>the pattern used to match the path. This is used in error messages. 
>
> There is a slightly more extensive API that allows a resolver to "play 
> nice" with Django's resolver implementations. This allows a developer to 
> replace a single layer of resolvers to implement custom logic/lookups. For 
> example, you can implement a resolver that uses the first hierarchical 
> part of the path as a dict lookup, rather than iterating each pattern. To 
> make this possible, a resolver should accept the following arguments in its 
> constructor:
>
>- BaseResolver.__init__(pattern, decorators=None) -> pattern is a 
>URLPattern instance (explained below). decorators is a list of 
>decorators that should be applied to each view that's a "descendant" of 
>this resolver. This list is passed down so the fully decorated view can be 
>cached. 
>
> I'm still looking how exactly we'd allow a developer to hook in a custom 
> resolver, any ideas are welcome. 
>
> Constraints are the building blocks of the current dispatcher framework. A 
> Constraint can (partially) match a path and request, and extract 
> arguments from them. It can also reconstruct a partial URL from a set of 
> arguments. Current implementations are a RegexPattern, 
> LocalizedRegexPattern, LocalePrefix and ScriptPrefix. This is the main 
> extension point for developers. I envision that over time, Django will 

Re: GSoC 2016: Draft Proposal on SQLAlchemy Integration with django

[Asif Saifuddin]

Hi Tim,

I have been sick for few days so couldn't work fully on the proposal. To 
give you have some idea on what I will be doing:

* creating a django-sqlalchemy package like flask-alchemy/pyramid_alchemy 
which user can use on any regular django project under installed app. The 
package will need different type of configurations specific to sqlalchemy 
and django to work properly.
* sqlalchemy has core, orm and declarative systax[more identical to 
django]. core is more like django expressions API based on which the ORM is 
built. But recently to make sqlalchemy more user friendly declarative 
syntax extension has been added to the library and user can use any one of 
the three according to there need. for regular business logic declarative 
sysntax is OK. but for more flexibility the ORM layer could be used, and 
for different advanced sql features core sql expression language is best 
way. these three can be used simultenuously in a project according to the 
need. to manage sqlalchemy there are different 3rd party tools like django 
has different utility in DB/ORM, management commands, migration handling, 
form generator, admin app etc.

>From the suggestions of Russel keith-magee and Ansi, integrating sqlalchemy 
with django actualy means having sqlalchemy utilities which are related to 
table definition to work like django model/fields etc through model._meta 
API, that means the SQLalcmey table definitions could work smoothly with 
django form.model form and can be manipulated through admin app. For that I 
have to map sqlallchemy table definitions to work like django model fields 
so tht they can easily used by _meta API.

There are some parts of django which also need work to the alchemy package. 
many details needed to be in the proposal on how I should approach to gain 
the desired goal. about technical detail some are I think I have figured 
out but there could be more room to figure out and at the time of working 
there might be some new thing could be found. 

For technical detail do you have any specific suggestions following those 
will let the core devs properly understand and comment on?

Best Reagards,

Asif

On Friday, March 18, 2016 at 6:11:12 PM UTC+6, Asif Saifuddin wrote:
>
> Hi,
>
> I have been working for preparing a proposal on SqlAlchemy integration 
> with django. While I haven't done with in detail proposal and in depth 
> technical specs, I'm posting my very draft proposal to understand If the 
> broader strokes of my approach are nearly OK and I should proceed with the 
> current approach. Critiques and suggestions are very much appreciated.
>
> https://gist.github.com/auvipy/33a57f6166549fd7c4c8
>
> Regards,
>
> 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 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/66e40ca2-3647-4740-873e-92691e04f7a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Integration

[Asif Saifuddin]

Hi,

about the DRF integration in django I went through the dep and the branch 
of tom christies work. He shared his opinion as some one should do the work 
and he will provide guidance. I still have some interest in the REST parts 
work. If Tom christie/DSF core team allows.

Thanks

Asif

On Saturday, March 5, 2016 at 6:16:31 AM UTC+6, Chad Paulson wrote:
>
> I was happy to read that part of the Mozilla Open Source Support program 
> funding that was recently awarded to the Django Software Foundation will go 
> toward integrating key components of Django REST Framework into Django.
>
> Since I haven't found any update since the initial announcement in 
> December, I was curious what the status of this integration is and, if 
> possible, how soon it might be available.
>
> https://www.djangoproject.com/weblog/2015/dec/11/django-awarded-moss-grant/
>

-- 
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/c34f919b-788b-4987-aa80-7085f9aefde4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: SQL ALchemy support on django

[Asif Saifuddin]

Hi,

I will be working on preparing a proposal for sql-alchemy support on 
django. [thorugh model meta]. 

Thanks

On Wednesday, September 16, 2015 at 2:35:15 PM UTC+6, Asif Saifuddin wrote:
>
> Hi,
>
>
> How much difficult it will be to add SQLalchemy support to django? what 
> are the technical difficulties? And which are the ways to add sqlalchemy 
> support to django?
>
> As SQLalchemy is separated in core and orm will it be wise to use 
> sqlalchemy core as the backend for django orm? Or  through the meta api? 
> any suggestion or direction to the solutions?
>
> The available 3rd party packages seems to be incomplete.
>
>
> Regards
>
> 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 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/57f06658-bce9-4d1b-80d6-d4e5bee3cd5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Index expressions

[Asif Saifuddin]

Hi Tim,

Thanks for your early input on the issue. I don't think I should compete 
with any specific proposal which already have another better competitor. I 
did some research on  SQLalchemy backend support on django and relevant 
improvement long ago before class based index. I will go for a sqlalchemy 
support on django then. and will try to contribute on relevant field too to 
prove myself as a strong candidate for that proposal. do you know any one 
else working on SQLalchemy support? or should I proceed aboout this?

Thanks

On Sunday, February 7, 2016 at 5:11:59 PM UTC+6, Curtis Maloney wrote:
>
>
> So, in #django recently there was a discussion about adding an index on 
> a date field for just the year. 
>
> I know the idea was raised some time ago, and several ideas on the 
> syntax were expressed.  But most of that focused on different types of 
> indices - not on indexing expressions. 
>
> It occurred to me that with the recent advances in expression syntax, it 
> should be fairly easy to add an indexes list to Meta to define complex 
> expressions. 
>
> Input? 
>
> -- 
> C 
>

-- 
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/59d4cf64-2816-4d3d-8252-20faf9df835c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Index expressions

[Asif Saifuddin]

Hi Josh,

I'm willing to work on django orm improvment for gsoc and considering 
custom index as a project idea. I have gone through the available resources 
like dep, POC on class based index, unification of transform API etc. What 
others stuff do you suggest me to look into to have some concrete ideas to 
complete a very good proposal.

Thanks
Asif

On Sunday, February 7, 2016 at 5:11:59 PM UTC+6, Curtis Maloney wrote:
>
>
> So, in #django recently there was a discussion about adding an index on 
> a date field for just the year. 
>
> I know the idea was raised some time ago, and several ideas on the 
> syntax were expressed.  But most of that focused on different types of 
> indices - not on indexing expressions. 
>
> It occurred to me that with the recent advances in expression syntax, it 
> should be fairly easy to add an indexes list to Meta to define complex 
> expressions. 
>
> Input? 
>
> -- 
> C 
>

-- 
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/39ccca4c-735e-4add-9124-2752002c13c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Search Refiner - Can anyone skype and help me?

[Asif Saifuddin]

Hi,

This group is for development of django itself/internals. for your problem 
please post to django-users mailing list.

Regards,

Asif

On Tuesday, January 26, 2016 at 8:43:27 AM UTC+6, eZ_Harry wrote:
>
> Hello,
>
> I have stuck making a search refiner for my website and have been stuck 
> for so long now, I am really just in need of some direction and to get 
> someone to tell me roughly how I should be going about it. If anyone could 
> help me that would be greatly appreciated. Just message me and ill send 
> over my skype. Cheers
>

-- 
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/b9ca5cdb-d6cf-4a88-928c-f69e74fabad6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: MOSS Award to Django

[Asif Saifuddin]

Awesome  awesome !!! awesome!!! :D :D

On Saturday, December 12, 2015 at 12:19:00 AM UTC+6, Andrew Godwin wrote:
>
> Hi everyone,
>
> For those who haven't seen, Mozilla has awarded $150,000 to Django for 
> work on Channels and request/response improvements lifted from REST 
> Framework. More in the blog post here: 
> https://www.djangoproject.com/weblog/2015/dec/11/django-awarded-moss-grant/
>
> I'll be coordinating this effort for the most part, but we're still 
> working out who to fund and the roadmap for the project, as well as work 
> out how we can pay people for their work on a different scale to the Django 
> Fellowship, so it might take a bit of time!
>
> I'll be back on here with some questions for people to discuss/answer 
> about the channels design at some point soon, but a lot of the basic design 
> is already up at http://channels.readthedocs.org, so take a read over 
> that if you're interested.
>
> What I can say is that my intention is to both bake Channels into the next 
> major release of Django, as well as hopefully release a pluggable app 
> version that will run on 1.8 and 1.9 - I have some plans around how to do 
> that effectively, but they involve hitherto unforged paths around Django 
> and how we package dependencies, so I can't say we'll get there 100%.
>
> 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/bbeea75a-1026-42f1-9cb4-56be0c8a08b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: use SQLAlchemy Core for query generation

[Asif Saifuddin]

Hi Luke,

I have been thinking and researching a lot recently about SQLalchemy and 
django integration.

Now SQLalchemy provides a devlarative orm extension too quite identical to 
django orm[not same], django has also refactored a lot in db internals with 
model meta refactore, expressions, new migrations and many stuff.

There would be 2 new approach for your proposal--

1) Probably the people used to/willing to use sqlalchemy's declarative orm 
extension will use that and there will be needed to create new model meta 
API driven abstraction layer which will help to show sqlalchemy generated 
models in django admin and django form/model form.
  * migrations would be handled by alaembic/sqlalchemy-migrate/whatever 
best available

2) Django Model ORM will be  rewritten in a 3rd party project as a parallel 
counterpart/equivalent to SQLalchemy's declarative ORM extension which will 
work like django model//migrations/command based normal djangoish workflow 
but under the hood will be used by sqlalchemy core/3rd party tools.

I'm willing to address the both issue in a solid 3rd party package. In both 
case propably django internal too needed to be ironed for edge cases.

I'm trying to tracking this thoughts in a git repo and also looked for some 
older attempts to understand the implementation way.

Looking forward to hear your thoughts.


Regards,

Asif



On Saturday, June 30, 2012 at 8:22:21 PM UTC+6, Luke Plant wrote:
>
> Hi all, 
>
> A good while back I put forward the idea of using SQLAlchemy Core in 
> Django [1]. Having had more experience working with SQLAlchemy, I'm 
> putting that idea forward as a formal proposal, as I mentioned in a more 
> recent thread here. 
>
> Apologies in advance for the length! I've included a few 'TL;DR' 
> summaries and headings in the different sections which you might want to 
> scan first. 
>
> === Proposal === 
>
> We should re-write our query generation code to use SQLAlchemy Core. 
> This includes DDL queries as well as DML (e.g. CREATE TABLE as well as 
> SELECT, INSERT etc). 
>
> This would also involve replacing our database connection objects with 
> SQLAlchemy's. In this proposal, our high-level ORM, with model 
> definition and query API, would remain the same - we wouldn't be using 
> the SQLAlchemy ORM. 
>
> This is a "Django 2.0" proposal i.e. not immediate future, and not fully 
> backwards compatible. 
>
> === Background - Django 2.0 philosophy === 
>
> TL;DR: "evolution not revolution, some backwards incompatibilities" 
>
> Although we haven't really discussed the timing of Django 2.0, or its 
> philosophy, I think we should be doing. My own assumption is that it 
> should be evolution, not revolution, similar to Python 3, where we break 
> stuff that has dogged us in the past, and will hamper us going forward, 
> but don't make radical changes where not necessary. This proposal fits 
> that basic assumption. 
>
> Also, in Django to date we've eschewed external dependencies. That has 
> been partly due to the poor and confusing state of Python packaging, 
> which is hopefully improving. I think it will make us a very poor Python 
> citizen if we don't reverse this policy at some point, and Django 2.0 is 
> an obvious point to do it. 
>
> This proposal does not represent a move away from being a 'full stack' 
> framework. "Full stack" does not mean "no dependencies". 
>
> Our current recommended installation method is via pip [2], and we would 
> be doing our users a disservice to recommend otherwise. Installation via 
> pip actually makes the instructions shorter - manual methods require 
> things like removing old versions manually - and for anything beyond 
> trivial use of Django you have to know pip anyway. 
>
> So, with our recommended installation method, adding a dependency 
> doesn't make things any more difficult at all. 
>
> === Background - ORM philosophy === 
>
> TL;DR: "Let's make Django's DB layer the best it can be for relational 
> databases." 
>
> Whether we call it "the ORM" or "the model layer" as some people prefer, 
> I think it's fairly certain that the overwhelming majority of our users 
> are using relational databases. 
>
> Many of the things that make Django a compelling choice, 
> including the admin and re-usable apps, either don't work or are of 
> little use if you are not using a relational database. 
>
> So my philosophy is that we should aim to provide a really excellent 
> ORM that will take users as far as possible. 
>
> This doesn't preclude having non-relational support in Django. But 
> it seems very strange to make that the focus, when we've had 
> little-to-no support for it so far, or to allow that support to limit 
> how well we can cater for the 99%. 
>
> === Motivation === 
>
> == Motivation 1: Django's ORM leaves you high and dry when you reach its 
> limits. 
>
> While the ORM can do a surprising number of queries, there are plenty it 
> can't, and in all the medium-to-large projects I've worked on I've 

Re: Integrating Django with Tornado's web server

[Asif Saifuddin]

Hi,

I used django-websocket-redis for implementing webscet in django project.

You could try that.

Regards

Asif

On Monday, September 14, 2009 at 3:30:59 AM UTC+7, Bret Taylor wrote:
>
> I am one of the authors of Tornado (http://www.tornadoweb.org/), the 
> web server/framework we built at FriendFeed that we open sourced last 
> week (see http://bret.appspot.com/entry/tornado-web-server). 
>
> I just checked in change to Tornado that enables you to run any WSGI- 
> compatible framework on Tornado's HTTP server so that Django apps 
> could run on top of Tornado's HTTP server and benefit from some of the 
> performance work we have done. (I just sent a message to django-users@ 
> with getting started instructions as well, but if you are interested, 
> take a look at 
> http://github.com/facebook/tornado/blob/master/tornado/wsgi.py#L188). 
>
> I chose the WSGI approach because it is generic and applies to all 
> frameworks, but Django is obviously the most widely used. I am curious 
> if there is any benefit to implementing more "native" support in 
> django.core.handlers or if WSGI is the preferred way of adding support 
> for new servers. If there is any performance or usability benefit, let 
> me know, because we would be happy to contribute our time to make it 
> happen. 
>
> In the meantime, if you find any issues with our WSGI support, let me 
> know so we can fix problems. 
>
> Bret 
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/84486ed5-ee46-42d1-8925-e1d9ff7984e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: annoyance with Python 3.2 support in Django 1.8

[Asif Saifuddin]

Python 3.2 should be removed as if any one use py3 should use 3.3+ or 
better the latest stable.

best

Asif

On Thursday, November 26, 2015 at 6:36:53 AM UTC+6, Tim Graham wrote:
>
> Django 1.8 is the last version to support Python 3.2. Python 3.2 is 
> scheduled to be end of life at February 2016 [1] while Django 1.8 is 
> scheduled to be supported until April 2018. The latest security release for 
> the 3.2 series, Python 3.2.6 contained a regression that causes 30 admin 
> test failures in the Django test suite related to parsing of httponly 
> cookies. I'm not sure if this problem is limited to the test client or if 
> it has the potential to cause problems in a web server context (if anyone 
> is using Python 3.2.6, I'd be interested to know). I submitted a patch to 
> Python to correct the issue [2], but it appears unlikely that the patch 
> will be applied along with a new release (no response from Python 3.2 
> release manager in 1 year).
>
> Due to the test failures, we cannot run the Django test suite with Python 
> 3.2 on the Ubuntu 14.04 CI machines which use the deadsnakes PPA [3] to 
> install the latest version of Python (3.2.6). Therefore the tests are 
> limited to running on our one remaining Ubuntu 12.04 CI machine which 
> includes Python 3.2.3 (deadsnakes doesn't bundle versions of Python that 
> would override the one included by the distribution). Support for Ubuntu 
> 12.04 ends April 2017, so we shouldn't keep that machine longer than that.
>
> Options:
> 1. Drop Python 3.2 support for Django 1.8 sometime before Django 1.8 EOL
> 2. Keep Python 3.2 support until Django 1.8 EOL:
>   a. Don't worry about CI support and rely on local testing of security 
> fixes (we had the same situation with Django 1.4 and Python 2.5)
>   b. Install the latest non-broken Python 3.2 release (3.2.5) "manually" 
> (without using deadsnakes) on the newer CI servers
> 3. Your idea
>
> Thanks for your feedback!
>
> [1] https://www.python.org/dev/peps/pep-0392/
> [2] https://bugs.python.org/issue22758
> [3] https://launchpad.net/~fkrull/+archive/ubuntu/deadsnakes
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bfc650af-6c28-4bc3-b792-5ae212accdb4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bringing some popular must have django tools/packages under django org umbrella

[Asif Saifuddin]

The projects will have the official tool status + the maintainer of the
projects will be able to collaborate better with django core team? less
risk of being abandoned by the maintainers etc.

IMHO

On Wed, Nov 25, 2015 at 12:31 AM, Collin Anderson <cmawebs...@gmail.com>
wrote:

> Hi,
>
> Say a little bit more: What would be the goal? What would you hope would
> be accomplished by doing this?
>
> Thanks,
> Collin
>
> On Tuesday, November 24, 2015 at 1:27:11 PM UTC-5, Asif Saifuddin wrote:
>>
>> How is the idea? tools like django-debug-toolbar, django-silk,
>> django-taggit, django-filter etc and some more de facto tools under the
>> umbrella of django github org?
>>
>> Regards
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/bIzfHebE2sw/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/70062405-3ccd-49b2-9118-ec1679203cd1%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/70062405-3ccd-49b2-9118-ec1679203cd1%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKAqTgrnMoqy-%3DdDUx31Dgru6XTzT3e-T%3DhspY-CDK5tV9k1gQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Bringing some popular must have django tools/packages under django org umbrella

[Asif Saifuddin]

How is the idea? tools like django-debug-toolbar, django-silk, 
django-taggit, django-filter etc and some more de facto tools under the 
umbrella of django github org?

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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2492490d-0bd5-4424-9bae-95471be34664%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: "Project" vs "App"

[Asif Saifuddin]

Without the part of sitecustomize agree with the other parts.

+ there should be distinction between projects app and install apps


Reagards

On Thursday, November 19, 2015 at 3:54:40 PM UTC+6, guettli wrote:
>
> I created a ticket to find a better definition of "Project" vs "App"
>
> https://code.djangoproject.com/ticket/25748
>
> I am happy since Tim Graham accepted it.
>
> Here are the current docs: 
> https://docs.djangoproject.com/en/1.8/ref/applications/#projects-and-applications
>
> Here is my view of Project" vs "App". It would be nice to find a consensus 
> and update the docs.
>
> Project
> ==
> A project is a container for apps.
> It contains only settings, no database models.
> Since it contains no database models it does not contain database schema 
> migrations.
> It can contain migrations which fill a database with project specific data.
> It is common that there is only one production installation of one project.
> It is common to have several stages (dev, test, prod) for one project.
> A project might contain a sitecustomize.py
>
> App
> ===
> An app can have models, views and code.
> It should be re-usable.
> An app can depend on other apps.
> It must not depend on a project.
> An app can contain a settings.py for testing, but it contains no settings 
> on its own.
> It should have instructions which settings are needed to get the app 
> running in a project.
> A app must not contain a sitecustomize.py.
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/eda9c93c-96ff-4c18-a144-3b15c4e17f86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: SQL ALchemy support on django

[Asif Saifuddin]

that's an awsome link :)

thanks russ.

On Thu, Nov 5, 2015 at 12:03 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> Hi Asif,
>
> On Wed, Nov 4, 2015 at 12:17 AM, Asif Saifuddin <auv...@gmail.com> wrote:
>
>> I would like to create an experiemental repo on my github for
>> experiementing the sqla support to django orm, hence some useful resource
>> indicator would be great. sqla have core engine and orm on top of it, so
>> the idea way to start experiment should be based on core?
>>
>
> I gave a broad description of what this would look like in my DjangoCon US
> presentation:
>
>
> https://www.youtube.com/watch?v=VgM0qmpHDiE=PLE7tQUdRKcyaRCK5zIQFW-5XcPZOE-y9t=10
>
> The answer is to write an adaptor for SQLAlchemy so that it can “quack”
> like Django’s Meta model, which will then make it compatible with Django’s
> Admin and Forms.
>
> Yours,
> Russ Magee %-)
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/puVGMV7GlNE/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJxq84_e8EnrxkBUuYLHYP8dHD2J5vcB0Jh35uJDB%2Bjjt4s_GQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAJxq84_e8EnrxkBUuYLHYP8dHD2J5vcB0Jh35uJDB%2Bjjt4s_GQ%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKAqTgrGRGwwnbs2wMonKFS8YgbcXOGO%2B%2BeW55bT-xMvHZvgjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: SQL ALchemy support on django

[Asif Saifuddin]

Hei,

I tried several frameworks, but django is my favorite for many reason. I
have some familarities with django internal code and mechanism.  sqlalchemy
integration with django is a challenging task as dj admin and forms and
some other thinks need to be figure out.

Cheers
Asif

On Thu, Nov 5, 2015 at 6:30 AM, Marcin Nowak <marcin.j.no...@gmail.com>
wrote:

>
>
> On Tuesday, November 3, 2015 at 5:17:32 PM UTC+1, Asif Saifuddin wrote:
>>
>> I would like to create an experiemental repo on my github for
>> experiementing the sqla support to django orm, hence some useful resource
>> indicator would be great. sqla have core engine and orm on top of it, so
>> the idea way to start experiment should be based on core?
>>
>>
> I would like to contribute. But I'm afraid about all things dependent on
> DjangoORM, like migrations,admin,(model) forms and so on.
> I like Django, most of it`s features and simplicity, but not DB layer
> (incl. migrations), html-related forms nor system checks.
>
> There are several ways I think:
>
>- fork of Django (a new project based on good things), with some
>compatibility layer
>- brand new framework based on great Werkzeug and SqlAlchemy, with
>good-things picked from Django
>- switching to Flask (there is SqlAlchemy ext)
>
> The last is the simplest :)
>
> Cheers,
> Marcin
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/puVGMV7GlNE/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/95130c0c-d113-4e7f-9c8d-56459fd796b1%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/95130c0c-d113-4e7f-9c8d-56459fd796b1%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKAqTgpe9Ke0TiGxLXfST4%2BpAOpJDGqdq%3D%3DhDS%2Bhm90L9WuJCQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: SQL ALchemy support on django

[Asif Saifuddin]

I would like to create an experiemental repo on my github for 
experiementing the sqla support to django orm, hence some useful resource 
indicator would be great. sqla have core engine and orm on top of it, so 
the idea way to start experiment should be based on core?

On Wednesday, September 16, 2015 at 2:35:15 PM UTC+6, Asif Saifuddin wrote:
>
> Hi,
>
>
> How much difficult it will be to add SQLalchemy support to django? what 
> are the technical difficulties? And which are the ways to add sqlalchemy 
> support to django?
>
> As SQLalchemy is separated in core and orm will it be wise to use 
> sqlalchemy core as the backend for django orm? Or  through the meta api? 
> any suggestion or direction to the solutions?
>
> The available 3rd party packages seems to be incomplete.
>
>
> Regards
>
> 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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4f9704ed-7d8e-4296-a15e-fa625130b9ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django ORM query syntax enhancement

[Asif Saifuddin]

this is the PR josh

https://github.com/django/django/pull/5443

On Monday, October 19, 2015 at 5:09:14 PM UTC+6, Josh Smeaton wrote:
>
> I think you forgot the PR link Alexey. I'd like to have a look at the 
> changes you've made. I'm not sure about the extensions to F() just yet, I'm 
> hoping they aren't actually needed for your patch to work, but will need to 
> review to be sure.
>
> Cheers
>
> On Monday, 19 October 2015 21:49:37 UTC+11, Alexey Zankevich wrote:
>
> Hi all,
>
> Here is a raw pull request, allowing lookup instances passing to filter 
> method 
> There are two new test cases working:
>
> 1. Passing lookup with F object: 
> Article.objects.filter(GreaterThan(F('id'), Value(5)))
> 2. And passing lookup with transforms: 
> Article.objects.filter(Contains(Upper(Lower(Upper(F('headline', 
> 'ARTICLE 5'))
>
> All the existing tests are passing successfully, by the way (at least for 
> SQLite backend).
>
> Several comments:
>
>- F expressions became real expressions (Expression subclass).
>- Expression got a new method - get_source_f_object, which walks 
>through children classes and find if it has F object passed. In that case 
>output_field-related code should be postponed, until compiler resolves it 
>(which cannot be done during lookup init time).
>- some code related to query.build_filter method (responsible to 
>lookups/transform parsing, and calculating joins), extracted into separate 
>helper classes - QueryKeywordLookupHelper and QueryObjectLookupHelper. 
> They 
>have common code base, but some of methods work in a different way.
>
> Except review, it would be really great if someone help with writing test 
> cases (and I'll get them working in case of any issues). Also, there is a 
> workaround field=None -> isnull=True for oracle database, can anybody check 
> if it is working correctly?
>
> Regards,
> Alexey
>
>
> On Thursday, October 1, 2015 at 11:38:39 AM UTC+3, Anssi Kääriäinen wrote:
>
> Lets concentrate on making expressions in filter calls and lookups as 
> expressions reality. When we have done that we can try out different 
> syntax approaches in 3rd party apps. Finally, after we have field 
> tested the approaches, we can merge something in to Django. 
>
>  - Anssi 
>
> On Thu, Oct 1, 2015 at 10:49 AM, Alexey Zankevich 
>  wrote: 
> >> I think the `F('name').decode('utf-8')` syntax is a good candidate for 
> >> core. 
> > 
> > When Django supports expression lookups, it will be possible to build 
> syntax 
> > sugar third-party library on top of it. 
> > For example, it will be possible to implement dotted syntax for F 
> objects: 
> > 
> > UserModel.objects.filter(Decode(F.user.name, 'utf-8') == u'Бармаглот') 
> > 
> > alternatively it can be even combined with your syntax 
> > 
> > UserModel.objects.filter(F.user.name.decode('utf-8') == u'Бармаглот') 
> > 
> > However, the second solution will be more complicated from technical 
> point 
> > of view (as will require lazy object, collecting all the func or 
> transform 
> > calls), also it will require to be really careful with transform names 
> not 
> > to conflict with possible field names. 
> > For example, it's hardly possible to have "decode" field in the model, 
> but 
> > easily - "date". 
> > 
> > 
> > On Thursday, October 1, 2015 at 10:18:40 AM UTC+3, Loïc Bistuer wrote: 
> >> 
> >> > On Oct 1, 2015, at 13:38, Anssi Kääriäinen  
> wrote: 
> >> > 
> >> > +1 to not requiring all transforms to handle __underscore__ syntax. 
> >> 
> >> +1 
> >> 
> >> > I think what we want to do is allow users choose which syntax they 
> >> > prefer. The idea is that Django will support both JSONExtract('data', 
> >> > path=['owner', 'other_pets', 0, 'name']) and 
> >> > data__owner__other_pets__0__name out of the box. 
> >> > 
> >> > We will also make it possible to support callable transforms. For 
> >> > example: 
> >> >filter(Exact(Decode(F('name'), 'utf-8'), Value(u'Бармаглот'))) 
> >> > is equivalent to 
> >> >filter(F('name').decode('utf-8') == Value(u'Бармаглот')) 
> >> > 
> >> > The callable transforms syntax will not be a part of Django, but it 
> >> > will be possible to create an extension for this (it is actually 
> >> > surprisingly easy to do once we have support for expressions in 
> >> > filter). 
> >> 
> >> I'm pretty convinced we need a better API / sugar as part of core in 
> the 
> >> long run. 
> >> 
> >> The `filter(Exact(Decode(F('name'), 'utf-8'), Value(u'Бармаглот')))` 
> >> syntax is not pythonic and very hard to decipher, and we've reached the 
> >> limits of our historical double underscore syntax (doesn't support 
> multiple 
> >> arguments, limited to ascii, etc.). 
> >> 
> >> I think the `F('name').decode('utf-8')` syntax is a good candidate for 
> >> core: 
> >> 
> >> - It's a small extension to the existing F objects, so it's easy to 
> grasp 
> >> for existing Django users. 
> >> - It's just a thin sugar on 

Re: SQL ALchemy support on django

[Asif Saifuddin]

Hi,

With "support" I meant having a official djangoish way to use sqlalchemy on
django. As I have to use model meta API to add support for any non django
backend to orm my question is, is django meta API fully formalized? If not
how much work is needed to formalize them?(as denial did a lots of work
then their should be proper guideline or enough insight to start digging? )

Or we are ok with the existing API's?

Regards

Asif

On Thu, Sep 17, 2015 at 5:20 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> Hi Asif,
>
> It depends entirely what you mean by "support".
>
> Django is just Python, so there's absolutely no reason you can't write
> a Django site that uses Django for the URLs, views and forms, but
> SQLAlchemy for the data access.
>
> Out of the box, you won't be able to use ModelForms or the Admin.
> However, with the new stable Meta API that was added in 1.8, you
> should be able to write a layer for SQLAlchemy that makes a SQLAlchemy
> table definition "quack" like a Django model, allowing you to wrap.
>
> Daniel Parathion did this as a proof of concept as part of his GSoC
> project using the Gmail API - he was able to expose a Gmail inbox as a
> Django model, browse his inbox in Admin, and use a ModelForm to
> compose an email from within the admin.
>
> I gave a presentation at the recent DjangoCon US about this topic; the
> slides are available here:
>
> https://speakerdeck.com/freakboy3742/i-never-meta-model-i-didnt-like
>
> Video should be available in the next week or so. Short version: it
> won't be *trivial*, but it's certainly *possible*, although you're in
> undocumented territory, so you'll have to navigate the sharp edges
> yourself.
>
> Yours,
> Russ Magee %-)
>
>
>
>
> On Wed, Sep 16, 2015 at 4:35 PM, Asif Saifuddin <auv...@gmail.com> wrote:
> > Hi,
> >
> >
> > How much difficult it will be to add SQLalchemy support to django? what
> are
> > the technical difficulties? And which are the ways to add sqlalchemy
> support
> > to django?
> >
> > As SQLalchemy is separated in core and orm will it be wise to use
> sqlalchemy
> > core as the backend for django orm? Or  through the meta api? any
> suggestion
> > or direction to the solutions?
> >
> > The available 3rd party packages seems to be incomplete.
> >
> >
> > Regards
> >
> > 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 post to this group, send email to django-developers@googlegroups.com.
> > Visit this group at http://groups.google.com/group/django-developers.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/django-developers/33078771-6802-44f9-9182-1eb2f7104e23%40googlegroups.com
> .
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/puVGMV7GlNE/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJxq849Ccd%2Bvz9uYf45UtcjnMXToRChoO-MyTz5b3YLFFEp6Ww%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKAqTgrgsSz6OEWQXt5LzLVOCybsLyV1yZJV%3DrPBbVHu6D9xKA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

SQL ALchemy support on django

[Asif Saifuddin]

Hi,


How much difficult it will be to add SQLalchemy support to django? what are 
the technical difficulties? And which are the ways to add sqlalchemy 
support to django?

As SQLalchemy is separated in core and orm will it be wise to use 
sqlalchemy core as the backend for django orm? Or  through the meta api? 
any suggestion or direction to the solutions?

The available 3rd party packages seems to be incomplete.


Regards

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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/33078771-6802-44f9-9182-1eb2f7104e23%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Major features for 1.9

[Asif Saifuddin]

Probably templete based wizard rendering and tasks in 1.9 would be great!

On Friday, July 17, 2015 at 11:19:38 PM UTC+6, Tim Graham wrote:
>
> Currently we have two items on the roadmap: 
> https://code.djangoproject.com/wiki/Version1.9Roadmap
>
> PostgreSQL Full Text Search  
> (Marc Tamlyn)
> Custom indexes  (Marc Tamlyn)
>
> Hopefully we can add Marten's URLs GSoC project to this list.
>
> I removed composite fields as Thomas indicated he doesn't plan to continue 
> work on it. 
>
> We have about two months until the alpha feature freeze (planned for 
> September 21). If anyone is planning any ambitious patches, let us know!
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/92e60a1e-c17e-428a-bc71-7ec6964a579c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any chances to see Django benefit from new Async features of Python 3.5 ?

[Asif Saifuddin]

This might interest you:

 https://gist.github.com/andrewgodwin/b3f826a879eb84a70625 


On Saturday, June 20, 2015 at 4:48:59 PM UTC+6, Benj wrote:
>
> Hi,
> are there any chances for a future Django version to benefit from new 
> built in Python async features ( https://www.python.org/dev/peps/pep-0492/ 
> ) ?
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/50e3d499-a1df-424a-b014-13d0014a102e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Asif Saifuddin]

+1 dude!! go for it!

On Mon, Jun 8, 2015 at 7:25 PM, Tim Graham <timogra...@gmail.com> wrote:

> Any other feedback on the proposal? I could assume no complaints is a good
> sign, but some +1's would be easier to interpret. :-)
>
>
> On Monday, June 1, 2015 at 11:09:12 AM UTC-4, Collin Anderson wrote:
>>
>> I see. I missed the "first upgrade Django to the last release before the
>> next
>> LTS (e.g. upgrade 1.8->1.9->2.0), then upgrade your dependencies to the
>> newer version that supports both 2.0 and 2.1, and then finally upgrade
>> to 2.1." part.
>>
>> Thanks,
>> Collin
>>
>> On Monday, June 1, 2015 at 11:02:01 AM UTC-4, Tim Graham wrote:
>>>
>>> If we dropped 1.8 deprecated features in 2.0, then it would require
>>> libraries to add conditional code to support both the old and new ways of
>>> doing something. The idea is that a third-party app wouldn't need to make
>>> any updates (except those needed to accommodate for backwards incompatible
>>> changes) until the next LTS release.
>>>
>>> The idea is *not* to suggest apps should try to support two LTS
>>> releases. Making that easy on Django's end would require keeping deprecated
>>> features in Django significantly longer than this proposal. See Carl's post
>>> in the thread where we discussed the deprecation cycle changes:
>>> https://groups.google.com/d/msg/django-developers/qCjfOu-FPxQ/hccAcVChHMkJ
>>>
>>> On Monday, June 1, 2015 at 10:20:13 AM UTC-4, Collin Anderson wrote:
>>>>
>>>> 1.8 - April 2015 (LTS): Dropped features deprecated in 1.6 [1.6 no
>>>> longer supported].
>>>> 1.9 - Dec. 2015: Drop features deprecated in 1.7 [1.7 no longer
>>>> supported].
>>>> 2.0 - Aug. 2016: No features dropped.
>>>> 2.1 - April 2017 (LTS): Drop features deprecated in 1.8, 1.9 [1.9 no
>>>> longer supported, third party apps can update to support 2.0 as a minimum
>>>> version; 1.8 users should use an old version of the third-party app for the
>>>> ~1 year until 1.8 is unsupported].
>>>> 2.2 - Dec. 2017: Drop features deprecated in 2.0 [2.0 no longer
>>>> supported].
>>>>
>>>> This is awesome.
>>>>
>>>> So why not to have 2.0 drop features features deprecated in 1.8? If the
>>>> replacement pattern/feature is available in 1.8, the 3rd party app should
>>>> be able to use the new feature to stay compatible, right? If anything I'd
>>>> like to see us hold off on dropping features deprecated in 1.9 until after
>>>> the LTS to help people migrate between LTSs.
>>>>
>>>> Thanks,
>>>> Collin
>>>>
>>>>
>>>> On Monday, June 1, 2015 at 9:20:07 AM UTC-4, Tim Graham wrote:
>>>>>
>>>>> I put together a draft proposal in the form of a potential
>>>>> djangoproject.com blog post. I've enabled commenting in case you have
>>>>> minor cosmetic comments, but please keep discussion about the content of
>>>>> the proposal itself on this mailing list. Also, please let me know of any
>>>>> additional questions or complaints that you'd like to see addressed in the
>>>>> last section.
>>>>>
>>>>> The overview is:
>>>>> * New major release every 8 months
>>>>> * New long-term support release every 2 years. LTS releases continue
>>>>> to be supported with security updates for 3 years.
>>>>> * Adjust the deprecation policy to make it easier for third-party apps
>>>>> to support all versions back to the last LTS.
>>>>>
>>>>>
>>>>> https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing
>>>>>
>>>>> On Tuesday, April 7, 2015 at 3:20:55 PM UTC-4, Collin Anderson wrote:
>>>>>>
>>>>>> On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote:
>>>>>>>
>>>>>>> How about
>>>>>>>
>>>>>>> a 8 month release cycle and having a LTS in every two years and
>>>>>>> supporting the old LTS atleast 3 years from the release date? there 
>>>>>>> will be
>>>>>>> 3 version between two LTS.
>>>>>>>
>>>>>>
>>>>>> Interesting. I like the idea of having predictable release dates.
>>>>>>
>>&g

Re: 1.9 release planning

[Asif Saifuddin]

thats great!!!

On Mon, Jun 1, 2015 at 7:20 PM, Tim Graham <timogra...@gmail.com> wrote:

> I put together a draft proposal in the form of a potential
> djangoproject.com blog post. I've enabled commenting in case you have
> minor cosmetic comments, but please keep discussion about the content of
> the proposal itself on this mailing list. Also, please let me know of any
> additional questions or complaints that you'd like to see addressed in the
> last section.
>
> The overview is:
> * New major release every 8 months
> * New long-term support release every 2 years. LTS releases continue to be
> supported with security updates for 3 years.
> * Adjust the deprecation policy to make it easier for third-party apps to
> support all versions back to the last LTS.
>
>
> https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing
>
> On Tuesday, April 7, 2015 at 3:20:55 PM UTC-4, Collin Anderson wrote:
>>
>> On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote:
>>>
>>> How about
>>>
>>> a 8 month release cycle and having a LTS in every two years and
>>> supporting the old LTS atleast 3 years from the release date? there will be
>>> 3 version between two LTS.
>>>
>>
>> Interesting. I like the idea of having predictable release dates.
>>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/MTvOPDNQXLI/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/5e38433f-f499-483c-88aa-0d2744fad9cb%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/5e38433f-f499-483c-88aa-0d2744fad9cb%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKAqTgqNARxgzJ48W_tcY5Frk0Z01TzXJEjg6W3QtnCuAHkj4g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Asif Saifuddin]

How about

a 8 month release cycle and having a LTS in every two years and supporting 
the old LTS atleast 3 years from the release date? there will be 3 version 
between two LTS.

On Thursday, March 12, 2015 at 6:13:11 AM UTC+6, Tim Graham wrote:
>
> With the release of 1.8 coming up, it's time to think about 1.9! I've 
> suggested some dates below. The schedule is similar to the intervals we 
> used for 1.8 with the final release date planned for about 6 months after 
> 1.8 final (barring unforeseen delays, 1.8 will be released about 7 months 
> after 1.7). Please voice any thoughts or concerns. With this schedule it 
> seems that any GSoC work would likely be included in 2.0. If you have any 
> big features planned, please add them here: 
> https://code.djangoproject.com/wiki/Version1.9Roadmap
>
> July 20 - Alpha (feature freeze)
> August 21 - Beta (only release blockers fixed after this)
> September 18 - RC (string freeze for translations)
> October 2 - Final
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/eb57f50b-a07d-4e0f-80a6-7fb845d193d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2015 project ideas suggestion

[Asif Saifuddin]

Hi,

I have been updating my proposal and as the deadline is friday Your 
feedback will help me to make it better in technical point of view

https://gist.github.com/auvipy/1da0d96f826bd8da4d47

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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5a2c7674-a101-4554-a725-17b4747068d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2015 project ideas suggestion

[Asif Saifuddin]

I have updated the proposal with what I'm planning to acheive in the 
program and updating  with my analysis and plans to acheive the goal. still 
in draft and am editing according the goal I wanted to acheive/implement in 
this project proposal.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f6acceaf-482b-4521-b4f5-7071b75dd6db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2015 project ideas suggestion

[Asif Saifuddin]

Have a look. though rough draft and many place for improvment

https://gist.github.com/auvipy/1da0d96f826bd8da4d47

On Mon, Mar 23, 2015 at 4:43 AM, Tim Graham <timogra...@gmail.com> wrote:

> Please explain what you plan to implement in the other apps rather than
> what's already been implemented in contrib.auth. You'll also need to
> explain your reasoning for addressing a ticket that's been marked as "won't
> fix."
>
> On Sunday, March 22, 2015 at 4:36:26 PM UTC-4, Asif Saifuddin wrote:
>>
>> I do belive to implement auth patch cleanly wont take more then a few
>> days. But I have plans with django admin app and others which will need
>> more tasks and also thinking about working with formset . The part I posted
>> here is just a very little/start point of my proposal :)
>>
>> And I am working on a draft gist for full proposal. This part was posted
>> to have an Idea if I'm going to right direction. I found admin-docs up to
>> date with class based views and using that as a good reference to
>> understand the implementation and also getting ideas about the problems
>> people faced earlier and theie thoughts about the possible solutions :)
>>
>> I'm I in right direction? at least in some context? knowing that will
>> help me a lot
>>
>> ./auvipy
>>
>>
>>
>> On Mon, Mar 23, 2015 at 1:14 AM, Tim Graham <timog...@gmail.com> wrote:
>>
>>> I see there's already a patch attached to the ticket that implements
>>> your proposal. While it likely needs to be updated to apply cleanly, I
>>> don't imagine that will take more than a few days?
>>>
>>>
>>> On Sunday, March 22, 2015 at 2:19:37 PM UTC-4, Asif Saifuddin wrote:
>>>>
>>>> Hi All,
>>>>
>>>> during my analyzing and making proposal for django best practices
>>>> updates (class based view etc)  I found this ticket related
>>>> https://code.djangoproject.com/ticket/16256 [though closed by a core
>>>> dev I think this should be addressed to resolve some issues in admin as per
>>>>  https://code.djangoproject.com/ticket/17209]
>>>>
>>>>
>>>> Here goes some of my initial proposal plan I will be updating regularly
>>>> to complete the proposal in a gist and share that again. before that please
>>>> give some feedback :)
>>>>
>>>> Background
>>>>
>>>> Over the years, as Django has evolved, the idea of what constitutes
>>>> "best practice" has also evolved. However, some parts of Django haven't
>>>> kept up with those best practices. For example, contrib apps do not use
>>>> class based views.
>>>>
>>>> In short, Django has been bad at eating it's own dogfood. The contents
>>>> of contrib should be audited and updated to make sure it meets current best
>>>> practices.
>>>>
>>>> For updating best practices first think to consider is to convert the
>>>> functional views of django contrib apps to class based views where possible
>>>> and necessary. To do so first app to consider is django contrib auth.
>>>>
>>>> contrib-auth views.py now have function based views and they are
>>>>
>>>> login logout logout_then_login redirect_to_login password_reset
>>>> password_reset_done password_reset_confirm password_reset_complete
>>>> password_change password_change_done
>>>>
>>>> and in urls.py url mapping for function based views as follows
>>>>
>>>> urlpatterns = [ url(r'^login/$', views.login, name='login'),
>>>> url(r'^logout/$', views.logout, name='logout'), url(r'^password_change/$',
>>>> views.password_change, name='password_change'),
>>>> url(r'^password_change/done/$', views.password_change_done,
>>>> name='password_change_done'), url(r'^password_reset/$',
>>>> views.password_reset, name='password_reset'),
>>>> url(r'^password_reset/done/$', views.password_reset_done,
>>>> name='password_reset_done'), url(r'^reset/(?P[0-9A-Za-z_-]+
>>>> )/(?P[0-9A-Za-z]{1,13}-[0-9A-Za-z]{1,20})/$',
>>>> views.password_reset_confirm, name='password_reset_confirm'),
>>>> url(r'^reset/done/$', views.password_reset_complete,
>>>> name='password_reset_complete'), ]
>>>>
>>>> and tests for this in tests/auth_tests/test_views.py
>>>>
>>>> the views have to be converted into CBV and also the urls. and this
>>>> should be

Re: GSOC 2015 project ideas suggestion

[Asif Saifuddin]

For the wont fix ticket I'm considering that to introduce django extra view 
like features in django will help fix many problem related to FormSet and 
ModelFormSet and then use them in improving django admin and possibly 
django-admin2 like features in django.

On Monday, March 23, 2015 at 4:43:30 AM UTC+6, Tim Graham wrote:
>
> Please explain what you plan to implement in the other apps rather than 
> what's already been implemented in contrib.auth. You'll also need to 
> explain your reasoning for addressing a ticket that's been marked as "won't 
> fix."
>
> On Sunday, March 22, 2015 at 4:36:26 PM UTC-4, Asif Saifuddin wrote:
>>
>> I do belive to implement auth patch cleanly wont take more then a few 
>> days. But I have plans with django admin app and others which will need 
>> more tasks and also thinking about working with formset . The part I posted 
>> here is just a very little/start point of my proposal :)
>>
>> And I am working on a draft gist for full proposal. This part was posted 
>> to have an Idea if I'm going to right direction. I found admin-docs up to 
>> date with class based views and using that as a good reference to 
>> understand the implementation and also getting ideas about the problems 
>> people faced earlier and theie thoughts about the possible solutions :)
>>
>> I'm I in right direction? at least in some context? knowing that will 
>> help me a lot
>>
>> ./auvipy
>>
>>
>>
>> On Mon, Mar 23, 2015 at 1:14 AM, Tim Graham <timog...@gmail.com> wrote:
>>
>>> I see there's already a patch attached to the ticket that implements 
>>> your proposal. While it likely needs to be updated to apply cleanly, I 
>>> don't imagine that will take more than a few days?
>>>
>>>
>>> On Sunday, March 22, 2015 at 2:19:37 PM UTC-4, Asif Saifuddin wrote:
>>>>
>>>> Hi All,
>>>>
>>>> during my analyzing and making proposal for django best practices 
>>>> updates (class based view etc)  I found this ticket related 
>>>> https://code.djangoproject.com/ticket/16256 [though closed by a core 
>>>> dev I think this should be addressed to resolve some issues in admin as 
>>>> per 
>>>>  https://code.djangoproject.com/ticket/17209]
>>>>
>>>>
>>>> Here goes some of my initial proposal plan I will be updating regularly 
>>>> to complete the proposal in a gist and share that again. before that 
>>>> please 
>>>> give some feedback :)
>>>>
>>>> Background
>>>>
>>>> Over the years, as Django has evolved, the idea of what constitutes 
>>>> "best practice" has also evolved. However, some parts of Django haven't 
>>>> kept up with those best practices. For example, contrib apps do not use 
>>>> class based views.
>>>>
>>>> In short, Django has been bad at eating it's own dogfood. The contents 
>>>> of contrib should be audited and updated to make sure it meets current 
>>>> best 
>>>> practices.
>>>>
>>>> For updating best practices first think to consider is to convert the 
>>>> functional views of django contrib apps to class based views where 
>>>> possible 
>>>> and necessary. To do so first app to consider is django contrib auth.
>>>>
>>>> contrib-auth views.py now have function based views and they are
>>>>
>>>> login logout logout_then_login redirect_to_login password_reset 
>>>> password_reset_done password_reset_confirm password_reset_complete 
>>>> password_change password_change_done
>>>>
>>>> and in urls.py url mapping for function based views as follows
>>>>
>>>> urlpatterns = [ url(r'^login/$', views.login, name='login'), 
>>>> url(r'^logout/$', views.logout, name='logout'), url(r'^password_change/$', 
>>>> views.password_change, name='password_change'), 
>>>> url(r'^password_change/done/$', views.password_change_done, 
>>>> name='password_change_done'), url(r'^password_reset/$', 
>>>> views.password_reset, name='password_reset'), 
>>>> url(r'^password_reset/done/$', views.password_reset_done, 
>>>> name='password_reset_done'), url(r'^reset/(?P[0-9A-Za-z_-]+
>>>> )/(?P[0-9A-Za-z]{1,13}-[0-9A-Za-z]{1,20})/$', 
>>>> views.password_reset_confirm, name='password_reset_confirm'), 
>>>> url(r'^reset/done/$', views.password_reset_complete, 
>>>> name='passwo

Re: GSOC 2015 project ideas suggestion

[Asif Saifuddin]

I do belive to implement auth patch cleanly wont take more then a few days.
But I have plans with django admin app and others which will need more
tasks and also thinking about working with formset . The part I posted here
is just a very little/start point of my proposal :)

And I am working on a draft gist for full proposal. This part was posted to
have an Idea if I'm going to right direction. I found admin-docs up to date
with class based views and using that as a good reference to understand the
implementation and also getting ideas about the problems people faced
earlier and theie thoughts about the possible solutions :)

I'm I in right direction? at least in some context? knowing that will help
me a lot

./auvipy



On Mon, Mar 23, 2015 at 1:14 AM, Tim Graham <timogra...@gmail.com> wrote:

> I see there's already a patch attached to the ticket that implements your
> proposal. While it likely needs to be updated to apply cleanly, I don't
> imagine that will take more than a few days?
>
>
> On Sunday, March 22, 2015 at 2:19:37 PM UTC-4, Asif Saifuddin wrote:
>>
>> Hi All,
>>
>> during my analyzing and making proposal for django best practices updates
>> (class based view etc)  I found this ticket related https://code.
>> djangoproject.com/ticket/16256 [though closed by a core dev I think this
>> should be addressed to resolve some issues in admin as per
>> https://code.djangoproject.com/ticket/17209]
>>
>>
>> Here goes some of my initial proposal plan I will be updating regularly
>> to complete the proposal in a gist and share that again. before that please
>> give some feedback :)
>>
>> Background
>>
>> Over the years, as Django has evolved, the idea of what constitutes "best
>> practice" has also evolved. However, some parts of Django haven't kept up
>> with those best practices. For example, contrib apps do not use class based
>> views.
>>
>> In short, Django has been bad at eating it's own dogfood. The contents of
>> contrib should be audited and updated to make sure it meets current best
>> practices.
>>
>> For updating best practices first think to consider is to convert the
>> functional views of django contrib apps to class based views where possible
>> and necessary. To do so first app to consider is django contrib auth.
>>
>> contrib-auth views.py now have function based views and they are
>>
>> login logout logout_then_login redirect_to_login password_reset
>> password_reset_done password_reset_confirm password_reset_complete
>> password_change password_change_done
>>
>> and in urls.py url mapping for function based views as follows
>>
>> urlpatterns = [ url(r'^login/$', views.login, name='login'),
>> url(r'^logout/$', views.logout, name='logout'), url(r'^password_change/$',
>> views.password_change, name='password_change'),
>> url(r'^password_change/done/$', views.password_change_done,
>> name='password_change_done'), url(r'^password_reset/$',
>> views.password_reset, name='password_reset'),
>> url(r'^password_reset/done/$', views.password_reset_done,
>> name='password_reset_done'), url(r'^reset/(?P[0-9A-Za-z_-]+
>> )/(?P[0-9A-Za-z]{1,13}-[0-9A-Za-z]{1,20})/$',
>> views.password_reset_confirm, name='password_reset_confirm'),
>> url(r'^reset/done/$', views.password_reset_complete,
>> name='password_reset_complete'), ]
>>
>> and tests for this in tests/auth_tests/test_views.py
>>
>> the views have to be converted into CBV and also the urls. and this
>> should be done in a backward compatible manner.
>>
>> as an example password_change_done view is now implemented as below.
>>
>> @login_required def password_change_done(request,
>> template_name='registration/password_change_done.html',
>> current_app=None, extra_context=None): context = { 'title': _('Password
>> change successful'), } if extra_context is not None:
>> context.update(extra_context)
>>
>> if current_app is not None:
>> request.current_app = current_app
>>
>> return TemplateResponse(request, template_name, context)
>>
>> this could be changed to cbv like below
>>
>> class PasswordChangeDoneView(TemplateView): 
>> template_name='registration/password_change_done.html'
>> current_app=None extra_context=None
>>
>> @method_decorator(login_required)
>> def dispatch(self, request, *args, **kwargs):
>> return super(Password_Change_Done, self).dispatch(request, *args, 
>> **kwargs)
>>
>> def get_context_data(self, **kwargs):
>> context = super(Password_Change_Done, self).get_context_data(**kw

Re: GSOC 2015 project ideas suggestion

[Asif Saifuddin]

Hi All,

during my analyzing and making proposal for django best practices updates 
(class based view etc)  I found this ticket 
related https://code.djangoproject.com/ticket/16256 [though closed by a 
core dev I think this should be addressed to resolve some issues in admin 
as per  https://code.djangoproject.com/ticket/17209]


Here goes some of my initial proposal plan I will be updating regularly to 
complete the proposal in a gist and share that again. before that please 
give some feedback :)

Background

Over the years, as Django has evolved, the idea of what constitutes "best 
practice" has also evolved. However, some parts of Django haven't kept up 
with those best practices. For example, contrib apps do not use class based 
views.

In short, Django has been bad at eating it's own dogfood. The contents of 
contrib should be audited and updated to make sure it meets current best 
practices.

For updating best practices first think to consider is to convert the 
functional views of django contrib apps to class based views where possible 
and necessary. To do so first app to consider is django contrib auth.

contrib-auth views.py now have function based views and they are

login logout logout_then_login redirect_to_login password_reset 
password_reset_done password_reset_confirm password_reset_complete 
password_change password_change_done

and in urls.py url mapping for function based views as follows

urlpatterns = [ url(r'^login/$', views.login, name='login'), 
url(r'^logout/$', views.logout, name='logout'), url(r'^password_change/$', 
views.password_change, name='password_change'), 
url(r'^password_change/done/$', views.password_change_done, 
name='password_change_done'), url(r'^password_reset/$', 
views.password_reset, name='password_reset'), 
url(r'^password_reset/done/$', views.password_reset_done, 
name='password_reset_done'), 
url(r'^reset/(?P[0-9A-Za-z_-]+)/(?P[0-9A-Za-z]{1,13}-[0-9A-Za-z]{1,20})/$', 
views.password_reset_confirm, name='password_reset_confirm'), 
url(r'^reset/done/$', views.password_reset_complete, 
name='password_reset_complete'), ]

and tests for this in tests/auth_tests/test_views.py

the views have to be converted into CBV and also the urls. and this should 
be done in a backward compatible manner.

as an example password_change_done view is now implemented as below.

@login_required def password_change_done(request, 
template_name='registration/password_change_done.html', current_app=None, 
extra_context=None): context = { 'title': _('Password change successful'), 
} if extra_context is not None: context.update(extra_context)

if current_app is not None:
request.current_app = current_app

return TemplateResponse(request, template_name, context)

this could be changed to cbv like below

class PasswordChangeDoneView(TemplateView): 
template_name='registration/password_change_done.html' current_app=None 
extra_context=None

@method_decorator(login_required)
def dispatch(self, request, *args, **kwargs):
return super(Password_Change_Done, self).dispatch(request, *args, **kwargs)

def get_context_data(self, **kwargs):
context = super(Password_Change_Done, self).get_context_data(**kwargs)
context.update({
 'title': _('Password change successful'),
 'current_app': self.current_app,
})
if self.extra_context is not None:
context.update(self.extra_context)
return context

for
 
backward compatibility the following way can be followed

def password_change_done(request, *args, **kwargs):

  return PasswordChangeDoneView.as_view(**kwargs)(request, *args, 
**kwargs)

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/248fbc76-0804-4128-998a-bb4f17f2c98c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: queryset caching note in docs

[Asif Saifuddin]

assigned myself to the ticket https://code.djangoproject.com/ticket/16614

will try to give akarai's patch a try


-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2295fb5a-c8ac-4d1f-93e7-5a3c6415a831%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSoC] Switching to Jinja2 proposal

[Asif Saifuddin]

Hi, chris,

So as django have the jinja 2 support out of the box what do you think the 
direction of the ticket? https://code.djangoproject.com/ticket/15667

should the form rendering based on jinja2? or whats on our mind? If you 
guide me with some direction then I might go for the ticket. looking 
forward to hear from you.

Regards

On Sunday, March 23, 2014 at 5:24:05 PM UTC+6, Christopher Medrela wrote:
>
> On Sunday, March 23, 2014 11:51:06 AM UTC+1, Gwildor Sok wrote:
>>
>> So, there won't be a GSoC project for this, but it would be a shame to 
>> let the lengthy discussion and momentum generated go to waste. Can a 
>> decision on this matter be made and implemented regardless of the GSoC 
>> projects?
>>
>
> I think that the initial decisions were made already -- we agreed on
> out-of-the-box support for Jinja2 and rewriting some templates into Jinja2.
>
> You are asking for implementing a big feature but who should do it? 
> Everybody
> is a volunteer here, contributors are scare resource. As I said, I won't 
> have
> enough time in the next six months to work at this feature. Maybe somebody
> will tempt to implement that for money? This feature seems to be a good
> kickstarter project -- it's an isolated issue with a clear objective.
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c56a438a-378e-4e01-ae87-89b1683c4fb4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Composite fields

[Asif Saifuddin]

but? IRC discussion?

On Tuesday, March 17, 2015 at 9:09:49 PM UTC+6, Thomas Stephenson wrote:
>
> Not impatient or anything, but...
>
> Bump.
>
> On 13 March 2015 at 14:07, Thomas Stephenson  > wrote:
>
>> All the null handling stuff has been removed from the specification and 
>> replaced with slightly more stringent restrictions on `value_to_dict`. 
>> There is an updated version which includes that change, plus a couple more 
>> alterations that were discussed here and on the PR available here. 
>> 
>>
>> Thomas
>>
>> On 9 March 2015 at 17:43, Anssi Kääriäinen > > wrote:
>>
>>> On Mon, Mar 9, 2015 at 8:06 AM, Thomas Stephenson >> > wrote:
>>> >> It doesn't result in good table design and adds 
>>> restrictions/complication
>>> >> to the ORM/migrations.
>>> >
>>> > Well, honestly, making all subfields always nullable (whether it is or 
>>> not)
>>> > in order to support the composite field being potentially nullable 
>>> doesn't
>>> > really result in good table design either.
>>> >
>>> >> Enforcing that both x and y have a value should be handled with a
>>> >> constraint and/or validators.
>>> >
>>> > There is _no_ problem that is better handled with validators than an
>>> > equivalent database constraint unless you assume that the framework is 
>>> the
>>> > only client your database will ever have.
>>>
>>> You'll likely need both. The database constraint is there to catch all
>>> errors, whether generated by the framework or some other client. The
>>> validator will supply nice user-facing error messages. This is how
>>> unique constraints work for example: there is a model validator that
>>> says "this value already exists in the database", but we also have
>>> database level constraint to make sure there is no way to store
>>> invalid values.
>>>
>>> >> -1 on silently changing the field definition. At best this would 
>>> result in
>>> >> an unnecessary migration when the error is discovered. Django should 
>>> error
>>> >> out with a message that the composite field definition is invalid.
>>> >
>>> > Changing the subfield definitions in the composite field constructor 
>>> has to
>>> > be supported, there's no way of passing parameters to subfields if you
>>> > don't. What mistake is there to be found? Either you want the composite
>>> > field to be nullable or you don't. You're being explicit about it by 
>>> passing
>>> > `null=True` into the field definition and it's a standard field 
>>> parameter.
>>>
>>> If the user supplies the fields, then we don't want to change them
>>> silently. We could have checks framework error for incompatible
>>> settings however. If the field auto-creates the subfields, then it can
>>> alter them in any way it wishes.
>>>
>>> Making the composite field null only when all of its subfields are
>>> null seems the right behavior to me. Otherwise you'd have strange
>>> cases where .filter(money__amount=10) is true, but
>>> .filter(money__isnull=True) is also true for the same row.
>>>
>>>  - Anssi
>>>
>>> --
>>> 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 post to this group, send email to django-d...@googlegroups.com 
>>> .
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/CALMtK1GCSfemy%2BN0HLPMbsovwgcSy%2BwEw6QF-%2BoZ-tfBCTSkUw%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0f8b0979-7e15-45d2-ab76-88dc747a0bf7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

About Class Based views

[Asif Saifuddin]

Hi,

I found this blog post about class based views of django

http://lukeplant.me.uk/blog/posts/my-approach-to-class-based-views/


what do you guys think about?

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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e84fd370-044e-456e-b2f3-fd028f41232e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

GSoC 2015: Django Best Practices Update

[Asif Saifuddin]

Hi,

Having a new thread for my gsoc project idea 2015. Analyzing for more then 
a month I have decided to work on django best practices updates project. 
Tim graham and Russels suggestions helped me to have some ideas related to 
this project. In this thread I hope to have a in depth discussion for the 
proposal. 

*Background:*

Over the years, as Django has evolved, the idea of what constitutes "best 
practice" has also evolved. However, some parts of Django haven't kept up 
with those best practices. For example, contrib apps do not use class based 
views.

In short, Django has been bad at eating it's own dogfood. The contents of 
contrib should be audited and updated to make sure it meets current best 
practices.


*Objectives:*

* Anallyzing django contrib apps to figure out which needs overhaul

* Introducing Class Based views and class based generic views in the 
contrib apps where necessary

* Drawing update path with backward compatibility in mind


*Apps Need to be reviewd:*

*admin, auth, content-type, flatpages, gis, sitemaps, sites, staticfiles, 
syndication*


- - - - - - - - - - - - - - - - - - - -

this is incomplete draft 



I found the following tickets helpful. Any other related old tickets?

https://code.djangoproject.com/ticket/17209,  
https://code.djangoproject.com/ticket/17208, 
https://code.djangoproject.com/ticket/16256

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d0e3e2ac-f3a3-4b72-aada-a3e3c76cb400%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2015 project ideas suggestion

[Asif Saifuddin]

Thanks a lot tim! that will be really helpful!

On Wed, Mar 11, 2015 at 6:42 AM, Tim Graham <timogra...@gmail.com> wrote:

> It's up to you to convince the value in your ideas. The more specific you
> can be, the easier we'll be able to give feedback. Here's a related ticket
> about using class-based views in contrib.auth which may be helpful:
> https://code.djangoproject.com/ticket/17209
>
> On Monday, March 9, 2015 at 2:05:39 PM UTC-4, Asif Saifuddin wrote:
>>
>> About the best practice project idea I'm analyzing contrib apps. I found
>> Admin docs app using class based views and probably it's almost up to date.
>> for admin and some other apps there are no class based views used. for
>> revamping django admin as a part of best practice update hoow about
>> extending django admin with the ideas from 3rd party apps llike djang admin
>> 2? or others. just for querying
>>
>> Regards
>>
>> On Fri, Mar 6, 2015 at 2:26 AM, Tim Graham <timog...@gmail.com> wrote:
>>
>>> I have seen that error on my own system Ubuntu 14.04 & Python 3.4.2
>>> (installed from source), but didn't investigate the cause. I just installed
>>> Python 3.4.3, however, and don't have the problem there. Now I've
>>> reinstalled 3.4.2 and the error is resolved there as well.
>>>
>>>
>>> On Thursday, March 5, 2015 at 2:29:36 PM UTC-5, Asif Saifuddin wrote:
>>>>
>>>> Hi,
>>>>
>>>> running django test suite under python 3.4.3 on my ubuntu 14.10 produce
>>>> the below output
>>>>
>>>> ERROR: test_extract_function (utils_tests.test_archive.TestBzip2Tar)
>>>> --
>>>> Traceback (most recent call last):
>>>>   File "/home/asif/foss/django/tests/utils_tests/test_archive.py",
>>>> line 42, in test_extract_function
>>>> extract(self.archive_path, self.tmpdir)
>>>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-package
>>>> s/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
>>>> line 49, in extract
>>>> with Archive(path) as archive:
>>>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-package
>>>> s/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
>>>> line 58, in __init__
>>>> self._archive = self._archive_cls(file)(file)
>>>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-package
>>>> s/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
>>>> line 138, in __init__
>>>> self._archive = tarfile.open(file)
>>>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/tarfile.py",
>>>> line 1553, in open
>>>> raise ReadError("file could not be opened successfully")
>>>> tarfile.ReadError: file could not be opened successfully
>>>>
>>>> ==
>>>> ERROR: test_extract_function_no_to_path (utils_tests.test_archive.Test
>>>> Bzip2Tar)
>>>> --
>>>> Traceback (most recent call last):
>>>>   File "/home/asif/foss/django/tests/utils_tests/test_archive.py",
>>>> line 51, in test_extract_function_no_to_path
>>>> extract(self.archive_path)
>>>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-package
>>>> s/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
>>>> line 49, in extract
>>>> with Archive(path) as archive:
>>>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-package
>>>> s/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
>>>> line 58, in __init__
>>>> self._archive = self._archive_cls(file)(file)
>>>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-package
>>>> s/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
>>>> line 138, in __init__
>>>> self._archive = tarfile.open(file)
>>>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/tarfile.py",
>>>> line 1553, in open
>>>> raise ReadError("file could not be opened successfully")
>>>> tarfile.ReadError: file could not be opened successfully
>>>>
>>>> ===

Re: GSOC 2015 project ideas suggestion

[Asif Saifuddin]

About the best practice project idea I'm analyzing contrib apps. I found
Admin docs app using class based views and probably it's almost up to date.
for admin and some other apps there are no class based views used. for
revamping django admin as a part of best practice update hoow about
extending django admin with the ideas from 3rd party apps llike djang admin
2? or others. just for querying

Regards

On Fri, Mar 6, 2015 at 2:26 AM, Tim Graham <timogra...@gmail.com> wrote:

> I have seen that error on my own system Ubuntu 14.04 & Python 3.4.2
> (installed from source), but didn't investigate the cause. I just installed
> Python 3.4.3, however, and don't have the problem there. Now I've
> reinstalled 3.4.2 and the error is resolved there as well.
>
>
> On Thursday, March 5, 2015 at 2:29:36 PM UTC-5, Asif Saifuddin wrote:
>>
>> Hi,
>>
>> running django test suite under python 3.4.3 on my ubuntu 14.10 produce
>> the below output
>>
>> ERROR: test_extract_function (utils_tests.test_archive.TestBzip2Tar)
>> --
>> Traceback (most recent call last):
>>   File "/home/asif/foss/django/tests/utils_tests/test_archive.py", line
>> 42, in test_extract_function
>> extract(self.archive_path, self.tmpdir)
>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-
>> packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
>> line 49, in extract
>> with Archive(path) as archive:
>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-
>> packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
>> line 58, in __init__
>> self._archive = self._archive_cls(file)(file)
>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-
>> packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
>> line 138, in __init__
>> self._archive = tarfile.open(file)
>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/tarfile.py", line
>> 1553, in open
>> raise ReadError("file could not be opened successfully")
>> tarfile.ReadError: file could not be opened successfully
>>
>> ==
>> ERROR: test_extract_function_no_to_path (utils_tests.test_archive.
>> TestBzip2Tar)
>> --
>> Traceback (most recent call last):
>>   File "/home/asif/foss/django/tests/utils_tests/test_archive.py", line
>> 51, in test_extract_function_no_to_path
>> extract(self.archive_path)
>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-
>> packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
>> line 49, in extract
>> with Archive(path) as archive:
>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-
>> packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
>> line 58, in __init__
>> self._archive = self._archive_cls(file)(file)
>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-
>> packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
>> line 138, in __init__
>> self._archive = tarfile.open(file)
>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/tarfile.py", line
>> 1553, in open
>> raise ReadError("file could not be opened successfully")
>> tarfile.ReadError: file could not be opened successfully
>>
>> ==
>> ERROR: test_extract_function_with_leadpath (utils_tests.test_archive.
>> TestBzip2Tar)
>> --
>> Traceback (most recent call last):
>>   File "/home/asif/foss/django/tests/utils_tests/test_archive.py", line
>> 46, in test_extract_function_with_leadpath
>> extract(self.archive_lead_path, self.tmpdir)
>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-
>> packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
>> line 49, in extract
>> with Archive(path) as archive:
>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-
>> packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
>> line 58, in __init__
>> self._archive = self._archive_cls(file)(file)
>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-
>> packages/Django-1.9.dev20150303124612-

CSRF cipher in xor + base64 or Vignere cipher

[Asif Saifuddin]

Hi,

Just start working on this 
ticket https://code.djangoproject.com/ticket/20869

wondering what should be the preferred way ?

using XOR or Vignere Cipher?


Reagrds

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3d23b87e-c153-4035-a838-331d5bc9cd1d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2015 project ideas suggestion

[Asif Saifuddin]

_to_path 
(utils_tests.test_archive.TestBzip2Tar)
--
Traceback (most recent call last):
  File "/home/asif/foss/django/tests/utils_tests/test_archive.py", line 37, 
in test_extract_method_no_to_path
with Archive(self.archive_path) as archive:
  File 
"/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
 
line 58, in __init__
self._archive = self._archive_cls(file)(file)
  File 
"/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
 
line 138, in __init__
self._archive = tarfile.open(file)
  File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/tarfile.py", line 
1553, in open
raise ReadError("file could not be opened successfully")
tarfile.ReadError: file could not be opened successfully

--
Ran 9087 tests in 214.033s

FAILED (errors=5, skipped=535, expected failures=7)
Destroying test database for alias 'default'...
Destroying test database for alias 'other'...


before that python 3.4.3 was installed under pyenv without bztar2 or 
something like that and gnu readline


I was preparing to work on some old tickets actually. Although not sure its 
the right place to post this issue.


regards

On Tuesday, January 27, 2015 at 11:15:20 PM UTC+6, Asif Saifuddin wrote:
>
> Hi,
>
> Although probably It's quite very early to ask about GSOC 2015 in January, 
>  I would like to start analyzing to prepare myself for choosing a correct 
> project and submitting a good proposal for that to get selected. I haven't 
> found any GSOC 2015 project ideas pages yet. But got some older idea pages 
>  of year 2013 and 2014. Should I look forward to the ideas that were 
> unimplemented or wait for gsoc 2015 wiki ideas page?
>
> ./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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e968ea76-a3b6-4649-8b5b-04d820f32c4a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: RE Composite fields-/ Multi Primary / Foreign keys

[Asif Saifuddin]

Hi Aron,

this discussion thread might interest you to collaborate

https://groups.google.com/forum/?utm_source=digest_medium=email#!topic/django-developers/MZUcOE6-7GY

On Tuesday, February 24, 2015 at 12:14:19 PM UTC+6, Aron Podrigal wrote:
>
> Hi, I just came across a project that requires  this functionality of 
> multi primary/foreign keys. So I'm bumping up this thread 
> again.
>  
> There were a lot of changes in django and the db api hasre-factored  since 
> this topic was discussed. It might be a time for another start on this 
> project. I'm willing to work on this as long it is ok with the core 
> developers. I didn't have much time yet to spend on this. I'm still reading 
> through the other earlier threads on possible implementations.
> I will post my proposal for this over the weekend. In the meantime I would 
> like to get some feedback from the community. 
>
> Aron.
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/31b58c26-71be-4075-a4dc-e1aca33bcc66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2015 project ideas suggestion

[Asif Saifuddin]

Thanks Russell.

Investigating contrib apps I can see some are django apps using django
framework and some are modules which is used to extend django frameworks
functionality.

For admin app theres is no use of urls.py for the admin app but admin_urls
in template tags, admin_lists etc. isn't it possible to used classed based
views,  to handle views and forms? there are also many files some of them
could be changed unders class based views. are this type of checking shoul
I perform to prepare my proposal for best practices ?

Reagrds



On Tue, Feb 24, 2015 at 6:09 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> Hi Asif,
>
> The "Best Practices" project requires a bit of investigation on your part.
> The project description gives one suggestion (expanding the use of
> Class-based views), but essentially, pick any feature that has been added
> in the last 5 years, and see if Django is making good use of that feature
> internally. If not, propose how we could be doing better.
>
> Yours,
> Russ Magee %-)
>
> On Mon, Feb 23, 2015 at 1:00 AM, Asif Saifuddin <auv...@gmail.com> wrote:
>
>> Seems my previous idea is not well suited for gsoc right now. have to
>> look for more convanient ideas then. what about best practise update? where
>> will I get Ideas about what are considered as best practise in django
>> 1.8/+? or other suggestions?
>>
>> Regards
>>
>> On Sun, Feb 22, 2015 at 6:36 AM, Russell Keith-Magee <
>> russ...@keith-magee.com> wrote:
>>
>>>
>>> To my mind, the goal of this project isn't to replace Django's routing
>>> infrastructure - as Josh and Florian have pointed out, unless you can
>>> provide a backwards compatible interface as well as tangible API
>>> improvements, we're unlikely to adopt that code.
>>>
>>> However, there *would* be benefit in making changes to Django's codebase
>>> so that if someone *wanted* to use an alternate routing infrastructure,
>>> they could, *in their own project*. In this context, the purpose of using
>>> webOb/werkzeug routing isn't to provide new features or backwards
>>> compatibility - it's to demonstrate that a completely alien codebase with
>>> analogous features can be integrated into Django's infrastructure using a
>>> standardised API.
>>>
>>> That said, I don't know enough about webOb or werkzeug to know if this
>>> is even plausible, so you'd need to provide a very strong technical
>>> proposal for this to be selected as a GSoC project.
>>>
>>> Yours,
>>> Russ Magee %-)
>>>
>>> On Sun, Feb 22, 2015 at 8:04 AM, Josh Smeaton <josh.smea...@gmail.com>
>>> wrote:
>>>
>>>> To expand on Florians reply, why do you think replacing the routing
>>>> infrastructure is a good idea? Is there any tangible benefit in doing so?
>>>> Can you demonstrate that you can stay completely backwards compatible while
>>>> realising those benefits? If there answer is no to benefits or backwards
>>>> compatibility, then I don't think you're going to see much support for the
>>>> idea.
>>>>
>>>> Regards,
>>>>
>>>>
>>>> On Sunday, 22 February 2015 07:52:49 UTC+11, Florian Apolloner wrote:
>>>>>
>>>>> Hi Aisf,
>>>>>
>>>>> while it theoretically would be possible to replace all of Django's
>>>>> request/response handling with Werkzeug, there is not much gain in it
>>>>> currently -- especially when considering backwards compatibility etc…
>>>>>
>>>>> Cheers,
>>>>> Florian
>>>>>
>>>>> On Saturday, February 21, 2015 at 9:14:27 PM UTC+1, Asif Saifuddin
>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Analyzing django code base docs and other tools I'm thinking of using
>>>>>> werkzeug's routing infrastructure for developing django's one. django 
>>>>>> http
>>>>>> mechanism can e re written using webOb/werkzeugs utilities too. this will
>>>>>> need working django urlresolve, urls, middlewares, views, http and some
>>>>>> more related components. Introducinf werkzeug/+webOb in django will let
>>>>>> eliminate some of django's built in way of handling request/response
>>>>>> processing, urlresolving, url routing, view processing some error 
>>>>>> handling
>>>>>> etc.
>>>>>>
>

Re: GSOC 2015 project ideas suggestion

[Asif Saifuddin]

Seems my previous idea is not well suited for gsoc right now. have to look
for more convanient ideas then. what about best practise update? where will
I get Ideas about what are considered as best practise in django 1.8/+? or
other suggestions?

Regards

On Sun, Feb 22, 2015 at 6:36 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> To my mind, the goal of this project isn't to replace Django's routing
> infrastructure - as Josh and Florian have pointed out, unless you can
> provide a backwards compatible interface as well as tangible API
> improvements, we're unlikely to adopt that code.
>
> However, there *would* be benefit in making changes to Django's codebase
> so that if someone *wanted* to use an alternate routing infrastructure,
> they could, *in their own project*. In this context, the purpose of using
> webOb/werkzeug routing isn't to provide new features or backwards
> compatibility - it's to demonstrate that a completely alien codebase with
> analogous features can be integrated into Django's infrastructure using a
> standardised API.
>
> That said, I don't know enough about webOb or werkzeug to know if this is
> even plausible, so you'd need to provide a very strong technical proposal
> for this to be selected as a GSoC project.
>
> Yours,
> Russ Magee %-)
>
> On Sun, Feb 22, 2015 at 8:04 AM, Josh Smeaton <josh.smea...@gmail.com>
> wrote:
>
>> To expand on Florians reply, why do you think replacing the routing
>> infrastructure is a good idea? Is there any tangible benefit in doing so?
>> Can you demonstrate that you can stay completely backwards compatible while
>> realising those benefits? If there answer is no to benefits or backwards
>> compatibility, then I don't think you're going to see much support for the
>> idea.
>>
>> Regards,
>>
>>
>> On Sunday, 22 February 2015 07:52:49 UTC+11, Florian Apolloner wrote:
>>>
>>> Hi Aisf,
>>>
>>> while it theoretically would be possible to replace all of Django's
>>> request/response handling with Werkzeug, there is not much gain in it
>>> currently -- especially when considering backwards compatibility etc…
>>>
>>> Cheers,
>>> Florian
>>>
>>> On Saturday, February 21, 2015 at 9:14:27 PM UTC+1, Asif Saifuddin wrote:
>>>>
>>>> Hi,
>>>>
>>>> Analyzing django code base docs and other tools I'm thinking of using
>>>> werkzeug's routing infrastructure for developing django's one. django http
>>>> mechanism can e re written using webOb/werkzeugs utilities too. this will
>>>> need working django urlresolve, urls, middlewares, views, http and some
>>>> more related components. Introducinf werkzeug/+webOb in django will let
>>>> eliminate some of django's built in way of handling request/response
>>>> processing, urlresolving, url routing, view processing some error handling
>>>> etc.
>>>>
>>>> Sould I go for a detail one with what I have thought to implement till
>>>> now?
>>>>
>>>> ./auvipy
>>>>
>>>> On Wed, Feb 4, 2015 at 5:57 AM, Russell Keith-Magee <
>>>> rus...@keith-magee.com> wrote:
>>>>
>>>>>
>>>>> On Wed, Feb 4, 2015 at 1:49 AM, Asif Saifuddin <auv...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Thank you both for the feedback. I will continue my analysis to
>>>>>> understand django well and also try to contribute some patch on django 
>>>>>> if I
>>>>>> can.
>>>>>>
>>>>>>
>>>>>> For django URL dispatcher improvement I am also looking for some
>>>>>> suggestions. Should I also look to some tool like werkzeug, webob along
>>>>>> side django http, url dispatch, middleware and related stuffs. Some guide
>>>>>> will help me to dig more and go to proper direction.
>>>>>>
>>>>>
>>>>> Take inspiration from wherever you can. Those patches will demonstrate
>>>>> different ways of doing dispatch, and different ways to organize a stack;
>>>>> in an ideal world, you should be able to use any of those techniques in
>>>>> Django as well. If you can find a way to modify Django so that those
>>>>> techniques can be used (either by directly using a third party package, or
>>>>> by building a Django equivalent), then I'd say you've cracked the core of
>>>>> the project.
>>>>>
>&

Re: GSOC 2015 project ideas suggestion

[Asif Saifuddin]

Hi,

Analyzing django code base docs and other tools I'm thinking of using
werkzeug's routing infrastructure for developing django's one. django http
mechanism can e re written using webOb/werkzeugs utilities too. this will
need working django urlresolve, urls, middlewares, views, http and some
more related components. Introducinf werkzeug/+webOb in django will let
eliminate some of django's built in way of handling request/response
processing, urlresolving, url routing, view processing some error handling
etc.

Sould I go for a detail one with what I have thought to implement till now?

./auvipy

On Wed, Feb 4, 2015 at 5:57 AM, Russell Keith-Magee <russ...@keith-magee.com
> wrote:

>
> On Wed, Feb 4, 2015 at 1:49 AM, Asif Saifuddin <auv...@gmail.com> wrote:
>
>> Thank you both for the feedback. I will continue my analysis to
>> understand django well and also try to contribute some patch on django if I
>> can.
>>
>>
>> For django URL dispatcher improvement I am also looking for some
>> suggestions. Should I also look to some tool like werkzeug, webob along
>> side django http, url dispatch, middleware and related stuffs. Some guide
>> will help me to dig more and go to proper direction.
>>
>
> Take inspiration from wherever you can. Those patches will demonstrate
> different ways of doing dispatch, and different ways to organize a stack;
> in an ideal world, you should be able to use any of those techniques in
> Django as well. If you can find a way to modify Django so that those
> techniques can be used (either by directly using a third party package, or
> by building a Django equivalent), then I'd say you've cracked the core of
> the project.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/WF3My-cZNtY/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJxq84_XbuDCeX5LHgP4%2BuCYdzBAUUMY4EJxYj8WU%3DBP43onXA%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAJxq84_XbuDCeX5LHgP4%2BuCYdzBAUUMY4EJxYj8WU%3DBP43onXA%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKAqTgr6r%2BTrdFrgGSbCXvwR38O%2BfHKEzou-P2aHLvcNBWhTFg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2015 project ideas suggestion

[Asif Saifuddin]

Thank you both for the feedback. I will continue my analysis to understand
django well and also try to contribute some patch on django if I can.


For django URL dispatcher improvement I am also looking for some
suggestions. Should I also look to some tool like werkzeug, webob along
side django http, url dispatch, middleware and related stuffs. Some guide
will help me to dig more and go to proper direction.

./auvipy

On Tue, Feb 3, 2015 at 6:13 AM, Russell Keith-Magee <russ...@keith-magee.com
> wrote:

>
> On Mon, Feb 2, 2015 at 11:58 PM, Asif Saifuddin <auv...@gmail.com> wrote:
>
>> Hi Fabio,
>>
>> Thank you for your project ideas. I'm going to follow the ideas from
>> https://code.djangoproject.com/wiki/SummerOfCode2015
>>
>
> While this is definitely a safe option, don't rule out a
> 'not-on-the-official-list' project. The GSoC project list is a good list of
> pre-vetted projects, but it's not exhaustive. A well posed project,
> especially one relating to an old ticket, would certainly be a good
> candidate for the GSoC -  For example, multiple schema support is #6148
>
> https://code.djangoproject.com/ticket/6148
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/WF3My-cZNtY/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJxq849-9bAeo7dfoAk1XdGBFnBkykGVekRbJbs19_5UH3C1Kg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAJxq849-9bAeo7dfoAk1XdGBFnBkykGVekRbJbs19_5UH3C1Kg%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKAqTgowxrpXi2XWtf4dYH03DdBuuUeYpjjfwsA7-4nJX6xXHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2015 project ideas suggestion

[Asif Saifuddin]

Hi Josh,

There are two technical problems that need to be solved in order to make
this happen.

   - Implement the packaging definitions to allow for multiple packages.
   - Clean up dependencies between components. Despite the best of
   intentions, there are some interesting dependencies between modules, some
   of which may need to be clarified or separated.

The aim of this project would be to clean up one or more of Django's
internal "parts" so that it could be delivered as a standalone package.
This may not be something that can be immediately delivered - for example,
it may be necessary to move or rename components to enable separate
packaging. In this case, the project deliverable would be to document the
strategy, and provide whatever initial moves in that direction are possible.

A simpler version of this project would be to enable separate packaging and
distribution of Django's contrib apps.

alongside reduce tight coupling how should I approach to following part?

"A simpler version of this project would be to enable separate packaging
and distribution of Django's contrib apps."


I am looking for dev teams suggestions


./auvipy





On Mon, Feb 2, 2015 at 9:58 PM, Asif Saifuddin <auv...@gmail.com> wrote:

> Hi Fabio,
>
> Thank you for your project ideas. I'm going to follow the ideas from
> https://code.djangoproject.com/wiki/SummerOfCode2015
>
>
> for your babel porting probably Aymeric Augustin's template refactor
> project have some plan with babel integration, but I'm willing to work on
> reduce decoupling/Improve template dispatching for first priority from my
> side till now.
>
>
> Regards
>
> ./auvipy
>
> On Mon, Feb 2, 2015 at 9:39 PM, Fabio Caritas Barrionuevo da Luz <
> bna...@gmail.com> wrote:
>
>> Some ideas. (which still require approval of the core developers):
>>
>>
>> * Improve database backend base API and related features(including
>> introspection feature used by inspectdb), so that it is less complicated to
>> add in the future support the specific features of some backends. eg
>> multiple database schemas (common used in Oracle and PostgreSQL) and/or
>> Oracle synonym tables
>>
>> * port Django i18n and i10 and related translation features to use Babel:
>> http://babel.pocoo.org/
>>
>>
>>
>> Em terça-feira, 27 de janeiro de 2015 14:15:20 UTC-3, Asif Saifuddin
>> escreveu:
>>
>>> Hi,
>>>
>>> Although probably It's quite very early to ask about GSOC 2015 in
>>> January,  I would like to start analyzing to prepare myself for choosing a
>>> correct project and submitting a good proposal for that to get selected. I
>>> haven't found any GSOC 2015 project ideas pages yet. But got some older
>>> idea pages  of year 2013 and 2014. Should I look forward to the ideas that
>>> were unimplemented or wait for gsoc 2015 wiki ideas page?
>>>
>>> ./auvipy
>>>
>>  --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/WF3My-cZNtY/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/cbb457c7-66cb-4370-99de-c9cfcd2a5622%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/cbb457c7-66cb-4370-99de-c9cfcd2a5622%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKAqTgpmtLaNke2%3DaRC%2BPitvpdyfA_9uWdON%2BJc-5GTVTvJekQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2015 project ideas suggestion

[Asif Saifuddin]

Hi Fabio,

Thank you for your project ideas. I'm going to follow the ideas from
https://code.djangoproject.com/wiki/SummerOfCode2015


for your babel porting probably Aymeric Augustin's template refactor
project have some plan with babel integration, but I'm willing to work on
reduce decoupling/Improve template dispatching for first priority from my
side till now.


Regards

./auvipy

On Mon, Feb 2, 2015 at 9:39 PM, Fabio Caritas Barrionuevo da Luz <
bna...@gmail.com> wrote:

> Some ideas. (which still require approval of the core developers):
>
>
> * Improve database backend base API and related features(including
> introspection feature used by inspectdb), so that it is less complicated to
> add in the future support the specific features of some backends. eg
> multiple database schemas (common used in Oracle and PostgreSQL) and/or
> Oracle synonym tables
>
> * port Django i18n and i10 and related translation features to use Babel:
> http://babel.pocoo.org/
>
>
>
> Em terça-feira, 27 de janeiro de 2015 14:15:20 UTC-3, Asif Saifuddin
> escreveu:
>
>> Hi,
>>
>> Although probably It's quite very early to ask about GSOC 2015 in
>> January,  I would like to start analyzing to prepare myself for choosing a
>> correct project and submitting a good proposal for that to get selected. I
>> haven't found any GSOC 2015 project ideas pages yet. But got some older
>> idea pages  of year 2013 and 2014. Should I look forward to the ideas that
>> were unimplemented or wait for gsoc 2015 wiki ideas page?
>>
>> ./auvipy
>>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/WF3My-cZNtY/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/cbb457c7-66cb-4370-99de-c9cfcd2a5622%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/cbb457c7-66cb-4370-99de-c9cfcd2a5622%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKAqTgpWbaSU%3DS%3DtvNq%3Dp-WiZMz2WD3r5H7%3D%2Bdv469udGn5tNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2015 project ideas suggestion

[Asif Saifuddin]

Hi,

For the Reducing coupling of Django components project I have some broader
Aim and objectives in my which I am planning to propose.

The main goal of this project proposal is to lay down the stepping stones
for reducing coupling in django internal components. To achieve the goal

1. Analyze and find out which components need to be included in django
proper and which need to be shipped in a different package.

2. There are Contrib Apps which are mainly django applications and can be
moved and evolved as different packages outside django repo. like
dj-admin/django-admin, django-gis/geodjango etc

3. Django ORM, Forms, Test, template this need work for moving as single
packages. Probably django-orm/django-db, django-forms etc.

This are the basic objectives of my proposals in very brief.


I would like to propose more detail  one with with technical details and my
plans to make this project success after having some feedback from core dev
teams.


Looking forward to some feedback if my initial move is okeyish?

./auvipy

On Wed, Jan 28, 2015 at 2:19 PM, Asif Saifuddin <auv...@gmail.com> wrote:

> Hi,
>
> Thank you both of you for your response with guidelines.
>
> I found a old project
> Reducing coupling in Django components
>
>- *Complexity:* Hard
>
>
> and a newer project
>
> Improving URL dispatch
> <https://code.djangoproject.com/wiki/SummerOfCode2015#ImprovingURLdispatch>
>
>- "Complexity:" Hard
>
>
> Interests me.
>
>
>
>
> With the first project I have some concrete ideas on mind to share with
> technical aspects and my proposed terms to be reviewed by the core team. I
> will soon share my understanding and proposal about this project.
>
> With The second project I'm still not fully sure about the technical
> implementation and I need some more analysis to understand.
>
>
> ./auvipy
>
> On Wed, Jan 28, 2015 at 1:41 AM, Tim Graham <timogra...@gmail.com> wrote:
>
>> I've created a wiki page for this year. It includes some ideas from past
>> years which may or may not still be relevant (I did some light editing). Of
>> course, you are welcome to propose something entirely different related to
>> your interests.
>>
>> https://code.djangoproject.com/wiki/SummerOfCode2015
>>
>> On Tuesday, January 27, 2015 at 2:01:33 PM UTC-5, Marc Tamlyn wrote:
>>>
>>> Anything not done from previous years is likely to be suitable yes.
>>>
>>> It would also be very beneficial to familiarise yourself with the
>>> contributing guidelines for Django[1] and take on some small fixes, perhaps
>>> in related areas to your interests for GSOC.
>>>
>>> Marc
>>>
>>> [1] https://docs.djangoproject.com/en/1.7/internals/contributing/
>>>
>>> On 27 January 2015 at 17:15, Asif Saifuddin <auv...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Although probably It's quite very early to ask about GSOC 2015 in
>>>> January,  I would like to start analyzing to prepare myself for choosing a
>>>> correct project and submitting a good proposal for that to get selected. I
>>>> haven't found any GSOC 2015 project ideas pages yet. But got some older
>>>> idea pages  of year 2013 and 2014. Should I look forward to the ideas that
>>>> were unimplemented or wait for gsoc 2015 wiki ideas page?
>>>>
>>>> ./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-develop...@googlegroups.com.
>>>> To post to this group, send email to django-d...@googlegroups.com.
>>>> Visit this group at http://groups.google.com/group/django-developers.
>>>> To view this discussion on the web visit https://groups.google.com/d/
>>>> msgid/django-developers/92f8aa3d-69da-4be2-af5a-
>>>> b2a0f55d616b%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/django-developers/92f8aa3d-69da-4be2-af5a-b2a0f55d616b%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 a topic in the
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/WF3My-cZNtY/u

Re: GSOC 2015 project ideas suggestion

[Asif Saifuddin]

Hi,

Thank you both of you for your response with guidelines.

I found a old project
Reducing coupling in Django components

   - *Complexity:* Hard


and a newer project

Improving URL dispatch
<https://code.djangoproject.com/wiki/SummerOfCode2015#ImprovingURLdispatch>

   - "Complexity:" Hard


Interests me.




With the first project I have some concrete ideas on mind to share with
technical aspects and my proposed terms to be reviewed by the core team. I
will soon share my understanding and proposal about this project.

With The second project I'm still not fully sure about the technical
implementation and I need some more analysis to understand.


./auvipy

On Wed, Jan 28, 2015 at 1:41 AM, Tim Graham <timogra...@gmail.com> wrote:

> I've created a wiki page for this year. It includes some ideas from past
> years which may or may not still be relevant (I did some light editing). Of
> course, you are welcome to propose something entirely different related to
> your interests.
>
> https://code.djangoproject.com/wiki/SummerOfCode2015
>
> On Tuesday, January 27, 2015 at 2:01:33 PM UTC-5, Marc Tamlyn wrote:
>>
>> Anything not done from previous years is likely to be suitable yes.
>>
>> It would also be very beneficial to familiarise yourself with the
>> contributing guidelines for Django[1] and take on some small fixes, perhaps
>> in related areas to your interests for GSOC.
>>
>> Marc
>>
>> [1] https://docs.djangoproject.com/en/1.7/internals/contributing/
>>
>> On 27 January 2015 at 17:15, Asif Saifuddin <auv...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Although probably It's quite very early to ask about GSOC 2015 in
>>> January,  I would like to start analyzing to prepare myself for choosing a
>>> correct project and submitting a good proposal for that to get selected. I
>>> haven't found any GSOC 2015 project ideas pages yet. But got some older
>>> idea pages  of year 2013 and 2014. Should I look forward to the ideas that
>>> were unimplemented or wait for gsoc 2015 wiki ideas page?
>>>
>>> ./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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/django-developers/92f8aa3d-69da-4be2-af5a-
>>> b2a0f55d616b%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/92f8aa3d-69da-4be2-af5a-b2a0f55d616b%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 a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/WF3My-cZNtY/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/cfe3dfff-2099-4715-a04c-f43c3120a6c3%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/cfe3dfff-2099-4715-a04c-f43c3120a6c3%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKAqTgoevaM1h8Gbp1XgbS5hQBZqnzj0mMRyQ9_MKXyvoST_nQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

GSOC 2015 project ideas suggestion

[Asif Saifuddin]

Hi,

Although probably It's quite very early to ask about GSOC 2015 in January, 
 I would like to start analyzing to prepare myself for choosing a correct 
project and submitting a good proposal for that to get selected. I haven't 
found any GSOC 2015 project ideas pages yet. But got some older idea pages 
 of year 2013 and 2014. Should I look forward to the ideas that were 
unimplemented or wait for gsoc 2015 wiki ideas page?

./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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/92f8aa3d-69da-4be2-af5a-b2a0f55d616b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Content Negotiation implement

[Asif Saifuddin]

Thank you both for your kind response.

I have only almost about a year working with django and still learing. My
django and python skills are still so limited as far I know. Reading the
dep and other related links of discussions and browsing some source code
things are bit overwhelming to me right now :p  but I am willing to expand
my technical knowledge  by learning and trying to contribute on this part.

I have some limitations in design decisions and understanding the overall
implementation process But still I want to start working on this part
primarily with you guys helps and suggestions.

I'll be trying to enhance my knowledge base about django request response
and other related stuffs necessary if you please show me some light to get
started or from where actually should I start.

Kind Regards

Asif

On Sun, Nov 9, 2014 at 4:31 PM, Asif Saifuddin <auv...@gmail.com> wrote:

> Thank you both for your kind response.
>
> I have only almost about a year working with django and still learing. My
> django and python skills are still so limited as far I know. Reading the
> dep and other related links of discussions and browsing some source code
> things are bit overwhelming to me right now :p  but I am willing to expand
> my technical knowledge  by learning and trying to contribute on this part.
>
> I have some limitations in design decisions and understanding the overall
> implementation process But still I want to start working on this part
> primarily with you guys helps and suggestions.
>
> I'll be trying to enhance my knowledge base about django request response
> and other related stuffs necessary if you please show me some light to get
> started or from where actually should I start.
>
> Kind Regards
>
> Asif
>
>
> On Saturday, November 8, 2014 3:01:28 PM UTC+6, Asif Saifuddin wrote:
>>
>> Hi,
>>  when https://github.com/django/deps/blob/master/drafts/
>> content-negotiation.rst this dep is to be implemented in django? 1.8?
>>
>> Regards
>>
>> Asif
>>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/g1P7H1PhZaY/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/436d3c71-2567-462d-a035-9880511124ab%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/436d3c71-2567-462d-a035-9880511124ab%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKAqTgrf-nDKfEf63r76d_Kd9AhYj7H-cqv6gDk5Oyid86JcdQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Content Negotiation implement

[Asif Saifuddin]

Thank you both for your kind response.

I have only almost about a year working with django and still learing. My 
django and python skills are still so limited as far I know. Reading the 
dep and other related links of discussions and browsing some source code 
things are bit overwhelming to me right now :p  but I am willing to expand 
my technical knowledge  by learning and trying to contribute on this part.

I have some limitations in design decisions and understanding the overall 
implementation process But still I want to start working on this part 
primarily with you guys helps and suggestions.

I'll be trying to enhance my knowledge base about django request response 
and other related stuffs necessary if you please show me some light to get 
started or from where actually should I start.

Kind Regards

Asif 


On Saturday, November 8, 2014 3:01:28 PM UTC+6, Asif Saifuddin wrote:
>
> Hi,
>  when 
> https://github.com/django/deps/blob/master/drafts/content-negotiation.rst 
> this dep is to be implemented in django? 1.8?
>
> Regards
>
> 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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/436d3c71-2567-462d-a035-9880511124ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.