Mostly for clarity and historical purpose, I'd like to expand on the points you listed.
Do not take this in any way as a dismissal of the issues you've raised. On 2 September 2014 06:45, Pkl <[email protected]> wrote: > > Hello, > > I once was once lured to an ideal of long-term stability and > retrocompatibility, by nice docs like this one : > https://docs.djangoproject.com/en/dev/misc/api-stability/ > > But for some years, stuffs have actually been getting worse and worse, > with each django release bringing its little crowd of nightmares. > > In random order, I stumbled upon: > - removal of django.conf.urls.defaults > This was moved into django.conf.urls ... > - removal of markup contrib lib (adios built-in RST support) > >From memory, this was due to a security issue with the Markdown library used. I, too , was hit by this, and ended up vendoring the tag library into my project. > - removal of request.raw_post_data (thus breaking about all existing > webservice libs) > It was renamed to request.body, not removed. This is because it represents the request body, no matter the HTTP method used. > - lots of changes in mandatory settings, like allowed_hosts or DB conf > format, > ALOWED_HOSTS was added as a security measure. The only significant DB config format I can recall was adding multi-DB support. Was there another? - future removal of the very basic "mimetype" argument from django objects > (how many apps impacted ? quite MANY I guess) > IIRC this was renamed to content-type, since "mime type" is, in fact, for email. > - future removal of request.REQUEST (aka "we're not all consenting adults, > let's remove all tools that people could misuse") > I remember the discussion for this. Primarily it was because it did cause security issues, as well as being unclear as to which was looked up first- GET or POST. As someone who has been using Django since 0.91... I've seen a lot of change over the years, some more drastic than others. I don't get this relentlessness at breaking, for the sake of purity, all > stuffs that are not actively maintained, yet could be perfectly working. > Whilst it could be argued that, for instance, request.body and requset.REQUEST were removed for "purity", it can also be said they were removed for clarity (to avoid confusion) and safety (to avoid real security issues). As for breaking unmaintained 3rd party apps... sorry, that's how the world works. If you want that project to keep up to date with Django, either incentivise the devlopers to do so, or contribute to them yourself. Such is open source. > What is easier, in a deeply dynamic language like python, than keeping > retrocompatibility ? > I do like this idea... it should be possible to monkey-path in at least some of these ideas. Open a ticket, CC me, and I'll happily work with you on a PR. If nothing else, we can make it a 3rd party app. > Why not keep "raw_post_data" as an undocumented alias for "body" ? Why not > keep "mimetype" as a silent alias for "content_type" ? > mimetype _was_ an alias for content_type for, IIRC, much longer than the usual 2-release deprecation cycle. > What harm did the "markup" support in django, since no one expects such > extensions to be 100% secure anyway (no software on earth is) ? If code > "purity" is wanted, then why not have all these monkey-patched from a > builtin, but removable, "django.compatibility" util ? Why not wait for 2.0, > to remove all compatibility aliases in one single shot ? > The current trend with contrib apps is to remove them if they'd benefit from a more frequent release cycle - one not tied to that of core. Howerver, I was a little surprised to see django.contrib.markup wasn't moved to a django-maintained 3rd party app like some others were. Perhaps open a ticket for that? > > The one killing features of django is its app ecosystem - being able to > plug blogs, authentication systems, webservice generators, and all other > kinds of applications, into this common framework, and benefit from the > common auto-admin. And since all these apps don't evolve at the same rythm, > retrocompatibility is IMHO a NECESSITY for django, not a LUXURY. Or isn't > it ? > > > Please don't kill the ecosystem, please respect the promises of > api-stability that were once made..... > These promises have been kept. There is a LOT of code that could be dropped or rewritten immediately if it weren't for the 2-relese deprecation cycle. One of my PRs was rejected specifically because I hadn't implemented a deprecation path. It would likely speed up template rendering, which I think everyone agrees is desirable. -- Curtis -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. 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/CAG_XiSDBkbqrk0XFhdTFjMGsZmggE4RP31WjXQBew5wadm%2BOUg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
