Łukasz Rekucki, Thanks for the reply. I wasn't being cynical when I said:
> If the API for this feature was not so intrinsically > obscure, it might be a more obvious choice to include it right away, What I meant was the design and implementation creates an unusable API by default. This is a sign that it's not quite ready. I don't suggest putting it off for another 2 years, but now that things are really starting to roll with Django, and more developers are getting added, it's worst time to start shoveling things in that a lot of people don't like, crippling production and evolution that could otherwise come very quickly now. > come help out! What do you call this. I don't see how any software developer could consider constructive criticism as anything other than helping out. Just about 90% of software development is in the mind (at least for me), and the other 10% is spent typing as fast as I can. On Oct 15, 2:10 pm, Łukasz Rekucki <lreku...@gmail.com> wrote: > On 15 October 2010 21:40, Yo-Yo Ma <baxterstock...@gmail.com> wrote: > > > My strong suggestion (again prima facie to this discussion) is: > > > Do not include something as controversial into the trunk, especially > > with the justification of, "There are quite a few sets of class-based > > views out there". > > That section probably needs extending, but imho it didn't get much > love, because we pretty much all agree we need this feature for > reusable apps to make sense. The only question is how to do it and > this was discussed many times in the passed, discussed on > DjangoCon[1][2] and recently on this mailing list for over a week with > over 100 posts. So, no - that's not the only justification. > > > If the API for this feature was not so intrinsically > > obscure, it might be a more obvious choice to include it right away, > > This isn't very constructive. If you want to show us a better API, > just fork Rusell's code[3] and go ahead. > > > but considering the "don't break the API" locked in nature of Django's > > trunk, it might be worth rehashing this argument after 1.3. Almost > > making it into the trunk will have surely opened a lot of eyes and > > will undoubtedly bring about new Git Hub forks with possibly better > > implementations and alternative APIs for class-based views. Something > > much better will come and it'll be too late. > > So we should because there might be a better solution in next 6 months > ? I don't think that is how "perfectionists with deadlines" work. This > is something that has been considered for over 2 years now. Perfection > is good, but the deadline is almost here, IMHO. > > So if you really are concerned with state of CBV, come help out! Just > shouting "your API sucks" doesn't help anyone. > > [1]:http://blip.tv/file/4109272 > [2]:http://blip.tv/file/4108781 > [3]:http://bitbucket.org/freakboy3742/django > > -- > Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
