Doc fix for list_editable fields for 1.1 - 1.5

2012-12-04 Thread Fred Cox
Please consider incorporating a doc patch (attached to #11313) for this release, and backpatching it to previous docs (1.1 - 1.4). The current implementation of list_editable in the Django admin is fundamentally broken in the face of possible changes to the data while the list page is up in

Re: Django 2.0 - a case for a customizable pony

2012-12-04 Thread ptone
I think you can see one pilot of future decoupling with what is happening with the localflavors being split into separate repos - what we learn from this process will be valuable when/if considering decoupling other parts of Django. Another major step is the pretty-far-along schema migration

Re: Django 2.0 - a case for a customizable pony

2012-12-04 Thread Jacob Kaplan-Moss
I don't really know how to respond to this other that "patches welcome". You're proposing very vague, sweeping changes with no details. That just doesn't work around here; if you want to make a big change you have to actually bring some hard work to the table. I think I probably agree with you in

Django 2.0 - a case for a customizable pony

2012-12-04 Thread Yo-Yo Ma
This morning read the SQLAlchemy proposal made by Luke Plant in June. I then decided that this would be a good time to rant about abstraction, extensibility, and decoupling. Background For years, Django has been forced to deal with most implementation issues from within,

django.utils.html.urlize and mark_safe

2012-12-04 Thread Gábor Farkas
hi, i think there is some use of unnecessary mark_safe in the above-mentioned function, but maybe i am overlooking something, so i thought before opening a ticket i will discuss it here. if you check the urlize-function https://github.com/django/django/blob/master/django/utils/html.py#L173, it