Re: [Visualpython-users] 5.11 version for 32 bit Ubuntu Jaunty (and some fixes)

[Gary R. <gr...@bi...>]

Guy K. Kloss wrote:
> On Tue, 30 Jun 2009 00:15:09 Gary Ruben wrote:
>> 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?
> 
> Since when is obfuscation helpful?

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.

> 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"
<snip>

Gary