Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

[C A. R. <an...@ex...>]

On Thu, Oct 7, 2010 at 5:26 PM, Bruce Sherwood <bas...@nc...> wrote:
> Okay, don't take it from me. See the postings on September 15 by James
> Mueller and Craig Struble who, like me, have extensive experience
> teaching novices to write small Python and/or VPython programs.
>
> If you're not convinced, that's fine, but I will say as clearly as I
> can: The current scheme will not be changed. That is simply not up for
> discussion.

My intent was not to convince nor offend you.  I presented a simple
rationale for how, in my opinion, imports being present are
_beneficial_.  As I said, you are still telling the students what is
available (though now they can't actually _see_ it!)... they don't
magically know what's available; so yeah, I guess I don't buy it, but
as you've alluded, my purchase is not necessary.

I have followed this list quietly for years, so I am aware of previous
threads.  The posts you've directed to are mostly devoid of content,
and ultimately recommend nearly the exact solution I proposed at the
beginning of the same thread.

> What is up for discussion is how best to accommodate the interests and
> needs of expert programmers, including those who on this mailing list
> have called for some scheme by which they can avoid importing stuff
> they don't want to import. I've offered several ways to address this
> need, and I'm asking for input on which scheme you think is best, on
> how best to document it, and what conventions should be encouraged
> (such as the scipy community settling on "import numpy as np").

Best?  The best solution is to provide a package that behaves as any
other quality pythonic/stdlib package; it is logically separated into
component modules, each piece can be cleanly imported, and you only
ever get what you ask for.  I (the developer) run the show here, and I
don't like my machine to do any more than I request.

Now, as established, this does not need to be provided by the "visual"
namespace; it could be "libvisual" (my preference), or "vpython", or
"vispy" or even "visual.strict", etc.  What I don't want, is needing
to remember special ways to import to avoid the pollution etc. etc.,
because the (top-level) package is making grand assumptions about how
it will be used... else I'll just keep doing "import visual" and wade
through that.

It is my strong opinion that convenience and shortcuts are second to
flexibility and interoperability.

There may even be a way to do some __all__ magic so that the "visual"
package can work both ways out-of-the-box, but I'm not sure.

> Please give me useful feedback on this! Maybe you're offended by the
> current behavior of "from visual import *" (or of "from pylab import
> *"; see http://www.scipy.org/PyLab), in which case you should't use
> it, but please don't waste time trying to convince me why it must be
> abolished, because it will stay.

No, not offended whatsoever.  The problem is that this entire
discussion is not really about "novice" vs. "expert" developers; the
real issue at hand is _how_ the package expects (assumes) the
developer will be using it.  Your students/novices/whatever are using
visual as a standalone tool, with next to nothing, if anything, else!
On the flip-side, those like me, use visual as a spectacular
component/library to much larger composite works, where visual may
play anywhere from lead role to background extra.  I think many want
to see it [visual] easy to embed, etc.  Who knows where it could end
up with a strong focus beyond the classroom.

So, please understand that we are all on the same side here; everyone
on this list has some investment in the project.  As much as
novices/niche users are annoyed by namespaces/explicit
directives/etc., integrators/experienced users are equally perturbed
by a seeming disinterest to learn and understand the proven guidelines
established by the community.

At any rate, visual is a wonderful tool; passions from any direction
only reaffirm the awe inspiring power of this package.  I'm confident
a good solution exists :-), and personally I like the matplotlib/pylab
(ie. libvisual/visual) route.

C Anthony