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
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
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
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
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
> >>>
>>> 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.
>>>
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
>>> 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
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
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
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
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
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
15 matches
Mail list logo
