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

[James M. <mu...@pi...>]

As an example, matplotlib has already done something like this.  The  
old syntax was

from pylab import *

which also imported numpy, resulting in a very polluted namespace.   
They now suggest

from matplotlib import pyplot as plt

which deals with namespaces in a much more sensible way.  They also re- 
implemented the pylab import such that it consists of an import of  
pyplot and numpy, so old code (and coders) can have their old code  
work as it did before.

  -Jim

On Jun 30, 2009, at 9:07 AM, Gary Ruben wrote:

> 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
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users