Progress report: django-mssql for Linux

Hello all: I just want to let everyone know what has happened on this proposal in the last little while. 1) The combination of a Linux (or Windows) database client with a Windows proxy database server is up and running. The remote supports all of the features of adodbapi (when run locally)

Re: Progress report: django-mssql for Linux

Hi Vernon, I'm glad to see that your plan is working. Regarding "auto_proxy", I would advise against magic configuration; explicit is better than implicit. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe

Re: Recommending a Python 3-compatible MySQL connector

On 7 mai 2013, at 08:34, Aymeric Augustin wrote: > These problems look fairly easy. I plan to work on them. I just updated the pull request and everything works except BinaryField: https://code.djangoproject.com/ticket/20025#comment:5 Something forces the

Re: Moving from PIL to Pillow

On 1 mars 2013, at 17:59, Alex Clark wrote: > Everything else e.g. "from PIL import Image" should be the same. Hi Alex, As we're starting to clear the blockers for the release of Django 1.6, I'm resurrecting this discussion. Quick question: is there a way to tell if the

Re: Ticket 19445

Hi Luke, On May 1, 2013, at 3:31 PM, Luke Plant wrote: > Hi all, > > Can I get some feedback on what to do about ticket 19445? > > https://code.djangoproject.com/ticket/19445 > > I have re-opened this ticket because I don't think it was addressed > satisfactorily. I

Re: test discovery

On May 8, 2013, at 5:00 PM, Carl Meyer wrote: > Jacob has suggested that back-compat breaks in test-running are not as > serious as in production code, and that we should just switch to the new > test runner by default in Django 1.6. This is what the pull request > currently

Re: test discovery

On 8 mai 2013, at 23:00, Carl Meyer wrote: > Jacob has suggested that back-compat breaks in test-running are not as > serious as in production code, and that we should just switch to the new > test runner by default in Django 1.6. This is what the pull request > currently does.

Re: test discovery

It would be really nice to be able to use same syntax for running a single Django's testcase at least for a while. I expect that there will be problems if inspecting how a given test case behaves in older versions compared to HEAD. Also, bisecting over the test case renaming boundary will be

Re: test discovery

On Wed, May 8, 2013 at 2:00 PM, Carl Meyer wrote: > Jacob has suggested that back-compat breaks in test-running are not as > serious as in production code, and that we should just switch to the new > test runner by default in Django 1.6. I still think this. I don't see the need

Re: test discovery

Hi Anssi, On 05/08/2013 03:31 PM, Anssi Kääriäinen wrote: > It would be really nice to be able to use same syntax for running a > single Django's testcase at least for a while. I expect that there > will be problems if inspecting how a given test case behaves in older > versions compared to HEAD.

Ticket #13910: Generator based rendering (streaming) of templates

Hi all, I picked up on earlier work done for generator based template rendering, brought it up to master and improved a little on it with tests and a StreamingTemplateView class. I've created the following pull request for consideration: https://github.com/django/django/pull/1037 Feedback

Re: Ticket 19445

On 07/05/13 02:04, Russell Keith-Magee wrote: > As for the "ModelForm without a Meta" approach -- I see what you're > driving at, and I can see how it's an elegant solution to the problem. > My concern is that we'd be encouraging people to pass around > "half-baked" ModelForm definitions -- i.e.,