Auto-import support for models and other objects in shell

[Phill Tornroth]

'Ello.

I'm gauging support for a tiny new feature, or at least a refactoring of an internal API that will allow the feature to be developed without code duplication. I'd like to stop typing import statements for all of my models and other common stuff into my django shell. In fact, I'd love for all of us to stop typing those import statements! I tossed up the following pull requests as an example for how this might look:

https://github.com/django/django/pull/303

This is effectively a subset of the functionality that shell_plus [1] appears to provide. The problem that I have with building my own, or with using shell_plus is that the shell command doesn't allow this change to be built without effectively copying the entire internal implementation of the shell command. New features added to, or issues fixed in shell will have to be copied over to shell_plus, or our homegrown solutions which is unfortunate. So at the very least it seems reasonable to provide something like the get_initial_shell_locals method I added in my pull request, which makes this feature easy enough to add without duplication.

In fact, that's where my thinking started but I also don't see a downside to providing this functionality in core either. I don't think it's usefulness is particularly questionable or niche, as the existence of shell_plus seems evidence of.

I haven't opened a ticket because the contribution docs suggest gauging consensus, first. So I think these are the two potential (not mutually exclusive) changes worth gauging support for:

1. An overridable method (or some other internal API change?) to make it possible to implement this functionality without copying the entire shell implementation.

2. A default implementation for said method that supports auto-importing useful objects into the shell scope.

Curious to hear what people think. Of course, please let me know if I'm going about this the wrong way.

Thanks!

Phill

[1]: https://github.com/django-extensions/django-extensions/blob/master/django_extensions/management/commands/shell_plus.py

[Alex Gaynor]

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/gcpo73Sk5aMJ.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

I'm pretty strongly -1 on this. I understand it can be a real convenience, but this is precisely the type of feature that makes things way more confusing for anyone who's new to a project, "Why are the things magically available here?". I realize this is "just" the shell, but I've been very critical of other frameworks for making things magically available, and I'm going to hold us to the same standard.

Alex

--
"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

[Phill Tornroth]

Totally fair, couple of things:

1. For backward compatibility and the confusion you mentioned, I'd suggest this be not enabled by default. Let people who want the feature (the people who download shell_plus for instance) enable it. My pull request leaves it totally off by default, retaining current behavior. In my opinion this removes the 'magically available' argument. The classes would be as magically available as context vars in templates are.

2. Are you also -1 on making it easier for projects like shell_plus to add locals to the shell? What's happening right now is pretty unfortunate. I can only see upside in an adjustment to the internal API that doesn't make this kind of duplication necessary.

Thanks for reading.

Phill

[Carl Meyer]

Hi Phill,

On 08/28/2012 03:51 PM, Phill Tornroth wrote:
> 2. Are you also -1 on making it easier for projects like shell_plus to
> add locals to the shell? What's happening right now is pretty
> unfortunate. I can only see upside in an adjustment to the internal API
> that doesn't make this kind of duplication necessary.

I think this is a practically useful feature, but it's pretty far afield
for a web framework, IMO [1]. Ideally it could be handled by convenience
shells such as IPython without needing to add anything new to "manage.py
shell". I know that in older versions of IPython auto-imports could be
easily done with an ipy_user_conf.py file in the same directory as
manage.py; since "manage.py shell" runs IPython if installed, that
solves the problem. I think the customization system has changed in
newer IPython versions and I haven't looked into how to do it now - but
that still seems to me like basically the right approach.

Carl



[1] Of course, the same could be said for "manage.py shell" itself,
which, in Django 1.4 at least, is little more than a shortcut for
setting DJANGO_SETTINGS_MODULE and running a python shell. I'd love to
see "manage.py shell" disappear entirely from Django someday.

[Russell Keith-Magee]

I'm in complete agreement with Alex. -1 from me. Explicit is better
than implicit, and to my mind, hiding imports just complicates the
learning curve associated with Django's package tree.

If you *really* want this, there are hooks into ipython et al that can
do this; I don't see it as something appropriate for Django itself.

Yours,
Russ Magee %-)

[Phill Tornroth]

Thanks all. This has been a helpful and enlightening glimpse into the values and priorities the Django project is stewarded with.

I appreciate the time and attention.

-Phill