visualpython-users

[Visualpython-users] Question about mouse event in vPython

[Moster M. <mos...@ho...>]

How to handle mouse click event when clicking on the composite object?

Thank you


 
Best regards,
 
Sukrit Manokhatiphaisan
Master degree student of
Institute of FIeld roBOtics(FIBO)
King Mongkut's University of Technology Thonburi
Administrator of
Hubei Jingshan Light Industrial Machinery (Thailand) Co.,Ltd

Email: mos...@ho..., mos...@gm...
Tel: 085-988-8628
   
 


<< Confidential Note >> 
 
If  you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others.  This e-mail message (including any attachment) is intended only for the individual(s) or entity named above and others who have been specifically authorized to receive it.  Please notify the sender that you have received this email in error by replying to the email. Please then delete the email and any copies of it. This information may be confidential and be subject to other privilege or any other immunity. 

 		 	   		  

Re: [Visualpython-users] Experimental clean import capability

[Bruce S. <bas...@nc...>]

Thanks to some public and private support for the "vis" as the name of
the clean module, I've remade the clean+convenience version to be in
two site-packages folders named visual (convenience, backward
compatibility) and vis (clean, no extra imports). You can get these
materials from the "For developers" section of vpython.org. They
should work with either Python 2.x or Python 3.1.

It is very important to read the README file before installing. In
particular, you need to save a copy of the old visual folder before
installing.

I hope some people will try this out before I'm tempted to post
VPython 5.4 with these new features.

Bruce Sherwood

Re: [Visualpython-users] Experimental clean import capability

[Bruce S. <bas...@nc...>]

Correction: This stuff does work with Python 3.1, but I haven't yet
made available the binaries of the C++ component; you have to use the
cvisual file that you already have.

Bruce Sherwood

On Tue, Oct 12, 2010 at 8:42 PM, Bruce Sherwood <bas...@nc...> wrote:
> Thanks to some public and private support for the "vis" as the name of
> the clean module, I've remade the clean+convenience version to be in
> two site-packages folders named visual (convenience, backward
> compatibility) and vis (clean, no extra imports). You can get these
> materials from the "For developers" section of vpython.org. They
> should work with either Python 2.x or Python 3.1.
>
> It is very important to read the README file before installing. In
> particular, you need to save a copy of the old visual folder before
> installing.
>
> I hope some people will try this out before I'm tempted to post
> VPython 5.4 with these new features.
>
> Bruce Sherwood
>

Re: [Visualpython-users] Experimental clean import capability

[Craig S. <cra...@ma...>]

I'm fine with that too, and it's even shorter, which I like more. :-)

    Craig

On Oct 11, 2010, at 2:19 PM, Bruce Sherwood wrote:

> Suppose the clean folder is named simply vis? There does not seem to
> exist a Python module named vis. It's short, which is nice for those
> who prefer to use the full name, as in vis.box(), and by its shortness
> it has the flavor of "visual but without the extras imported by
> visual". It's similar to your first choice but without the py, which
> seems a bit superfluous in the Python environment. And on the other
> hand, if someone starts a new project dealing with visualization
> they're more likely to call it vispy than vis, because of tradition
> (scipy, numpy, etc.).
> 
> Whaddya think?
> 
> I hope that some people other than me actually try out the machinery I
> posted and say whether in fact it satisfies their needs.
> 
> Bruce Sherwood
> 
> On Mon, Oct 11, 2010 at 8:31 AM, Craig Struble
> <cra...@ma...> wrote:
>> I don't like visual_parts at all. Too long and is unlike just about every other Python module out there. If vpython is off the table, I'd prefer the names in the order of 1) vispy, 2) visualpy, 3) vislib, 4) visuallib, 5) libvis, 6) libvisual.
> 
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> 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...

Re: [Visualpython-users] Experimental clean import capability

[Bruce S. <bas...@nc...>]

Suppose the clean folder is named simply vis? There does not seem to
exist a Python module named vis. It's short, which is nice for those
who prefer to use the full name, as in vis.box(), and by its shortness
it has the flavor of "visual but without the extras imported by
visual". It's similar to your first choice but without the py, which
seems a bit superfluous in the Python environment. And on the other
hand, if someone starts a new project dealing with visualization
they're more likely to call it vispy than vis, because of tradition
(scipy, numpy, etc.).

Whaddya think?

I hope that some people other than me actually try out the machinery I
posted and say whether in fact it satisfies their needs.

Bruce Sherwood

On Mon, Oct 11, 2010 at 8:31 AM, Craig Struble
<cra...@ma...> wrote:
> I don't like visual_parts at all. Too long and is unlike just about every other Python module out there. If vpython is off the table, I'd prefer the names in the order of 1) vispy, 2) visualpy, 3) vislib, 4) visuallib, 5) libvis, 6) libvisual.

Re: [Visualpython-users] Experimental clean import capability

[Anton S. <br...@po...>]

On 2010-10-10 12:51, Bruce Sherwood wrote:
> [...]  You're invited to suggest a better name.

I always said VP ought to be named Gilliam.

-- 
Anton Sherwood *\\* www.ogre.nu

Re: [Visualpython-users] Experimental clean import capability

[Craig S. <cra...@ma...>]

I don't like visual_parts at all. Too long and is unlike just about every other Python module out there. If vpython is off the table, I'd prefer the names in the order of 1) vispy, 2) visualpy, 3) vislib, 4) visuallib, 5) libvis, 6) libvisual.

The other discussions over the weekend seemed to converge to a good solution: a clean implementation in the newly named space, and a visual module that imports from the clean implementation to avoid code duplication. It's unfortunate a visual.py solution can't be made to work, but visual/__init.py__ isn't too bad.

    Craig

On Oct 10, 2010, at 2:51 PM, Bruce Sherwood wrote:

> A colleague correctly points out that "vpython" isn't an appropriate
> name for the other module, because of confusion with the cover term
> (VPython = Visual+Python). A better name might be for example
> visual_parts; note that whatever the name is, presumably it will get
> imported with a short name (much as the scipy world settled on import
> numpy as np). You're invited to suggest a better name.
> 
> Bruce Sherwood
> 
> On Sat, Oct 9, 2010 at 10:11 PM, Bruce Sherwood <bas...@nc...> wrote:
>> In the "For developers" section of vpython.org is a zip file
>> containing experimental code for doing either the convenient "from
>> visual import *" or a clean "import vpython". Please try this out and
>> post comments about whether this would meet your needs, or how it
>> should be changed, or offer a different scheme entirely. Once we reach
>> agreement, this will become a part of VPython 5.4 for Python 2.7 and
>> Python 3.1.
>> 
>> I was able to follow the suggestion to put almost everything in the
>> new vpython folder, so that the visual folder mostly just imports from
>> the vpython folder. I thought it might be possible, and clean, to put
>> the two modules inside one folder, but that doesn't work. I'm very
>> hazy on how the import search works. If you see a way to have one
>> folder rather than two, please explain.
>> 
>> As far as I can tell from my tests, there is complete backward
>> compatibility with existing programs.
>> 
>> Bruce Sherwood
>> 
>> -----------------------------------------------------------------------------
>> 
>> Here are the installation instructions in the accompanying README file:
>> 
>> 1) Before making any changes to your current site-packages, make a copy of
>> 
>>     site-packages/visual
>> 
>> 2) Replace site-packages/visual with the visual folder in this package.
>> 
>> 3) Add to site-packages the vpython folder in this package.
>> 
>> 4) From your saved copy of site-packages/visual, copy into the new
>> vpython folder
>> 
>>     cvisual.pyd (Windows) or
>>     cvisual.so (Mac)
>> 
>> 5) On Windows, from your saved copy of site-packages/visual, copy the doc and
>>   examples folders into the new visual folder.
>> 
>> After making these changes, you can still use "from visual import *" if that is
>> convenient, but if you want to import the visual objects cleanly, import them
>> from the new vpython module. Here are two simple examples:
>> 
>> import vpython as vp
>> vp.box(color=vp.color.orange, material=vp.materials.wood)
>> 
>> from vpython import (box, color, materials)
>> box(color=color.orange, material=materials.wood)
>> 
>> There are new clean modules vpython.controls, vpython.filedialog, and
>> vpython.graph
>> that can be used instead of the old modules visual.controls,
>> visual.filedialog, and
>> visual.graph. The old modules execute "from visual import *" and are
>> retained because
>> some programs expect that behavior when importing one of these modules.
>> 
> 
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> 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...

Re: [Visualpython-users] Experimental clean import capability

[C A. R. <an...@ex...>]

On Sun, Oct 10, 2010 at 5:19 PM, C Anthony Risinger <an...@ex...> wrote:
>
> But if vpython really cannot work, I still like either visualpy,

Oops, I meant vispy here :-)

C Anthony

Re: [Visualpython-users] Experimental clean import capability

[C A. R. <an...@ex...>]

On Sun, Oct 10, 2010 at 2:51 PM, Bruce Sherwood <bas...@nc...> wrote:
> On Sat, Oct 9, 2010 at 10:11 PM, Bruce Sherwood <bas...@nc...> wrote:
>> In the "For developers" section of vpython.org is a zip file
>> containing experimental code for doing either the convenient "from
>> visual import *" or a clean "import vpython". Please try this out and
>> post comments about whether this would meet your needs, or how it
>> should be changed, or offer a different scheme entirely. Once we reach
>> agreement, this will become a part of VPython 5.4 for Python 2.7 and
>> Python 3.1.

Perfect, will take a look.

>> I was able to follow the suggestion to put almost everything in the
>> new vpython folder, so that the visual folder mostly just imports from
>> the vpython folder. I thought it might be possible, and clean, to put
>> the two modules inside one folder, but that doesn't work. I'm very
>> hazy on how the import search works. If you see a way to have one
>> folder rather than two, please explain.

I personally think two folders/modules is desirable.  The only way I
think there should be one, is if the "visual" namespace can be used
for the pythonic module, and something else (ie. visual.physics, etc.)
used for the wildcard module ;-)

>> As far as I can tell from my tests, there is complete backward
>> compatibility with existing programs.
>>
>> Bruce Sherwood
>
> A colleague correctly points out that "vpython" isn't an appropriate
> name for the other module, because of confusion with the cover term
> (VPython = Visual+Python).

I don't understand what you mean here, what's the issue exactly?

> A better name might be for example
> visual_parts;

This particular name makes the proper module seem more like a second
class citizen.  IMO, the clean module _is_ vpython... the "visual"
module is not.

> note that whatever the name is, presumably it will get
> imported with a short name (much as the scipy world settled on import
> numpy as np). You're invited to suggest a better name.

I might be alone here, but I rarely use a different name for imports,
unless there will be conflict, but i like everything to be explicit...
I don't like to have to look it up when i read the code later.

But if vpython really cannot work, I still like either visualpy,
visuallib, or maybe even pyvisual/visualpy.

C Anthony

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

[C A. R. <an...@ex...>]

On Sun, Oct 10, 2010 at 3:01 PM, Bruce Sherwood <bas...@nc...> wrote:
> Maybe I'm using the word "relative" incorrectly. I'll try to be more clear:
>
> Suppose in the site-packages/visual folder the file __init__.py has
> "from visual.ui import display". That's clearly an absolute import;
> the full path visual.ui is given.
>
> In the past, you could instead say "from ui import display", and this
> was called a "relative" import. It had the problem of ambiguity with
> some possible module named ui, outside the visual module, and so this
> form was deprecated (and I think maybe it won't even work in Python
> 3).
>
> Though I only became aware of this recently, since at least Python 2.6
> you can say "from .ui import display", where the dot makes this an
> absolute import, with the dot standing for "visual.". In this
> conversation I incorrectly called the dot form a "relative" import,
> because it is relative to the current directory. But it is really an
> absolute import, one that has the advantage that changing the name of
> the surrounding directory doesn't require any changes to the files.

No, you are using it correctly:

http://www.python.org/dev/peps/pep-0328/#guido-s-decision

The syntax was introduced to remove the ambiguity, because the old
form was being removed at the same time.  It's still a relative
import, since the meaning of the import can change as folders are
shuffled around.

C Anthony

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

[Bruce S. <bas...@nc...>]

Maybe I'm using the word "relative" incorrectly. I'll try to be more clear:

Suppose in the site-packages/visual folder the file __init__.py has
"from visual.ui import display". That's clearly an absolute import;
the full path visual.ui is given.

In the past, you could instead say "from ui import display", and this
was called a "relative" import. It had the problem of ambiguity with
some possible module named ui, outside the visual module, and so this
form was deprecated (and I think maybe it won't even work in Python
3).

Though I only became aware of this recently, since at least Python 2.6
you can say "from .ui import display", where the dot makes this an
absolute import, with the dot standing for "visual.". In this
conversation I incorrectly called the dot form a "relative" import,
because it is relative to the current directory. But it is really an
absolute import, one that has the advantage that changing the name of
the surrounding directory doesn't require any changes to the files.

Bruce Sherwood

On Sat, Oct 9, 2010 at 9:08 AM, Bruce Sherwood <bas...@nc...> wrote:
> I had read those same documents about imports and reached the opposite
> conclusions!
>
> The full context in your reference [1] is this:
>
> "Never use relative package imports. If you’re writing code that’s in
> the package.sub.m1 module and want to import package.sub.m2, do not
> just write import m2, even though it’s legal. Write from package.sub
> import m2 instead. Relative imports can lead to a module being
> initialized twice, leading to confusing bugs. See PEP 328 for
> details."
>
> By "relative import" here they mean "import m2" inside a package,
> which has the danger of importing some module named m2 that is outside
> the package. As I read the documents, the new dot notation is designed
> to make it possible for packages to be real packages, which can even
> be moved to a different folder and still work under the new package
> name.
>
> An example of the power of the dot notation is that for Python 3 I was
> able to make experimental versions of IDLE and VIDLE that except for
> one single very special statement don't refer to either "idlelib" or
> "vidle" and have mostly the same code inside the idlelib or vidle
> folder.
>
> If I've fundamentally misunderstood the point, perhaps a very specific
> example would help me see the error of my ways.
>
> Bruce Sherwood
>
> On Fri, Oct 8, 2010 at 5:05 PM, Guy K. Kloss <g....@ma...> wrote:
>> On Sat, 09 Oct 2010 10:44:29 Bruce Sherwood wrote:
>>> This proposal assumed that the "libvisual" file was in the visual
>>> folder, in which case I thought that relative imports were now
>>> favored, for various reasons. As I understand it, the main issue is
>>> that there could be a module named "foo" at a higher level in the
>>> search path, in which case "import foo" might not pick up our foo, but
>>> someone else's foo. Have I misunderstood something?
>>
>> Well, not really. It's just that the use of relative imports is mainly
>> intended for corner cases, but it's discouraged to be used on a general basis.
>> Of course, things could break if there's a clash between two "foo" modules.
>> This is called "shadowing". One common case is for example when people call a
>> variable "file" and therefore are shadowing the built-in "file" type.
>>
>> In other cases, this behaviour is exactly desired, so for example when people
>> *want* to use a specific implementation as a drop-in replacement for an
>> otherwise used package. This is for example quite common with the XML parser
>> through the ElementTree API. Many APIs are designed to be compatible with each
>> other, another one of those are the ones of the threading/processing modules.
>> So a user can choose which one to use (for various reasons).
>>
>> So what it boils down to is to commonly use absolute imports rather than
>> relative ones, unless something demands a relative import for specific
>> reasons. From the Python documentation [1]: "Relative imports can lead to a
>> module being initialized twice, leading to confusing bugs. See PEP 328 [2] for
>> details."
>>
>> You can read up more on this and related issues more on [1], [2] and [3].
>>
>> Guy
>>
>>
>> [1] http://docs.python.org/faq/programming.html#what-are-the-best-practices-
>> for-using-import-in-a-module
>>
>> [2] http://docs.python.org/release/2.5/whatsnew/pep-328.html
>>
>> [3] http://bugs.python.org/issue10031
>>
>> Guy
>>
>

Re: [Visualpython-users] Experimental clean import capability

[Bruce S. <bas...@nc...>]

A colleague correctly points out that "vpython" isn't an appropriate
name for the other module, because of confusion with the cover term
(VPython = Visual+Python). A better name might be for example
visual_parts; note that whatever the name is, presumably it will get
imported with a short name (much as the scipy world settled on import
numpy as np). You're invited to suggest a better name.

Bruce Sherwood

On Sat, Oct 9, 2010 at 10:11 PM, Bruce Sherwood <bas...@nc...> wrote:
> In the "For developers" section of vpython.org is a zip file
> containing experimental code for doing either the convenient "from
> visual import *" or a clean "import vpython". Please try this out and
> post comments about whether this would meet your needs, or how it
> should be changed, or offer a different scheme entirely. Once we reach
> agreement, this will become a part of VPython 5.4 for Python 2.7 and
> Python 3.1.
>
> I was able to follow the suggestion to put almost everything in the
> new vpython folder, so that the visual folder mostly just imports from
> the vpython folder. I thought it might be possible, and clean, to put
> the two modules inside one folder, but that doesn't work. I'm very
> hazy on how the import search works. If you see a way to have one
> folder rather than two, please explain.
>
> As far as I can tell from my tests, there is complete backward
> compatibility with existing programs.
>
> Bruce Sherwood
>
> -----------------------------------------------------------------------------
>
> Here are the installation instructions in the accompanying README file:
>
> 1) Before making any changes to your current site-packages, make a copy of
>
>     site-packages/visual
>
> 2) Replace site-packages/visual with the visual folder in this package.
>
> 3) Add to site-packages the vpython folder in this package.
>
> 4) From your saved copy of site-packages/visual, copy into the new
> vpython folder
>
>     cvisual.pyd (Windows) or
>     cvisual.so (Mac)
>
> 5) On Windows, from your saved copy of site-packages/visual, copy the doc and
>   examples folders into the new visual folder.
>
> After making these changes, you can still use "from visual import *" if that is
> convenient, but if you want to import the visual objects cleanly, import them
> from the new vpython module. Here are two simple examples:
>
> import vpython as vp
> vp.box(color=vp.color.orange, material=vp.materials.wood)
>
> from vpython import (box, color, materials)
> box(color=color.orange, material=materials.wood)
>
> There are new clean modules vpython.controls, vpython.filedialog, and
> vpython.graph
> that can be used instead of the old modules visual.controls,
> visual.filedialog, and
> visual.graph. The old modules execute "from visual import *" and are
> retained because
> some programs expect that behavior when importing one of these modules.
>

[Visualpython-users] Experimental clean import capability

[Bruce S. <bas...@nc...>]

In the "For developers" section of vpython.org is a zip file
containing experimental code for doing either the convenient "from
visual import *" or a clean "import vpython". Please try this out and
post comments about whether this would meet your needs, or how it
should be changed, or offer a different scheme entirely. Once we reach
agreement, this will become a part of VPython 5.4 for Python 2.7 and
Python 3.1.

I was able to follow the suggestion to put almost everything in the
new vpython folder, so that the visual folder mostly just imports from
the vpython folder. I thought it might be possible, and clean, to put
the two modules inside one folder, but that doesn't work. I'm very
hazy on how the import search works. If you see a way to have one
folder rather than two, please explain.

As far as I can tell from my tests, there is complete backward
compatibility with existing programs.

Bruce Sherwood

-----------------------------------------------------------------------------

Here are the installation instructions in the accompanying README file:

1) Before making any changes to your current site-packages, make a copy of

     site-packages/visual

2) Replace site-packages/visual with the visual folder in this package.

3) Add to site-packages the vpython folder in this package.

4) From your saved copy of site-packages/visual, copy into the new
vpython folder

     cvisual.pyd (Windows) or
     cvisual.so (Mac)

5) On Windows, from your saved copy of site-packages/visual, copy the doc and
   examples folders into the new visual folder.

After making these changes, you can still use "from visual import *" if that is
convenient, but if you want to import the visual objects cleanly, import them
from the new vpython module. Here are two simple examples:

import vpython as vp
vp.box(color=vp.color.orange, material=vp.materials.wood)

from vpython import (box, color, materials)
box(color=color.orange, material=materials.wood)

There are new clean modules vpython.controls, vpython.filedialog, and
vpython.graph
that can be used instead of the old modules visual.controls,
visual.filedialog, and
visual.graph. The old modules execute "from visual import *" and are
retained because
some programs expect that behavior when importing one of these modules.

[Visualpython-users] VPython for Python 3 on Mac

[Bruce S. <bas...@nc...>]

I've succeeded in running VPython for Python 3 on the Mac. I've been
using VPython for Python 3 on my Windows machine for some time without
problems. I haven't managed to build on Ubuntu, I think due to
clumsiness on my part in building and installing from source the Boost
libraries for Python 3, for which there is no package.

I'd like to incorporate the thinking of the community on clean imports
of Visual features before releasing anything for Python 3, just for
clarity. I think that a good scheme is likely to emerge very soon.
Let's aim for VPython 5.4 on Python 2.7 and Python 3.1, with a clean
import option available on both versions of Python (in addition to the
convenience/compatibility form "from visual import *").

Bruce Sherwood

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

[C A. R. <an...@ex...>]

On Fri, Oct 8, 2010 at 10:09 PM, Guy K. Kloss <g....@ma...> wrote:
> On Sat, 09 Oct 2010 16:05:22 C Anthony Risinger wrote:
>> So, it may have to remain a package for compatibility, but that
>> doesn't mean it needs to implement anything significant; it can still
>> import what it needs from "vpython".
>
> It could be an empty package, that only contains a __init__.py, which does all
> the import magic.

That's what I meant :-)

I was trying to see if it was possible to do it with only a file,
visual.py like pylab, but I just don't think that will work.

__init__.py can append a finder to sys.meta_path, which will then be
used to properly build the namespace/"virtual" package contents.

Some brief tests looked fine, but I'll try to make something more
concrete later today.

C Anthony

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

[Bruce S. <bas...@nc...>]

I had read those same documents about imports and reached the opposite
conclusions!

The full context in your reference [1] is this:

"Never use relative package imports. If you’re writing code that’s in
the package.sub.m1 module and want to import package.sub.m2, do not
just write import m2, even though it’s legal. Write from package.sub
import m2 instead. Relative imports can lead to a module being
initialized twice, leading to confusing bugs. See PEP 328 for
details."

By "relative import" here they mean "import m2" inside a package,
which has the danger of importing some module named m2 that is outside
the package. As I read the documents, the new dot notation is designed
to make it possible for packages to be real packages, which can even
be moved to a different folder and still work under the new package
name.

An example of the power of the dot notation is that for Python 3 I was
able to make experimental versions of IDLE and VIDLE that except for
one single very special statement don't refer to either "idlelib" or
"vidle" and have mostly the same code inside the idlelib or vidle
folder.

If I've fundamentally misunderstood the point, perhaps a very specific
example would help me see the error of my ways.

Bruce Sherwood

On Fri, Oct 8, 2010 at 5:05 PM, Guy K. Kloss <g....@ma...> wrote:
> On Sat, 09 Oct 2010 10:44:29 Bruce Sherwood wrote:
>> This proposal assumed that the "libvisual" file was in the visual
>> folder, in which case I thought that relative imports were now
>> favored, for various reasons. As I understand it, the main issue is
>> that there could be a module named "foo" at a higher level in the
>> search path, in which case "import foo" might not pick up our foo, but
>> someone else's foo. Have I misunderstood something?
>
> Well, not really. It's just that the use of relative imports is mainly
> intended for corner cases, but it's discouraged to be used on a general basis.
> Of course, things could break if there's a clash between two "foo" modules.
> This is called "shadowing". One common case is for example when people call a
> variable "file" and therefore are shadowing the built-in "file" type.
>
> In other cases, this behaviour is exactly desired, so for example when people
> *want* to use a specific implementation as a drop-in replacement for an
> otherwise used package. This is for example quite common with the XML parser
> through the ElementTree API. Many APIs are designed to be compatible with each
> other, another one of those are the ones of the threading/processing modules.
> So a user can choose which one to use (for various reasons).
>
> So what it boils down to is to commonly use absolute imports rather than
> relative ones, unless something demands a relative import for specific
> reasons. From the Python documentation [1]: "Relative imports can lead to a
> module being initialized twice, leading to confusing bugs. See PEP 328 [2] for
> details."
>
> You can read up more on this and related issues more on [1], [2] and [3].
>
> Guy
>
>
> [1] http://docs.python.org/faq/programming.html#what-are-the-best-practices-
> for-using-import-in-a-module
>
> [2] http://docs.python.org/release/2.5/whatsnew/pep-328.html
>
> [3] http://bugs.python.org/issue10031
>
> Guy
>

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

[Guy K. K. <g....@ma...>]

On Sat, 09 Oct 2010 16:05:22 C Anthony Risinger wrote:
> So, it may have to remain a package for compatibility, but that
> doesn't mean it needs to implement anything significant; it can still
> import what it needs from "vpython".

It could be an empty package, that only contains a __init__.py, which does all 
the import magic.

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

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

[C A. R. <an...@ex...>]

On Fri, Oct 8, 2010 at 7:47 PM, Guy K. Kloss <g....@ma...> wrote:
> On Sat, 09 Oct 2010 13:11:44 Bruce Sherwood wrote:
>> I think and hope we're in agreement. My point was a narrow technical
>> one, that in the matplotlib case the simplified import could be
>> handled with a single file (pylab.py) whereas we need a folder named
>> visual due to the existence of visual.graph and visual.factorial and
>> possible imports by someone of other files currently in the visual
>> folder.
>
> Wouldn't it make sense to have "vpython" (or any other name) as a package
> (folder/directory), which contains then the modules graph and factorial?

I 100% agree here... and a bit of reiteration, but the clean module
*must* have all the guts, "visual" becomes a "meeting ground"/facade
of "vpython", numpy, etc., along with some convenience stuff.
"visual" package should do nothing significant.

> Then visual would just need to be a module (visual.py) to import the stuff
> from vpython, vpython.graph, vpython.factorial, ...

After some research I really don't think this is possible; it would
only work if importing "visual" directly, ie. `import visual`.

The standard import machinery directly translates the dotted package
name to a directory hierarchy... the only way I see around this is by
using sys.meta_path, or possibly some tweaking from a C module, but
the latter is beyond my knowledge.

So, it may have to remain a package for compatibility, but that
doesn't mean it needs to implement anything significant; it can still
import what it needs from "vpython".

C Anthony

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

[Guy K. K. <g....@ma...>]

On Sat, 09 Oct 2010 13:11:44 Bruce Sherwood wrote:
> I think and hope we're in agreement. My point was a narrow technical
> one, that in the matplotlib case the simplified import could be
> handled with a single file (pylab.py) whereas we need a folder named
> visual due to the existence of visual.graph and visual.factorial and
> possible imports by someone of other files currently in the visual
> folder.

Wouldn't it make sense to have "vpython" (or any other name) as a package 
(folder/directory), which contains then the modules graph and factorial?

Then visual would just need to be a module (visual.py) to import the stuff 
from vpython, vpython.graph, vpython.factorial, ...

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

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

[C A. R. <an...@ex...>]

On Fri, Oct 8, 2010 at 7:11 PM, Bruce Sherwood <bas...@nc...> wrote:
>
> I think and hope we're in agreement. My point was a narrow technical
> one, that in the matplotlib case the simplified import could be
> handled with a single file (pylab.py) whereas we need a folder named
> visual due to the existence of visual.graph and visual.factorial and
> possible imports by someone of other files currently in the visual
> folder.

Nothing new to add, I just wanted to briefly chime about a few things
(from older messages too):

) +3, 2, 1 for either "vpython", "vispy", or "visuallib", respectively
as the clean package name, for consistency with related projects
(libvisual looks nice to me, but it does give the impression of a
shared object i suppose)
) clean package should _definitely_ be it's own package/top-level, and
not in the visual namespace
) clean package should have _all_ the functionality, "visual" should
just pull from it like it does from numpy and friends; anything in
"visual" is specific to the backwards compat requirement or
convenience

As for the visual.graph etc. problems... "visual" may indeed need to
remain a package, and visual.graph can pull from the clean package
like anything else within the "visual" package.

I'm looking into it now if there is a way to make a module "pretend"
to be a package, then dynamically create additional modules/etc.
within it's namespace; then maybe we could have a single file called
"visual.py"... not sure yet, I don't know if the import machinery will
allow it.

C Anthony

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

[Bruce S. <bas...@nc...>]

I think and hope we're in agreement. My point was a narrow technical
one, that in the matplotlib case the simplified import could be
handled with a single file (pylab.py) whereas we need a folder named
visual due to the existence of visual.graph and visual.factorial and
possible imports by someone of other files currently in the visual
folder.

Bruce Sherwood

On Fri, Oct 8, 2010 at 4:40 PM, Guy K. Kloss <g....@ma...> wrote:
> On Sat, 09 Oct 2010 10:41:35 Bruce Sherwood wrote:
>> Are you saying that there should be two copies of key components in
>> the two folders (which I'll call "visual" and "vpython" for now)? I
>> would be nervous about the maintenance issues, although I guess
>> installers be built to put copies of files in two places.
>
> No no no. Absolutely not. The code is there only *once*, but as you're
> "mirroring in" parts of the NumPy and math name spaces, you'd be "mirroring
> in" all the stuff into the "visual" package from the "vpython" packages. So
> the "visual" package/module does not really contain any (significant)
> implementations, but just imports/aggregates the stuff from "around the
> house".
>
>> My intention
>> is that if the actual implementation is done right it should make no
>> difference whatsoever where the components are physically located,
>> that importing from the vpython folder will be completely clean,
>> independent of where the files are.
>
> Exactly, that's the way I (and probably the others putting up their votes for
> better Python cleanliness) have envisioned it.
>
> 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

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

[Guy K. K. <g....@ma...>]

On Sat, 09 Oct 2010 10:44:29 Bruce Sherwood wrote:
> This proposal assumed that the "libvisual" file was in the visual
> folder, in which case I thought that relative imports were now
> favored, for various reasons. As I understand it, the main issue is
> that there could be a module named "foo" at a higher level in the
> search path, in which case "import foo" might not pick up our foo, but
> someone else's foo. Have I misunderstood something?

Well, not really. It's just that the use of relative imports is mainly 
intended for corner cases, but it's discouraged to be used on a general basis. 
Of course, things could break if there's a clash between two "foo" modules. 
This is called "shadowing". One common case is for example when people call a 
variable "file" and therefore are shadowing the built-in "file" type.

In other cases, this behaviour is exactly desired, so for example when people 
*want* to use a specific implementation as a drop-in replacement for an 
otherwise used package. This is for example quite common with the XML parser 
through the ElementTree API. Many APIs are designed to be compatible with each 
other, another one of those are the ones of the threading/processing modules. 
So a user can choose which one to use (for various reasons).

So what it boils down to is to commonly use absolute imports rather than 
relative ones, unless something demands a relative import for specific 
reasons. From the Python documentation [1]: "Relative imports can lead to a 
module being initialized twice, leading to confusing bugs. See PEP 328 [2] for 
details."

You can read up more on this and related issues more on [1], [2] and [3].

Guy


[1] http://docs.python.org/faq/programming.html#what-are-the-best-practices-
for-using-import-in-a-module

[2] http://docs.python.org/release/2.5/whatsnew/pep-328.html

[3] http://bugs.python.org/issue10031

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

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

[Guy K. K. <g....@ma...>]

On Sat, 09 Oct 2010 10:41:35 Bruce Sherwood wrote:
> Are you saying that there should be two copies of key components in
> the two folders (which I'll call "visual" and "vpython" for now)? I
> would be nervous about the maintenance issues, although I guess
> installers be built to put copies of files in two places.

No no no. Absolutely not. The code is there only *once*, but as you're 
"mirroring in" parts of the NumPy and math name spaces, you'd be "mirroring 
in" all the stuff into the "visual" package from the "vpython" packages. So 
the "visual" package/module does not really contain any (significant) 
implementations, but just imports/aggregates the stuff from "around the 
house".

> My intention
> is that if the actual implementation is done right it should make no
> difference whatsoever where the components are physically located,
> that importing from the vpython folder will be completely clean,
> independent of where the files are.

Exactly, that's the way I (and probably the others putting up their votes for 
better Python cleanliness) have envisioned it.

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

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

[Bruce S. <bas...@nc...>]

This proposal assumed that the "libvisual" file was in the visual
folder, in which case I thought that relative imports were now
favored, for various reasons. As I understand it, the main issue is
that there could be a module named "foo" at a higher level in the
search path, in which case "import foo" might not pick up our foo, but
someone else's foo. Have I misunderstood something?

Bruce Sherwood

On Fri, Oct 8, 2010 at 2:57 PM, Guy K. Kloss <g....@ma...> wrote:
> On Fri, 08 Oct 2010 17:39:59 Bruce Sherwood wrote:
>> Here's another possibility for the contents of a file in the visual
>> folder, perhaps called libvisual as has been suggested:
>>
>> ----------------------------------------------------
>> from . import cvisual
>> from .cvisual import (vector, mag, mag2, norm, cross, rotate,
>>                        comp, proj, diff_angle, rate, waitclose)
>> from .primitives import (arrow, cylinder, cone, sphere, box, ring, label,
>>                                frame, pyramid, ellipsoid, curve,
>> faces, convex, helix,
>>                                points, text, distant_light, local_light)
>> from . ui import display
>> from . import crayola
>> color = crayola
>> from . import materials
>> from . import site_settings
>> ----------------------------------------------------
>
> Why all these funky relative imports ("from . import foo")?
>
> It should be much cleaner to just say "import foo"!
>
> 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
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

[Bruce S. <bas...@nc...>]

Are you saying that there should be two copies of key components in
the two folders (which I'll call "visual" and "vpython" for now)? I
would be nervous about the maintenance issues, although I guess
installers be built to put copies of files in two places. My intention
is that if the actual implementation is done right it should make no
difference whatsoever where the components are physically located,
that importing from the vpython folder will be completely clean,
independent of where the files are. If that's not achievable, then of
course you're right.

Bruce Sherwood

On Fri, Oct 8, 2010 at 2:55 PM, Guy K. Kloss <g....@ma...> wrote:
> On Sat, 09 Oct 2010 07:05:19 Bruce Sherwood wrote:
>> I pointed out that while we can arrange things in such a way as to
>> look like this, the actual implementation has to be "the other way
>> round": for backward compatibility the visual folder has to remain
>> essentially unchanged, and a second folder (maybe named "vpython")
>> would have submodules that would import from the visual folder.
>
> I think there's an error in the logic here. The implementation should be
> driven in a way that it is implemented cleanly first off the bat. Then you can
> put all kinds of imports into a "comfortability" module "visual".
>
> If done the other way around, the runtime will be buggered with all the unused
> imports, and it is only the presentation that makes it look more pythonesque.
>
> So my suggestion goes along the line to provide two independent name spaces:
> "vpython" (or "libvisual" or whatever suggestions Craig has made) for the
> clean implementation, and a separate one "visual" that contains the
> comfortability imports from the clean implementation.
>
> 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
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>