What about a built-in models.BitField 
<https://github.com/disqus/django-bitfield> ? Or a generic tagging function 
giving related items recommended by TF-IDF 
<http://en.wikipedia.org/wiki/TF-IDF>?

On Monday, February 23, 2015 at 4:01:11 AM UTC+11, Asif Saifuddin 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 <
> rus...@keith-magee.com <javascript:>> 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.s...@gmail.com 
>> <javascript:>> 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.
>>>>>>
>>>>>> 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-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/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&utm_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-develop...@googlegroups.com <javascript:>.
>>> To post to this group, send email to django-d...@googlegroups.com 
>>> <javascript:>.
>>> 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/c35b86be-cba9-4d66-8e8b-fb5fcb7cf92a%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/django-developers/c35b86be-cba9-4d66-8e8b-fb5fcb7cf92a%40googlegroups.com?utm_medium=email&utm_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-develop...@googlegroups.com <javascript:>.
>> To post to this group, send email to django-d...@googlegroups.com 
>> <javascript:>.
>> 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_tfCxFPG3fTY%2BNWcAcWV1tjv4VwE%2BvmWiKTsnTyPLAcg%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/CAJxq84_tfCxFPG3fTY%2BNWcAcWV1tjv4VwE%2BvmWiKTsnTyPLAcg%40mail.gmail.com?utm_medium=email&utm_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/93692793-7f87-463a-84a4-8fb140599d80%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to