Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

For tracking purposes, I've opened a ticket: https://code.djangoproject.com/ticket/21829 Russ %-) On Sun, Jan 19, 2014 at 10:08 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > On 19 janv. 2014, at 13:46, Russell Keith-Magee > wrote: > > On Sun, Jan

Re: Django Security & OWASP Project

Hey Michael -- This sounds right up my ally. I'll jump on the list and post some more info over there. Jacob On Tuesday, January 14, 2014, Michael Coates wrote: > Django Developers, > > Hello! Over at OWASP I've started a framework security project. Our goal > is to

Re: Merging GSoC 2013 - Validation Refactor

Hi all, For notification purposes - this has been committed as of d818e0c, ready for 1.7 alpha. https://github.com/django/django/commit/d818e0c9b2b88276cc499974f9eee893170bf0a8 The final commit integrated a bunch of suggestions from a couple of reviewers, some Python 3 fixes, and a slight

Re: Testing parameters in database settings

On Wednesday 15 January 2014 00:02:52 Michael Manfre wrote: > On Tue, Jan 14, 2014 at 3:26 PM, Shai Berger wrote: > > > > Your suggestion, if I understand it correctly, gives the user two options: > > > > 1) Use separate credentials, and perhaps even a separate service, for >

Re: Ticket #21751 review requested

On Sunday 19 January 2014 10:44:32 Michael Manfre wrote: > On Sun, Jan 19, 2014 at 5:23 AM, Shai Berger wrote: > > Still, spreading with-blocks all over the code for this looks very ugly to > > me. > > I'd rather add an execute_single() or execute_and_close() method to the > >

Re: Ticket #21751 review requested

On Sun, Jan 19, 2014 at 5:23 AM, Shai Berger wrote: > > Still, spreading with-blocks all over the code for this looks very ugly to > me. > I'd rather add an execute_single() or execute_and_close() method to the > cursors instead. Perhaps even only as private API, as that usage

Re: Improving aggregate support (#14030)

There are a few other things that I need to try and get in before the 1.7 feature freeze. Since this is not slated for 1.7, I'll take a look a the PR after the freeze and see if the comments I had still apply. Regards, Michael Manfre On Sun, Jan 19, 2014 at 8:00 AM, Josh Smeaton

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

On 19 janv. 2014, at 13:46, Russell Keith-Magee wrote: > On Sun, Jan 19, 2014 at 5:48 PM, Aymeric Augustin > wrote: > > We can certainly use AppConfig.ready() for new features such as the checks > framework. It’s reasonable to ask

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

On Sun, Jan 19, 2014 at 9:52 PM, Marc Tamlyn wrote: > For what it's worth, if we have some code that: > > a) is a new feature we want to ensure runs > b) has no obvious, explicit place to place it > and > c) is trivially solved by .ready() > > Then I start to think that

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

For what it's worth, if we have some code that: a) is a new feature we want to ensure runs b) has no obvious, explicit place to place it and c) is trivially solved by .ready() Then I start to think that practicality beats purity. Personally, I think we should still encourage the "explicit"

Re: Feature request: serve_file() view in static app

PyPI packages 'static' and 'dj-static' might help you. -- 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 django-developers+unsubscr...@googlegroups.com. To

Re: Improving aggregate support (#14030)

I've finally sent a PR, so if you're still able, I'd love to see the specific comments you had. https://github.com/django/django/pull/2184 Cheers, - Josh On Sunday, 12 January 2014 10:35:58 UTC+11, Michael Manfre wrote: > > With minor tweaks to django-mssql's SQLCompiler, I am able to pass

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

HI Marc, On Sun, Jan 19, 2014 at 5:52 PM, Marc Tamlyn wrote: > All of your proposed solutions require trying to import an apps.py module > which may not exist. I know Aymeric was very much against this, especially > as python imports have potential side effects, and we

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

On Sun, Jan 19, 2014 at 5:48 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > On 19 janv. 2014, at 08:56, Russell Keith-Magee > wrote: > > This is fine, but it limits the logic that we (as a project) can put into > AdminConfig.ready(), because existing

Re: Ticket #21751 review requested

On Sunday 19 January 2014 11:52:40 Łukasz Rekucki wrote: > On 19 January 2014 09:12, Shai Berger wrote: > > On Friday 17 January 2014 01:19:29 Michael Manfre wrote: > >> In an effort to make Django a bit more explicit with regards to closing > >> cursors when they are no longer

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

All of your proposed solutions require trying to import an apps.py module which may not exist. I know Aymeric was very much against this, especially as python imports have potential side effects, and we don't know what people might have in a apps module already. Anyways, configuration over

Re: Ticket #21751 review requested

On 19 January 2014 09:12, Shai Berger wrote: > On Friday 17 January 2014 01:19:29 Michael Manfre wrote: >> In an effort to make Django a bit more explicit with regards to closing >> cursors when they are no longer needed, I have created ticket #21751 [1] >> with a pull

Re: Ticket #21751 review requested

On 19 janv. 2014, at 09:12, Shai Berger wrote: > I think this is suboptimal, API-wise. Python destroys temporaries soon > enough. > Is there a reason why we cannot arrange for a __del__ method to close the > cursor? Circular references anywhere? Hi Shai, You probably

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

On 19 janv. 2014, at 08:56, Russell Keith-Magee wrote: > This is fine, but it limits the logic that we (as a project) can put into > AdminConfig.ready(), because existing projects won't reference the new > AdminConfig. So, cleanups like putting admin.autoregister and

Re: Ticket #21751 review requested

On Friday 17 January 2014 01:19:29 Michael Manfre wrote: > In an effort to make Django a bit more explicit with regards to closing > cursors when they are no longer needed, I have created ticket #21751 [1] > with a pull request[2]. > > Most of the changes are straight forward and change the usage