|
From: Craig S. <cra...@ma...> - 2010-09-16 01:35:30
|
I like Jim's example of matplotlib: a simple package (pylab) for some users, but more pythonic imports for python experts.
Jim's point of very novice users is important to me. We've used VPython to teach high school teachers from a variety of disciplines. The approach of
from visual import *
to include a wide range of useful classes, functions, etc. is a quick way to get the teachers (and hopefully their students) going. Computationally oriented people (e.g., engineers, computer scientists, mathematicians, etc.) are only a small portion of the audience I target.
It could be argued another tool is more appropriate, but the fact that Python scales well from small scripts for novices to large scientific computing applications for experts is very appealing.
So, with some effort, I think VPython can have it both ways. I believe it should.
Craig
On Sep 15, 2010, at 7:59 PM, Guy K. Kloss wrote:
> On Thu, 16 Sep 2010 11:42:30 James Mueller wrote:
>> I have to admit that I am a bit offended by the "physicist make
>> happy" comments. What is being referred to here are in general NOT
>> physicists.
>
> Sorry, no offence intended. But the "physicists" were just the ones commonly
> used here as a representative group of users that are not Computer Scientists.
>
> If this is a feature needed for this or similar groups, then that's fine. It
> would be just a huge shame if the visual package therefore would be spoiled
> for more users with more ambitious Python/programming knowledge.
>
>> Bruce's target audience is College Freshmen, (mainly future
>> engineers), who have never taken any programing course. Bruce wants to
>> allow them to investigate their course material visually, and uses the
>> python environment to do that. The concept of namespace is lost on
>> them. I know, as I am teaching some of them right now. In their
>> "computing for freshman engineers" course, they are currently learning
>> excel. Next term they plan to teach them Matlab. They don't know
>> variables; they don't know for or while loops; they don't know physics;
>> THEY DON'T KNOW ANYTHING! So don't call them physicists.
>
> Again, sorry for that, it was just the common nomination previously here.
>
> BTW, I'm an engineer myself (chemical engineer), and the concepts involved are
> not hard to understand. Python is also being taught to engineers at Auckland
> University (one of our PUG members teaches them), and they've got no problems
> to understand. After all, engineers are technical and logically thinking
> people, so they've got what it takes to think in systematic ways.
>
>> Other than that,
>> I agree with everything you said. What I would like to see is something
>> like matplotlib where they cleaned up the code but kept the pylab module
>> to preserve functionality. People who know what they are doing, might do
>>
>> import numpy as np
>> import matplotlib.pyplot as plt
>> import scipy
>>
>> etc. but one can also just do
>>
>> import pylab
>>
>> which ends up importing all sorts of things into the pylab namespace (I am
>> not sure how much). And again most people continue to use it as
>>
>> from pylab import *
>>
>> We can cringe, and tell them not to do it, but it was important that the
>> option was preserved. The matplotlib people provide the option but also
>> provide ways to do things properly. I see the same thing in this
>> case. If the code could be rearranged to have proper granularity and
>> allow people to use namspaces properly, that would be great! WE do not
>> need to use the "visual" name for that. Then "visual" can just be
>> something that imports everything to reproduce the current visual
>> namespace. We don't need to care as we can use the "correct" imports, as
>> long as they exist and are documented. From Bruce's mail, it seems like
>> the option is there to separate the namespaces. whether this is the
>> correct separation, I don't know, but seeing all the things visual
>> currently loads into one namespace is great. I can start to use things
>> properly. Most of my students will still "from visual import *", but I
>> have something to tell those who do know a little programming.
>
> My biggest issue with the current way visual handles things is, that it
> imports all kinds of non-visual related things from the math and numpy
> packages. And it would get even worse if things imported then are also being
> renamed ("from spam import eggs as seggs").
>
> Namespaces back and forth, certain things just shouldn't be pulled in by a
> base package named visual, that are completely unrelated.
>
>> As always, the devil is in the details, but I think this thread will
>> continue.
>
> Yes, indeed. And the issue can only be resolved if it's being discussed.
>
> Only with positive intentions,
>
> Guy
>
> --
> Guy K. Kloss
> Institute of Information and Mathematical Sciences
> Te Kura Pūtaiao o Mōhiohio me Pāngarau
> Massey University, Albany (North Shore City, Auckland)
> 473 State Highway 17, Gate 1, Mailroom, Quad B Building
> voice: +64 9 414-0800 ext. 9266 fax: +64 9 441-8181
> G....@ma... http://www.massey.ac.nz/~gkloss
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev_______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
--
Craig A. Struble, Ph.D. | Marquette University
Associate Professor of Computer Science | 369 Cudahy Hall
(414)288-3783 | (414)288-5472 (fax)
http://www.mscs.mu.edu/~cstruble | cra...@ma...
|