Re: Various small issues

On Tue, Feb 1, 2011 at 11:45 AM, Brian Neal wrote: > On Jan 31, 7:35 pm, Russell Keith-Magee > wrote: >> >> The core team aren't the only people who can review tickets. In fact, >> all you need is for someone who isn't you to review your ticket and >>

Re: Pluggable models

On Tue, Feb 1, 2011 at 9:22 AM, David Greisen wrote: > Dear List, > > This is my first time writing to the list. I've been working with Django for > the last two years and recently started hacking on Django itself. > > For a while I have felt restricted by the fact that I

Re: Various small issues

On Jan 31, 7:35 pm, Russell Keith-Magee wrote: > > The core team aren't the only people who can review tickets. In fact, > all you need is for someone who isn't you to review your ticket and > say that it looks good (by Django's standards -- which means > documentation,

Pluggable models

Dear List, This is my first time writing to the list. I've been working with Django for the last two years and recently started hacking on Django itself. For a while I have felt restricted by the fact that I cannot replace the user model. I use the profile feature for additional methods and

Re: settings.py should have way to hide key/values even when debug set True

Second. On Tue, Feb 1, 2011 at 1:00 AM, Russell Keith-Magee wrote: > On Tue, Feb 1, 2011 at 12:12 AM, Horst Gutmann > wrote: > > On Mon, Jan 31, 2011 at 5:02 PM, Matteius wrote: > >> I think it would be really useful to have a

Re: Various small issues

On Tue, Feb 1, 2011 at 7:47 AM, Stephen Kelly wrote: > Klaas van Schelven wrote: > >> Hi all, >> >> Maybe I wasn't clear enough last time... I've provided patches for >> both these old problems and would appreciate either a brutal Linus >> style rant for being such an idiot or

Re: settings.py should have way to hide key/values even when debug set True

On Tue, Feb 1, 2011 at 12:12 AM, Horst Gutmann wrote: > On Mon, Jan 31, 2011 at 5:02 PM, Matteius wrote: >> I think it would be really useful to have a way (possibly a decorator >> such as @hide_setting) such as to protect deployed sites when they >>

Re: Various small issues

Klaas van Schelven wrote: > Hi all, > > Maybe I wasn't clear enough last time... I've provided patches for > both these old problems and would appreciate either a brutal Linus > style rant for being such an idiot or would like to see the patches > applied. Silence... not so much. > Hi Klass,

Re: Various small issues

Hi all, Maybe I wasn't clear enough last time... I've provided patches for both these old problems and would appreciate either a brutal Linus style rant for being such an idiot or would like to see the patches applied. Silence... not so much. ciao, Klaas On Jan 14, 6:28 pm, Klaas van Schelven

Re: One Django instance, hundreds of websites

On Jan 31, 8:27 pm, Carl Meyer wrote: > On Jan 31, 1:49 am, Xavier Ordoquy wrote: > > > The thread is pretty long because there are also 2 threads in one: > >  - one for simply changing the site_id per request > >  - one for changing the all setting

Re: Discussion about language discovery - ticket 15168

What you are proposing is too idiosyncratic to be part of the Django framework. As already suggested by others it should be trivial enough to create your own middleware to address your needs: if language preference not specified explicitly by the user: set it to the language of your choice

Discussion about language discovery - ticket 15168

You see things from your point of view, so lets give it one more shot: 1) Browsers/Op? systems are not available in many small languages and therefore the speakers of languages like estonians have to use browsers/systems in english and their browsers are therefore in english - they may not desire

Re: One Django instance, hundreds of websites

On Jan 31, 1:49 am, Xavier Ordoquy wrote: > The thread is pretty long because there are also 2 threads in one: >  - one for simply changing the site_id per request >  - one for changing the all setting per request Exactly! For the record, as far as I'm concerned #15089 is

Re: ANN: Server upgrade on djangoproject.com

Since you're installing directly from SVN, you'll need to preface the URL with "svn+". Just 20 minutes ago I successfully did a pip install using the following command: pip install svn+http://code.djangoproject.com/svn/django/trunk/#egg=django Chuck On Monday, January 31, 2011 at 12:57 PM,

Re: ANN: Server upgrade on djangoproject.com

I don't know if it's related to this server upgrade, but I can't install django from svn with pip anymore [1]. However, it's still working with easy_install. [1] I'm using: pip install http://code.djangoproject.com/svn/django/trunk Pip error log on http://dpaste.com/371850/ Thanks --

Re: settings.py should have way to hide key/values even when debug set True

On Mon, Jan 31, 2011 at 5:02 PM, Matteius wrote: > I think it would be really useful to have a way (possibly a decorator > such as @hide_setting) such as to protect deployed sites when they > switch over to debug mode.  To me this would be a most useful setting > to have,

settings.py should have way to hide key/values even when debug set True

I think it would be really useful to have a way (possibly a decorator such as @hide_setting) such as to protect deployed sites when they switch over to debug mode. To me this would be a most useful setting to have, especially when protecting secret key settings. Please be advised. -- You

Using OneToOneField in reverse from values or values_list is rejected with "Invalid field name"

Working on some code I've hit that the reverse name for a OneToOneField cannot be used, it seems, in values_list or values. I couldn't see why there would need to be such an exclusion, given it is a one-to-one relationship, so am wondering if it's just an oversight in the code or a deliberate

Re: RFC: Add a "needinfo" state to triaging

On Wed, Nov 17, 2010 at 10:49 AM, Russell Keith-Magee wrote: > On Wed, Nov 17, 2010 at 9:22 PM, Gabriel Hurley wrote: >> Bear in mind that this is a *very* old Trac installation... ;-) > > Hopefully not for long. > > Jacob is in the process of bringing

Re: Question on ForeignKey (on_delete=DO_NOTHING)

Carl, you are right. I didn't mention the actual problem i was facing... Prior to 1.3 the way we implemented 'sqlflush' was to simply turn on 'cascade_delete' in DB2 and then return 'delete from TABLENAME' for every table passed in. Without the delete_cascade, this required the delete's to be

Re: One Django instance, hundreds of websites

On Jan 31, 8:30 am, James Hancock wrote: > This post is getting pretty long. But I had a simple Django fix that would > make it work a lot easier for me, and might help others. (I say this because > of how I implemented it, I am working with about 60 different sites and it >