Menu
▾
▴
Re: [Visualpython-users] 5.11 version for 32 bit Ubuntu Jaunty (and some fixes)
|
From: Bruce S. <Bru...@nc...> - 2009-06-30 17:12:55
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Thanks for the elegant commentary, Craig. Because I too work with large
numbers of naive users, in particular including teachers and students,
this is precisely my concern and experience as well, but you've said it
better than I could.<br>
<br>
At the same time, we want Visual to be useful to and usable by power
users, and I'm glad that Guy Kloss has raised the issues, and happy to
see the constructive discussions that are under way. Your choice of
"visual.core" is exactly the same name that Dave Scherer, the
originator of Visual, suggested when I talked recently with him about
these issues. He too is in favor of cleaning the space, but with
caution. One possible approach is to import very few essential things
from the very large numpy module, but probably all of the much smaller
math module (though even there one should look carefully); the point of
including the math module is that you can hardly do anything with
Visual without sines and cosines and square roots. He also suggested a
factoring that would include "visual.math" (which would perform the
magic needed to get good performance out of choosing the math sqrt
instead of the numpy sqrt when possible).<br>
<br>
I'm strongly against eliminating numpy from the Windows and Mac
installers. We found experimentally that even college students majoring
in engineering and science fairly frequently have difficulties with a
two-part installation (Python and Visual), and there have been serious
questions about the advisability of a one-part installer for novices. A
three-part installation would be 50% worse than the current situation.
Linux is a different beast, and there the dependencies can be taken
care of by the package manager, if someone makes a Visual package for a
particular distribution.<br>
<br>
I'll mention that you'll see in __init__.py the following:<br>
# Names defined for backward compatibility with Visual 3:<br>
import sys, time<br>
true = True<br>
false = False<br>
We shouldn't be importing sys and time; the last time this issue was
visited, there were fears of introducing incompatibilities, but I'm not
sure how valid those particular fears were.<br>
<br>
Bruce Sherwood<br>
<br>
Craig Struble wrote:
<blockquote
cite="mid:C43...@ma..."
type="cite">
<pre wrap="">I want to echo Bruce's request for careful thought in this process.
Changing the API to be more Pythonesque and changing the distribution
to using a more ideal dependency structure may have certain aesthetic
and large scale advantages, but I fear they would be hurdles that
would prevent larger adoption.
Having just taught a 3-day workshop on computational thinking using
Python and VPython to high school science teachers, who have never
used Python or VPython before, the current simple to use import
behavior was essential to getting them to begin writing their own
simulations in a short period of time. Our goal was to have the
teachers focus on the science they wanted to teach, not to master
Python's language or namespaces. Every additional line of code needed
to get a simple simulation running is a very large penalty to many
users.
My main point is that there needs to be an option in the mix that
maintains the simplicity both in imports and in distribution. I also
thought, as a Gary suggested, that a namespace such as
from visual.core import *
(instead of visual.visual, which is a confusing name) would be a
reasonable transition from the current behavior to something more in
line with good Python practice. So
from visual import *
could import everything into a single namespace and let the other
modules be better suited for developers needing more control. The
visual.graph module would probably need some refactoring to act more
like a proper Python module that doesn't pollute namespaces, but then
there would be more consistency in behavior. (The current behavior of
visual.graph is a little confusing to explain.) Gary's other
suggestion about visual.all is also reasonable.
Craig
On Jun 30, 2009, at 8:07 AM, Gary Ruben wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Guy K. Kloss wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Tue, 30 Jun 2009 00:15:09 Gary Ruben wrote:
</pre>
<blockquote type="cite">
<pre wrap="">would
adding another namespace within visual provide the best of both
worlds -
that way one might do something like
"from visual.visual import *"
instead of "from visual import *"
if you just want the visual module without the other imports?
</pre>
</blockquote>
<pre wrap="">Since when is obfuscation helpful?
</pre>
</blockquote>
<pre wrap="">OK, I don't deny that this is probably not the best idea.
I should clarify myself. Personally, I would be more than happy for
vpython to be changed to remove the wholesale namespace importation -
this would be a forward step. I think what you propose is a good
course
of action. However, since Bruce suggested that there is careful
thought
behind the current operation, I'm just wondering whether Python
permits
you to *not* do this via an admittedly less-than-ideal mechanism like
that which I suggested. Alternatively, not knowing the full thinking
behind the current behaviour, what do you think of following through
with your suggestion for 6.x, and maybe providing a subordinate
namespace (dare I say like visual.visual or visual.all) that does the
full environment setup, presumably to simplify use of vpython in a
teaching environment.
While I'm at it, I'd like to see numpy removed completely from the
installer - I think it's mature enough and a slow enough moving target
to be made a dependency instead.
</pre>
<blockquote type="cite">
<pre wrap="">BTW, I am *not* intending to aim at breaking compatibility for the
5.x release
series. I am aiming at hinting towards refining the API for maybe a
future 6.x
series. And I am intending to hint towards that in the spirit of
Python, which
is well established and it is what made the language as popular as
it is
today. These suggestions go fully conform with "The Zen of
Python" (see below,
you get it when typing "import this" in the interactive Python
shell).
In my opinion a refinement of the API in that direction for future
release
series would already touch 5 of the Zen of Python statements, and
therefore
largely serve the usability in Python at the little expense of
having to adapt
with the switch over from 5.x to 6.0"
</pre>
</blockquote>
<pre wrap=""><snip>
Gary
------------------------------------------------------------------------------
_______________________________________________
Visualpython-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Vis...@li...">Vis...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/visualpython-users">https://lists.sourceforge.net/lists/listinfo/visualpython-users</a>
</pre>
</blockquote>
<pre wrap=""><!---->
--
Craig A. Struble, Ph.D. | 369 Cudahy Hall | Marquette University
Associate Professor of Computer Science | (414)288-3783
Director, Master of Bioinformatics Program | (414)288-5472 (fax)
<a class="moz-txt-link-freetext" href="http://www.mscs.mu.edu/~cstruble">http://www.mscs.mu.edu/~cstruble</a> | <a class="moz-txt-link-abbreviated" href="mailto:cra...@ma...">cra...@ma...</a>
------------------------------------------------------------------------------
_______________________________________________
Visualpython-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Vis...@li...">Vis...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/visualpython-users">https://lists.sourceforge.net/lists/listinfo/visualpython-users</a>
</pre>
</blockquote>
</body>
</html>
|
