Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

For lots of reasons (including existing documentation and programs,
not restricted to the documentation and programs that come with
VPython), unless there are extremely strong arguments to justify a
change, I want to leave "from visual import *" in place, a "batteries
included" environment (also a pythonic concept). But I'm happy to
introduce a new way to import visual that is restrictive. I'm
certainly not tied to the little experiment I've just carried out. As
you say, perhaps my little file should be split into separate pieces.

Bruce SherwoodOn Wed, Sep 15, 2010 at 11:22 AM, C Anthony Risinger
<an...@ex...> wrote:
> On Wed, Sep 15, 2010 at 11:51 AM, Bruce Sherwood <bas...@nc...> wrote:
>> A colleague points out that visual.basic (Visual Basic) maybe isn't
>> the most intelligent nomenclature....
>>
>> So if this idea has merit, there is at least the question of what the
>> file should really be named.
>
> My thought was to create a dedicated namespace/module, for these
> "specialized" environments; something like:
>
> visual.framework.physics
> visual.framework.<insert here>
>
> this would open the door for other special interest groups, if any, to
> create there own modules that import whatever they want to create a
> base environment for the novices in their particular field.
>
> additionally...
>
> from visual.framework.physics import *
>
> is still a pretty easy one-liner.  Relating to your "basic.py"
> example, my preference would be that everything exist in it's own
> module, example:
>
> from visual.vector import mag, mag2, ..., ...
>
> I see that primitives/ui/materials/etc. (from your example) seem to
> already be nicely broken up.  I'm not very familiar with visual
> internally, having only used it in projects.  In short, I guess I'm
> just the kind of developer that likes everything to be explicitly
> included, and nothing else, but that's just me :-).
>
> At any rate, visual is a great tool, and I would like to see it become
> flexible enough for embedding, and any other use cases; great stuff.
>
> C Anthony