Re: Ideas for a new DEP on long-term Django API compatibility

2019-08-20 Thread Pascal Chambon
Hello, Just for the record, we spent a good time discussion this change (to bring > inheritance of Admin Actions in line with Python’s expected inheritance > rules). We reviewed the entire history of the feature. We explored an > alternative approach, which would have maintained BC. We put the dis

Re: Django Async DEP

2019-06-08 Thread Pascal Chambon
Hello, There is something a little scary for me, in changing all the core of Django to async, when this really helps only, imho, a tiny fraction of users : websocket/long polling services, and reddit-like sites with thousands+ hits per second. For most webpages and webservices, async artillery sou

Re: Presenting DCP, a compatibility layer for Django (feedback welcome)

2017-01-24 Thread Pascal Chambon
ture would need to provide a *wrapper* around Django's > APIs and not modify it: other code in > the project is likely to rely on the documented behaviour. > > > For the third part, I'm unsure how you'd handle various libraries having > different Django target versi

Re: Presenting DCP, a compatibility layer for Django (feedback welcome)

2017-01-23 Thread Pascal Chambon
uld love it, if they could upgrade THEIR codebase semi-automatically, instead of doing mass regex search/replaces. There are plenty of AST modifiers for python ( https://github.com/berkerpeksag/astor, or others, pytest does some nifty ast hacking too...), else a regex based django-command would alrea

Re: Presenting DCP, a compatibility layer for Django (feedback welcome)

2017-01-22 Thread Pascal Chambon
Hi, @James Pc - thanks for the support, if you happen to miss some fixers in DCP and don't have the opportunity to contribute them, please open an issue so that I have a look @Tim Graham & James James Bennett - from what I sum up, the new policy simply extends the delay between breaking changes,

Re: Presenting DCP, a compatibility layer for Django (feedback welcome)

2017-01-15 Thread Pascal Chambon
I don't think it says much. What >> I'd do, is rather run the unit-tests of the previous django version >> (excluding some specifically marked "short-lived" tests), against the >> newest code. This would mean so much more. >> >> Here is my view on wh

Re: Fate of sql* management commands

2015-04-03 Thread Pascal Chambon
Hello, sorry for the delay (I'm moving home), thanks for the detailed explanations, I've learned a lot about the new status of migrations, and I guess every django users might benefit from this "shift of canonical representation", that's why there shouldbe room for a proper introduction in django

Re: Fate of sql* management commands

2015-03-30 Thread Pascal Chambon
Thanks for your answers, l'm confused nonetheless, because their are two notions mixing up, here, that we should probably separate: - the HISTORY of SQL schemas, aka "django/south migrations" - the CURRENT STATE of SQL schemas, that I'll call "ORM Models Dump" Let's leave the SQL data (and its m