Menu
▾
▴
visualpython-users
|
From: Guy K. K. <g....@ma...> - 2009-06-29 02:34:59
|
OK, creating a proper Debian package for Jaunty/Python 2.6 was a bit of a challgenge. Gladly Jonas Smedegaard has recently created packages for the upcoming Karmic Koala (9.10) release. So it was just a matter of a backport making it *much* easier. Additionally I have patched the 5.11 version to not wildcard import visual, numpy and math all over the place. So the name space is not polluted and VPython should play much more nicely with other Python stuff on the system. Both packages are available for download here: https://gutefee.massey.ac.nz/moin/Python/3D (You need to accept the self signed certificate as an exception to get the packages) Enjoy, 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-06-29 05:52:13
|
Warning: I do not accept the notion of removing the full importation of numpy and math without vastly more discussion. There were and are good reasons for the existing scheme, and changing this will break existing programs right and left, programs that large numbers of people depend on. Most of these people are students and instructors who aren't working on Linux, so there's little immediate danger. And I accept that for some advanced users cleaning the name space can be useful. But it should be understood that this is for "consenting adults." My concern is that it could be very difficult for someone who is not expert to be able to figure out what has gone wrong. Bruce Sherwood Guy K. Kloss wrote: > OK, creating a proper Debian package for Jaunty/Python 2.6 was a bit of a > challgenge. Gladly Jonas Smedegaard has recently created packages for the > upcoming Karmic Koala (9.10) release. So it was just a matter of a backport > making it *much* easier. > > Additionally I have patched the 5.11 version to not wildcard import visual, > numpy and math all over the place. So the name space is not polluted and > VPython should play much more nicely with other Python stuff on the system. > > Both packages are available for download here: > > https://gutefee.massey.ac.nz/moin/Python/3D > > (You need to accept the self signed certificate as an exception to get the > packages) > > Enjoy, > > Guy > > |
|
From: Guy K. K. <g....@ma...> - 2009-06-29 06:07:36
|
Hold your horses there ... On Mon, 29 Jun 2009 17:52:11 Bruce Sherwood wrote: > Warning: I do not accept the notion of removing the full importation of > numpy and math without vastly more discussion. That's why that package is provided *additionally*, but the basic one is given first on that page. > There were and are good > reasons for the existing scheme, and changing this will break existing > programs right and left, programs that large numbers of people depend > on. Most of these people are students and instructors who aren't working > on Linux, so there's little immediate danger. And I accept that for some > advanced users cleaning the name space can be useful. But it should be > understood that this is for "consenting adults." My concern is that it > could be very difficult for someone who is not expert to be able to > figure out what has gone wrong. Yes, so can be the difficulty trying to figure out why the code is all of a sudden behaving erratically, although you did everything the way you usually do in Python. There are strong arguments for both sides. The one to make it easier, and the one to keep it in a Pythonic way. And after all, the ones using it are using Python, so that's the common denominator one should adhere to. And telling them to do a wild card import should be easy as anyway, if they want it to be simple but messy. 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-06-29 06:25:28
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
It's good that you provide two versions, but there's an informational
problem for someone trying to figure out the ramifications of which to
use.<br>
<br>
There aren't just two sides to this; there are more like four sides.
Sides 3 and 4 are these:<br>
<br>
3) There exists a large body of existing VPython programs developed
over the last 9 years that various constituencies depend on working,
and removing the numpy and math imports will break many (most?) of
these. Many of these users are students and faculty who cannot be
easily reached to explain a major change; they don't read computer
lists.<br>
<br>
4) There is a tricky point concerning mathematical functions that
appear in both math and numpy. When Arthur Siegel did the work to
convert Visual from dependence on Numeric to dependence on numpy,
performance on many existing programs was horrible, because numpy
scalar floats, unlike Numeric scalar floats, were no longer captured by
the fast math functions but instead were processed by the
array-handling numpy functions. There is arcane code in Visual to get
around this problem. Few users would be able to figure this out for
themselves.<br>
<br>
Bruce Sherwood<br>
<br>
Guy K. Kloss wrote:
<blockquote cite="mid:200...@ma..."
type="cite">
<pre wrap="">Hold your horses there ...
On Mon, 29 Jun 2009 17:52:11 Bruce Sherwood wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Warning: I do not accept the notion of removing the full importation of
numpy and math without vastly more discussion.
</pre>
</blockquote>
<pre wrap=""><!---->
That's why that package is provided *additionally*, but the basic one is given
first on that page.
</pre>
<blockquote type="cite">
<pre wrap="">There were and are good
reasons for the existing scheme, and changing this will break existing
programs right and left, programs that large numbers of people depend
on. Most of these people are students and instructors who aren't working
on Linux, so there's little immediate danger. And I accept that for some
advanced users cleaning the name space can be useful. But it should be
understood that this is for "consenting adults." My concern is that it
could be very difficult for someone who is not expert to be able to
figure out what has gone wrong.
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, so can be the difficulty trying to figure out why the code is all of a
sudden behaving erratically, although you did everything the way you usually
do in Python.
There are strong arguments for both sides. The one to make it easier, and the
one to keep it in a Pythonic way. And after all, the ones using it are using
Python, so that's the common denominator one should adhere to. And telling
them to do a wild card import should be easy as anyway, if they want it to be
simple but messy.
Guy
</pre>
</blockquote>
</body>
</html>
|
|
From: Guy K. K. <g....@ma...> - 2009-06-29 07:07:50
|
BTW, I have added a warning to the wiki page on the modified version to clarify the difference between the two versions. On Mon, 29 Jun 2009 18:25:28 Bruce Sherwood wrote: > 3) There exists a large body of existing VPython programs developed over > the last 9 years that various constituencies depend on working, and > removing the numpy and math imports will break many (most?) of these. Many > of these users are students and faculty who cannot be easily reached to > explain a major change; they don't read computer lists. I can understand this point of view. That's why it's vital to keep the API frozen on a major release series (5.x). > 4) There is a tricky point concerning mathematical functions that appear in > both math and numpy. When Arthur Siegel did the work to convert Visual from > dependence on Numeric to dependence on numpy, performance on many existing > programs was horrible, because numpy scalar floats, unlike Numeric scalar > floats, were no longer captured by the fast math functions but instead were > processed by the array-handling numpy functions. There is arcane code in > Visual to get around this problem. Few users would be able to figure this > out for themselves. But those distinctions happen in module space of the visual module, not on the user level. What the user gets is just a cluttered mix and mash of functions with overlapping name spaces. There's nothing wrong in keeping this distinction for speed up under the bonnet of the module (which is what I have done in the modification, too). The aim is just to give the user a *predictable* experience for future versions, which is not guaranteed if a module messes with the name spaces from other modules that are not obviously related. The modifications I have provided are (A) for my own sanity, and might (B) be used as a basis for future development towards a 6.x release series of VPython. I just wanted to be *nice* by offering that stuff to others as well, who've been bitten by the polluted name space. BTW, have you ever tried to familiarise yourself with a new module/package by using IPython interactively? It's quite neat, as it offers tab completion to find potential good candidates for something. This has bitterly failed using the default visual module, as it is just cluttered by 100s of members that have got nothing obvious to do with VPython, but are swamped in through numpy and math, and they totally obfuscate the use. 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: Gary R. <gr...@bi...> - 2009-06-29 15:11:55
|
Just to add another voice to this discussion, rather than prevent the import of numpy and math, which breaks backward compatibility, 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? Gary R. |
|
From: Guy K. K. <g....@ma...> - 2009-06-29 19:46:21
|
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? 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" * Namespaces are one honking great idea -- let's do more of those! * Readability counts. * Special cases aren't special enough to break the rules. * In the face of ambiguity, refuse the temptation to guess. * There should be one-- and preferably only one --obvious way to do it. And it's not rocket science. I've patched the original sources within 30 minutes, and it's been quite helpful for me. As a proof of concept attached with a warning, that might also help others, I have provided these packages. So beware, they *will* break the common use and all examples, but they do retain the 5.x API. Guy In [32]: import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! -- 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: Gary R. <gr...@bi...> - 2009-06-30 14:53:09
|
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 |
|
From: Craig S. <cra...@ma...> - 2009-06-30 15:26:57
|
I want to echo Bruce's request for careful thought in this process.
Changing the API to be more Pythonesque and changing the distribution
to using a more ideal dependency structure may have certain aesthetic
and large scale advantages, but I fear they would be hurdles that
would prevent larger adoption.
Having just taught a 3-day workshop on computational thinking using
Python and VPython to high school science teachers, who have never
used Python or VPython before, the current simple to use import
behavior was essential to getting them to begin writing their own
simulations in a short period of time. Our goal was to have the
teachers focus on the science they wanted to teach, not to master
Python's language or namespaces. Every additional line of code needed
to get a simple simulation running is a very large penalty to many
users.
My main point is that there needs to be an option in the mix that
maintains the simplicity both in imports and in distribution. I also
thought, as a Gary suggested, that a namespace such as
from visual.core import *
(instead of visual.visual, which is a confusing name) would be a
reasonable transition from the current behavior to something more in
line with good Python practice. So
from visual import *
could import everything into a single namespace and let the other
modules be better suited for developers needing more control. The
visual.graph module would probably need some refactoring to act more
like a proper Python module that doesn't pollute namespaces, but then
there would be more consistency in behavior. (The current behavior of
visual.graph is a little confusing to explain.) Gary's other
suggestion about visual.all is also reasonable.
Craig
On Jun 30, 2009, at 8: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
--
Craig A. Struble, Ph.D. | 369 Cudahy Hall | Marquette University
Associate Professor of Computer Science | (414)288-3783
Director, Master of Bioinformatics Program | (414)288-5472 (fax)
http://www.mscs.mu.edu/~cstruble | cra...@ma...
|
|
From: Bruce S. <Bru...@nc...> - 2009-06-30 17:12:55
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Thanks for the elegant commentary, Craig. Because I too work with large
numbers of naive users, in particular including teachers and students,
this is precisely my concern and experience as well, but you've said it
better than I could.<br>
<br>
At the same time, we want Visual to be useful to and usable by power
users, and I'm glad that Guy Kloss has raised the issues, and happy to
see the constructive discussions that are under way. Your choice of
"visual.core" is exactly the same name that Dave Scherer, the
originator of Visual, suggested when I talked recently with him about
these issues. He too is in favor of cleaning the space, but with
caution. One possible approach is to import very few essential things
from the very large numpy module, but probably all of the much smaller
math module (though even there one should look carefully); the point of
including the math module is that you can hardly do anything with
Visual without sines and cosines and square roots. He also suggested a
factoring that would include "visual.math" (which would perform the
magic needed to get good performance out of choosing the math sqrt
instead of the numpy sqrt when possible).<br>
<br>
I'm strongly against eliminating numpy from the Windows and Mac
installers. We found experimentally that even college students majoring
in engineering and science fairly frequently have difficulties with a
two-part installation (Python and Visual), and there have been serious
questions about the advisability of a one-part installer for novices. A
three-part installation would be 50% worse than the current situation.
Linux is a different beast, and there the dependencies can be taken
care of by the package manager, if someone makes a Visual package for a
particular distribution.<br>
<br>
I'll mention that you'll see in __init__.py the following:<br>
# Names defined for backward compatibility with Visual 3:<br>
import sys, time<br>
true = True<br>
false = False<br>
We shouldn't be importing sys and time; the last time this issue was
visited, there were fears of introducing incompatibilities, but I'm not
sure how valid those particular fears were.<br>
<br>
Bruce Sherwood<br>
<br>
Craig Struble wrote:
<blockquote
cite="mid:C43...@ma..."
type="cite">
<pre wrap="">I want to echo Bruce's request for careful thought in this process.
Changing the API to be more Pythonesque and changing the distribution
to using a more ideal dependency structure may have certain aesthetic
and large scale advantages, but I fear they would be hurdles that
would prevent larger adoption.
Having just taught a 3-day workshop on computational thinking using
Python and VPython to high school science teachers, who have never
used Python or VPython before, the current simple to use import
behavior was essential to getting them to begin writing their own
simulations in a short period of time. Our goal was to have the
teachers focus on the science they wanted to teach, not to master
Python's language or namespaces. Every additional line of code needed
to get a simple simulation running is a very large penalty to many
users.
My main point is that there needs to be an option in the mix that
maintains the simplicity both in imports and in distribution. I also
thought, as a Gary suggested, that a namespace such as
from visual.core import *
(instead of visual.visual, which is a confusing name) would be a
reasonable transition from the current behavior to something more in
line with good Python practice. So
from visual import *
could import everything into a single namespace and let the other
modules be better suited for developers needing more control. The
visual.graph module would probably need some refactoring to act more
like a proper Python module that doesn't pollute namespaces, but then
there would be more consistency in behavior. (The current behavior of
visual.graph is a little confusing to explain.) Gary's other
suggestion about visual.all is also reasonable.
Craig
On Jun 30, 2009, at 8:07 AM, Gary Ruben wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Guy K. Kloss wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Tue, 30 Jun 2009 00:15:09 Gary Ruben wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">Since when is obfuscation helpful?
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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"
</pre>
</blockquote>
<pre wrap=""><snip>
Gary
------------------------------------------------------------------------------
_______________________________________________
Visualpython-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Vis...@li...">Vis...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/visualpython-users">https://lists.sourceforge.net/lists/listinfo/visualpython-users</a>
</pre>
</blockquote>
<pre wrap=""><!---->
--
Craig A. Struble, Ph.D. | 369 Cudahy Hall | Marquette University
Associate Professor of Computer Science | (414)288-3783
Director, Master of Bioinformatics Program | (414)288-5472 (fax)
<a class="moz-txt-link-freetext" href="http://www.mscs.mu.edu/~cstruble">http://www.mscs.mu.edu/~cstruble</a> | <a class="moz-txt-link-abbreviated" href="mailto:cra...@ma...">cra...@ma...</a>
------------------------------------------------------------------------------
_______________________________________________
Visualpython-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Vis...@li...">Vis...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/visualpython-users">https://lists.sourceforge.net/lists/listinfo/visualpython-users</a>
</pre>
</blockquote>
</body>
</html>
|
|
From: James M. <mu...@pi...> - 2009-06-30 15:41:53
|
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 |
×
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