Menu
▾
▴
visualpython-users
|
From: Symion <kn...@ip...> - 2009-10-21 07:53:51
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> </head> <body bgcolor="#ffffff" text="#000000"> <tt>Hi there,<br> <br> I have been using Visual.random number generators and have found that the following Methods return as <br> numpy arrays, which when Printed or Evaluated returns a list that is not separated by the usual commas.<br> <br> from visual import *<br> <br> print visual.random.sample(5) # floating point list with no commas<br> print visual.random.permutation(5)</tt><tt> # Integer list with no commas</tt><br> <tt>print visual.random.randint(1,46,5)</tt><tt> # Integer list with no commas</tt><br> <tt><br> visual.safe_eval(</tt><tt>str(visual.random.randint(1,46,5))) # generates error<br> <br> </tt><tt>No commas between elements?!<br> <br> A work around is to add .tolist()<br> <br> visual.random.sample(5).tolist() # returns normal list of floats<br> visual.random.permutation(6).tolist()<br> visual.random.randint(1,46,5).tolist()<br> visual.safe_eval(str(visual.random.randint(1,46,5).tolist()))<br> <br> Symion</tt> <br> </body> </html> |
|
From: Guy K. K. <g....@ma...> - 2009-10-21 18:36:11
|
Hi Symion, On Wed, 21 Oct 2009 20:53:30 Symion wrote: > I have been using Visual.random number generators and have found that the > following Methods return as numpy arrays, which when Printed or Evaluated > returns a list that is not separated by the usual commas. > > from visual import * Yes, this is one of the issues that I've been mentioning on the list before, caused by the snowball imports that Visual is conducting under the bonnet in the code (from math import *; from numpy import *). Therefore the namespace is quite "polluted" with modules that are not from Visual, but that also may behave in some way unexpected, as they come from different packages. In the case of random this originates from NumPy, and therefore returns NumPy's ndarray structures. > print visual.random.sample(5) # floating point list with no commas > print visual.random.permutation(5) # Integer list with no commas > print visual.random.randint(1,46,5) # Integer list with no commas > > visual.safe_eval(str(visual.random.randint(1,46,5))) # generates error > > No commas between elements?! The ndarray objects are *not* lists or tuples. But they do implement the methods of the iterable interface so they behave in many ways like lists. As for your observation, their __str__() method is implemented to print out arrays separated by blanks, and not to use commas as separators, as well as other rounding style, and some truncation style on very extensive arrays. > A work around is to add .tolist() Or to call the list constructor: list(a_numpy_array) > visual.random.sample(5).tolist() # returns normal list of floats > visual.random.permutation(6).tolist() > visual.random.randint(1,46,5).tolist() > visual.safe_eval(str(visual.random.randint(1,46,5).tolist())) Be very careful what's imported, and what you're using. It might be not what you expect. That's also why an "from visual import *" can be quite dangerous for your own code, as their name spaces are *very* full and may mask stuff you're doing yourself. 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. 9585 fax: +64 9 441-8181 G....@ma... http://www.massey.ac.nz/~gkloss |
|
From: Derek <kn...@ip...> - 2009-10-22 14:22:48
|
Guy K. Kloss wrote: > Hi Symion, > > On Wed, 21 Oct 2009 20:53:30 Symion wrote: > >> I have been using Visual.random number generators and have found that the >> following Methods return as numpy arrays, which when Printed or Evaluated >> returns a list that is not separated by the usual commas. >> >> from visual import * >> > > Yes, this is one of the issues that I've been mentioning on the list before, > caused by the snowball imports that Visual is conducting under the bonnet in > the code (from math import *; from numpy import *). > > Therefore the namespace is quite "polluted" with modules that are not from > Visual, but that also may behave in some way unexpected, as they come from > different packages. > > In the case of random this originates from NumPy, and therefore returns > NumPy's ndarray structures. > > >> print visual.random.sample(5) # floating point list with no commas >> print visual.random.permutation(5) # Integer list with no commas >> print visual.random.randint(1,46,5) # Integer list with no commas >> >> visual.safe_eval(str(visual.random.randint(1,46,5))) # generates error >> >> No commas between elements?! >> > > The ndarray objects are *not* lists or tuples. But they do implement the > methods of the iterable interface so they behave in many ways like lists. As > for your observation, their __str__() method is implemented to print out > arrays separated by blanks, and not to use commas as separators, as well as > other rounding style, and some truncation style on very extensive arrays. > > >> A work around is to add .tolist() >> > > Or to call the list constructor: list(a_numpy_array) > > >> visual.random.sample(5).tolist() # returns normal list of floats >> visual.random.permutation(6).tolist() >> visual.random.randint(1,46,5).tolist() >> visual.safe_eval(str(visual.random.randint(1,46,5).tolist())) >> > > Be very careful what's imported, and what you're using. It might be not what > you expect. That's also why an "from visual import *" can be quite dangerous > for your own code, as their name spaces are *very* full and may mask stuff > you're doing yourself. > > Guy > > I have been following the namespace issue and the following might help to get a handle on things. from visual import * print len(dir()) Mine reads 556 If you're brave you'll print dir()! Although this is a drawback, it is also a Gold mine of amazing, obscure, bizarre but quite often useful things. But then, on the other hand I would like to be able to 'import visual' as a minimal system then import any modules of my choosing. I can see the dilemma. Symion |
|
From: Bruce S. <Bru...@nc...> - 2009-10-22 01:47:24
|
Here's an idea about how to unpollute in a way that wouldn't break existing programs. Suppose one said "from visual2 import *" to get just the visual objects? Bruce Sherwood Guy K. Kloss wrote: > Hi Symion, > > On Wed, 21 Oct 2009 20:53:30 Symion wrote: >> I have been using Visual.random number generators and have found that the >> following Methods return as numpy arrays, which when Printed or Evaluated >> returns a list that is not separated by the usual commas. >> >> from visual import * > > Yes, this is one of the issues that I've been mentioning on the list before, > caused by the snowball imports that Visual is conducting under the bonnet in > the code (from math import *; from numpy import *). > > Therefore the namespace is quite "polluted" with modules that are not from > Visual, but that also may behave in some way unexpected, as they come from > different packages. > > In the case of random this originates from NumPy, and therefore returns > NumPy's ndarray structures. > >> print visual.random.sample(5) # floating point list with no commas >> print visual.random.permutation(5) # Integer list with no commas >> print visual.random.randint(1,46,5) # Integer list with no commas >> >> visual.safe_eval(str(visual.random.randint(1,46,5))) # generates error >> >> No commas between elements?! > > The ndarray objects are *not* lists or tuples. But they do implement the > methods of the iterable interface so they behave in many ways like lists. As > for your observation, their __str__() method is implemented to print out > arrays separated by blanks, and not to use commas as separators, as well as > other rounding style, and some truncation style on very extensive arrays. > >> A work around is to add .tolist() > > Or to call the list constructor: list(a_numpy_array) > >> visual.random.sample(5).tolist() # returns normal list of floats >> visual.random.permutation(6).tolist() >> visual.random.randint(1,46,5).tolist() >> visual.safe_eval(str(visual.random.randint(1,46,5).tolist())) > > Be very careful what's imported, and what you're using. It might be not what > you expect. That's also why an "from visual import *" can be quite dangerous > for your own code, as their name spaces are *very* full and may mask stuff > you're doing yourself. > > Guy > |
|
From: Tony R. <To...@br...> - 2009-10-22 02:13:00
|
Why not just "import visual2"? Isn't the * somewhat discouraged? I would rather have to important math/numpy stuff myself if I need them, and let the visual.* namespace be nothing but sphere/display/etc. That's how ive seen other modules internally and seems to be the norm to only explicitly import what you need. Is that not feasible for visual? Maybe the module needs to be one version for non programmers with a huge first level namespace, and another module more properly structured for integrators. On Oct 21, 2009, at 8:48 PM, "Bruce Sherwood" <Bru...@nc...> wrote: > Here's an idea about how to unpollute in a way that wouldn't break > existing > programs. Suppose one said "from visual2 import *" to get just the > visual objects? > > Bruce Sherwood > > Guy K. Kloss wrote: >> Hi Symion, >> >> On Wed, 21 Oct 2009 20:53:30 Symion wrote: >>> I have been using Visual.random number generators and have found >>> that the >>> following Methods return as numpy arrays, which when Printed or >>> Evaluated >>> returns a list that is not separated by the usual commas. >>> >>> from visual import * >> >> Yes, this is one of the issues that I've been mentioning on the >> list before, >> caused by the snowball imports that Visual is conducting under the >> bonnet in >> the code (from math import *; from numpy import *). >> >> Therefore the namespace is quite "polluted" with modules that are >> not from >> Visual, but that also may behave in some way unexpected, as they >> come from >> different packages. >> >> In the case of random this originates from NumPy, and therefore >> returns >> NumPy's ndarray structures. >> >>> print visual.random.sample(5) # floating point list with no commas >>> print visual.random.permutation(5) # Integer list with no commas >>> print visual.random.randint(1,46,5) # Integer list with no commas >>> >>> visual.safe_eval(str(visual.random.randint(1,46,5))) # generates >>> error >>> >>> No commas between elements?! >> >> The ndarray objects are *not* lists or tuples. But they do >> implement the >> methods of the iterable interface so they behave in many ways like >> lists. As >> for your observation, their __str__() method is implemented to >> print out >> arrays separated by blanks, and not to use commas as separators, as >> well as >> other rounding style, and some truncation style on very extensive >> arrays. >> >>> A work around is to add .tolist() >> >> Or to call the list constructor: list(a_numpy_array) >> >>> visual.random.sample(5).tolist() # returns normal list of floats >>> visual.random.permutation(6).tolist() >>> visual.random.randint(1,46,5).tolist() >>> visual.safe_eval(str(visual.random.randint(1,46,5).tolist())) >> >> Be very careful what's imported, and what you're using. It might be >> not what >> you expect. That's also why an "from visual import *" can be quite >> dangerous >> for your own code, as their name spaces are *very* full and may >> mask stuff >> you're doing yourself. >> >> Guy >> > > --- > --- > --- > --------------------------------------------------------------------- > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users > > Tony Risinger Application Development Specialist Tel: 507-535-7563 | Fax: 507-292-5747 | Toll Free: 866-241-0639 To...@Br... http://www.brokerbin.com/ CONFIDENTIAL INFORMATION: This electronic mail message and any attached files contain information intended for the exclusive use of the specific individual(s) or entity(s) to whom it is addressed and may contain information that is propriety, privileged or confidential or otherwise exempt from disclosure. If you are not the intended recipient, please notify the sender immediately, by reply electronic mail or by telephone, of any unintended recipients so we may correct our records. Also, delete the original electronic mail and any attachments without making any copies of the electronic mail message or attachments. |
|
From: Guy K. K. <g....@ma...> - 2009-10-22 02:14:01
|
On Thu, 22 Oct 2009 14:47:09 Bruce Sherwood wrote: > Here's an idea about how to unpollute in a way that wouldn't break > existing programs. Suppose one said "from visual2 import *" to get just > the visual objects? Hmmm, to have a "shadow package" that is unpolluted. Might be an idea. Make it API identical ... Another option to have a "vidual_" package that actually implements all the stuff, and then have a "visual" package (for backward compatibility) that imports "from visual_ import *" as well as does the other wild imports from NumPy and math. That might do the trick ... while trying to keep the implementation as clean as possible. 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. 9585 fax: +64 9 441-8181 G....@ma... http://www.massey.ac.nz/~gkloss |
|
From: Tony R. <To...@br...> - 2009-10-22 02:20:49
|
You could maybe use the __all__ list in init to somehow trigger a full import, maybe a dummy submodule... A way to transparently detect an "import visual" from an "from visual import *" seems the ideal case but I'm not sure if it could easily be imemented that way. Although there seems to be alot of namespace correction code in the visual package that could possibly be moved to a dummy submodule that is only triggered when someone uses the * syntax On Oct 21, 2009, at 9:15 PM, "Guy K. Kloss" <g....@ma...> wrote: > On Thu, 22 Oct 2009 14:47:09 Bruce Sherwood wrote: >> Here's an idea about how to unpollute in a way that wouldn't break >> existing programs. Suppose one said "from visual2 import *" to get >> just >> the visual objects? > > Hmmm, to have a "shadow package" that is unpolluted. Might be an > idea. Make it > API identical ... > > Another option to have a "vidual_" package that actually implements > all the > stuff, and then have a "visual" package (for backward compatibility) > that > imports "from visual_ import *" as well as does the other wild > imports from > NumPy and math. > > That might do the trick ... while trying to keep the implementation > as clean > as possible. > > Guy > > -- > Guy K. Kloss > Institute of Information and Mathematical Sciences > Te Kura Putaiao o Mohiohio me Pangarau > Massey University, Albany (North Shore City, Auckland) > 473 State Highway 17, Gate 1, Mailroom, Quad B Building > voice: +64 9 414-0800 ext. 9585 fax: +64 9 441-8181 > G....@ma... http://www.massey.ac.nz/~gkloss > > --- > --- > --- > --------------------------------------------------------------------- > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users Tony Risinger Application Development Specialist Tel: 507-535-7563 | Fax: 507-292-5747 | Toll Free: 866-241-0639 To...@Br... http://www.brokerbin.com/ CONFIDENTIAL INFORMATION: This electronic mail message and any attached files contain information intended for the exclusive use of the specific individual(s) or entity(s) to whom it is addressed and may contain information that is propriety, privileged or confidential or otherwise exempt from disclosure. If you are not the intended recipient, please notify the sender immediately, by reply electronic mail or by telephone, of any unintended recipients so we may correct our records. Also, delete the original electronic mail and any attachments without making any copies of the electronic mail message or attachments. |
|
From: Guy K. K. <g....@ma...> - 2009-10-22 03:03:56
|
On Thu, 22 Oct 2009 15:12:42 Tony Risinger wrote: > Why not just "import visual2"? Isn't the * somewhat discouraged? > > I would rather have to important math/numpy stuff myself if I need > them, and let the visual.* namespace be nothing but sphere/display/etc. Yeah, that's been discussed in the past ... The issues are (A) backwards compatibility, and (B) ease of use for students otherwise *not* into programming, that they have got immediate and instant access at a huge fund of useful functions for the purpose. Having said that, myself, I'm much more a fan of keeping it clean as well. So that's the reasoning behind the suggestion(s). 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. 9585 fax: +64 9 441-8181 G....@ma... http://www.massey.ac.nz/~gkloss |
|
From: Bruce S. <Bru...@nc...> - 2009-10-22 04:25:02
|
Yes, I should have said either "import visual2" or "from visual2 import *". The key point is that neither of these imports would import anything from math or numpy beyond what is utterly essential for visual itself to run. I should comment that the backwards compatibility issue has lots of ramifications that may not be obvious. For example, there are many faculty who run demos in their lectures that were written in VPython, and they themselves may not know much about the environment, and they may be running on classroom computers over which they have no control. These computers are periodically updated by a central university classroom technology group. If "from visual import *" breaks due to a new version of Python and Visual being installed, it's an educational disaster when the unsuspecting faculty member in the middle of class finds that an important demo program doesn't run. Bruce Sherwood Guy K. Kloss wrote: > On Thu, 22 Oct 2009 15:12:42 Tony Risinger wrote: >> Why not just "import visual2"? Isn't the * somewhat discouraged? >> >> I would rather have to important math/numpy stuff myself if I need >> them, and let the visual.* namespace be nothing but sphere/display/etc. > > Yeah, that's been discussed in the past ... > > The issues are (A) backwards compatibility, and (B) ease of use for students > otherwise *not* into programming, that they have got immediate and instant > access at a huge fund of useful functions for the purpose. > > Having said that, myself, I'm much more a fan of keeping it clean as well. > > So that's the reasoning behind the suggestion(s). > > Guy > |
|
From: Guy K. K. <g....@ma...> - 2009-10-22 05:07:45
|
On Thu, 22 Oct 2009 16:33:53 Bruce Sherwood wrote: > I should comment that the backwards compatibility issue has lots of > ramifications that may not be obvious. For example, there are many faculty > who run demos in their lectures that were written in VPython, and they > themselves may not know much about the environment, and they may be > running on classroom computers over which they have no control. These > computers are periodically updated by a central university classroom > technology group. If "from visual import *" breaks due to a new version of > Python and Visual being installed, it's an educational disaster when the > unsuspecting faculty member in the middle of class finds that an important > demo program doesn't run. Indeed, fully understood. We've discussed that at length. Maybe we should go that way of "cleaning up" the internal imports (as I've done once for the 5.11 version), and then do the wild card import *only* on the package level once for the package that needs these imports or backward compatibility reasons. Once I've got my thesis handed soon (this summer/December), I could assist in patching up the sources again towards that goal. Then we could easily introduce a "shadow" package "visual2", "visual_", "visual_clean" or whatever ... which does not include these wild card imports. I think this way everybody could be happy and just use what they need, or use the default for compatibility reasons. For a future version (5.2+ or 6.x) then it could be "reversed", so that the default becomes a clean "visual", and a "visual_compat" is provided for the ones who like it convenient as it was in the past. Just my two kiwi cents, 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. 9585 fax: +64 9 441-8181 G....@ma... http://www.massey.ac.nz/~gkloss |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X