Thanks for the comment. It will really help. I will try to address
wide variety of consequences of any change in the code in my proposal.
As for the last comment, it really brings up conflict as I was also
thinking yesterday. Firstly, my solution would be changing
importlib.import_module to have 3 parameters and naming a new instance
of foo.bar [in other words, (foo.bar, mayor)] application as
foo.bar.mayor. For example:
def import_module(name, package=None, clone=None)
...
if not clone None:
new_module = __import__(name.split('.')[-1], globals(),
locals(), ['models'], -1)
sys.modules[name] = new_module
return sys.modules[name]
...
Then, I thought that changing import_module is not necessary and
thought of importing the original app to the new instance in place,
like:
...
for app_name in settings.INSTALLED_APPS:
if (type(app_name) == types.TupleType):
a = app_name[0] + "." + app_name[1]
sys.modules[a] = __import__(app_namep[0])
...
not using sys.modules exactly, of course.
It would be the most straight-forward way without interrupting the
existing use of the current app loading mechanism.
On Wed, Apr 7, 2010 at 2:25 PM, Russell Keith-Magee
<freakboy3...@gmail.com> wrote:
> On Mon, Apr 5, 2010 at 4:11 PM, Dagvadorj Galbadrakh
> <dagvad...@gmail.com> wrote:
>> Hello group,
>>
>>
>>
>> I want to attend to this year's Google Summer of Code program with
>> "App loading". The following is a part from my proposal. It offers
>> more simplistic approach than heavily discussed one with App() in
>> INSTALLED_APPS, i.e., multiple instances of an app is declared as
>> ('foo.polls', 'mayor'). I'd appreciate any comments and feedbacks.
>
> I don't want to appear harsh, but there really isn't much to comment
> on here. You've given an example of how the code would look to end
> users, and some very shallow details of how that example would be
> interpreted, but almost no information on how this change would affect
> the rest of Django, or the complications that you anticipate.
>
> For example, the Wiki description of this problem lists 2 specific
> problems that you need to address. It's not clear to me that you've
> addressed either of these.
>
> It also fails to address the reasons why App loading is interesting in
> the first place - issues like translation of application names, and
> specification of application settings.
>
> The only detail that I can see that I can comment on is the process of
> name munging that you use to avoid collisions - and I can't say I like
> that very much at all.
>
> On a superficial level, I'm really not a fan of having a trailing
> underscore everywhere.
>
> On a more substantial level, you haven't provided any indication why
> this approach is necessary instead of simply allowing the end-user to
> specify the name that they want the application to be represented as
> -- that is, if I want to use the name gsoc_2009, then why not specify
> ('gsoc', 'gsoc_2009')? This leaves the flexibility in the hands of the
> end user, rather than embedded in a convention that I can guarantee
> *someone* will want to break out of.
>
> Plus, at the end of the day, it doesn't prevent name collisions, anyway:
> INSTALLED_APPS = (
> 'foo.gsoc_2009_',
> ('foo.gsoc', '2009'),
> )
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
Dagvadorj GALBADRAKH
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
