On Nov 17, 10:31 am, Jannis Leidel <[EMAIL PROTECTED]> wrote:
>
> Importing in the settings.py is effectively not required by any other
> part of Django.
Is importing in settings.py regarded generally as bad practice? If so,
I wasn't aware of this.
> What do you mean by "which you don't contro
On Nov 17, 11:20 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
>
> The InstalledAppsRevision wiki page. That was produced after the PyCon
> sprint. Since that involved a bunch of people, a number of them
> maintainers, I tend to view it as fairly canonical as to what is wanted
> in the feat
On Mon, 2008-11-17 at 02:24 -0800, Vinay Sajip wrote:
>
>
> On Nov 17, 1:13 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
> > My -1 is because of basically the same thing Jannis has pointed out (and
> > as I mentioned in my comment). There's a big ticket with various
> > proposals and at
>> Indeed, my idea though is to dodge imports in settings.py and just
>> use
>> dotted module names.
>
> I'm not sure why importing in settings.py is such a bad thing. Putting
> in dotted module names just moves the importing to somewhere else
> (which you don't control) and seems more 'magical'
On Nov 17, 1:13 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> My -1 is because of basically the same thing Jannis has pointed out (and
> as I mentioned in my comment). There's a big ticket with various
> proposals and at some point last year Adrian mentioned he had another
> idea and that
On Nov 17, 12:50 am, Jannis Leidel <[EMAIL PROTECTED]> wrote:
>
> The two -1 from core devs veto the feature for the next version, not
> the whole feature. We can go on discussing it here. I still hope they
> chime in though :)
>
I hope so too.
>
> Indeed, my idea though is to dodge imports in
On Mon, 2008-11-17 at 01:50 +0100, Jannis Leidel wrote:
> >>> If the basic premise of an app class - instances of which can
> >>> live in
> >>> settings.INSTALLED_APPS - is acceptable (and, of course, this means
> >>> instances of subclasses of app can live in settings.INSTALLED_APPS
> >>> too
>>> If the basic premise of an app class - instances of which can
>>> live in
>>> settings.INSTALLED_APPS - is acceptable (and, of course, this means
>>> instances of subclasses of app can live in settings.INSTALLED_APPS
>>> too) then the precise location of an implementation (e.g.
>>> django.c
On Nov 16, 7:48 pm, Jannis Leidel <[EMAIL PROTECTED]> wrote:
> >>> Well, what are those features you wanted, explicitly?
>
> There was a case for multiple instances of apps when it was discussed
> at the Pycon sprint and I just forgot it.
>
Ok - I'm not saying there's no case for it, just that
>>> Well, what are those features you wanted, explicitly?
>>
>> Mostly what has been written down
>> athttp://code.djangoproject.com/wiki/InstalledAppsRevision
>
> Thank you for your response. If you mean
>
>* Allow change of name of third-party app
>* Allow change of db_prefix of third-p
On Nov 15, 7:19 pm, Jannis Leidel <[EMAIL PROTECTED]> wrote:
> Thanks for bringing this topic up for discussion.
>
> > jezdez says: "As Jacob said, that's such a pain. I tried and wasn't
> > able to implement even part of the wanted features. The app cache
> > needs a thourough look. But I don't
On Nov 15, 6:57 pm, David Cramer <[EMAIL PROTECTED]> wrote:
> I personally was a 0 on this one. Let me explain why. I want Django to
> be a strong platform for developers, like myself, who really want the
> opportunity to have power in the framework, as well as features. As of
> lately I have be
Thanks for bringing this topic up for discussion.
> jezdez says: "As Jacob said, that's such a pain. I tried and wasn't
> able to implement even part of the wanted features. The app cache
> needs a thourough look. But I don't see installing apps multiple times
> as a favored feature. I will happi
I personally was a 0 on this one. Let me explain why. I want Django to
be a strong platform for developers, like myself, who really want the
opportunity to have power in the framework, as well as features. As of
lately I have been using Rails for a project, and to be quite honest,
the maturity and
I haven't looked at the patch yet, but I'd really like to be able to
change an app's name (and with it the names of the database tables),
which I thought was something that this proposal would include. So
fwiw, I personally would like to see it in 1.1.
Michael
--~--~-~--~~
On Nov 15, 12:27 pm, Vinay Sajip <[EMAIL PROTECTED]> wrote:
> Re. the recent post by Jacob Kaplan-Moss on Django 1.1 features and
> votes:
>
> ORM-23 gets a +1 from me. Jacob has given it a -0 and a comment "A
> huge can of worms. Some really awesome benefits come out of this, but
> so far every
Re. the recent post by Jacob Kaplan-Moss on Django 1.1 features and
votes:
ORM-23 gets a +1 from me. Jacob has given it a -0 and a comment "A
huge can of worms. Some really awesome benefits come out of this, but
so far everyone who's tried to make this work has failed. Until
there's an actual imp
17 matches
Mail list logo
