visualpython-users

Re: [Visualpython-users] New Linux installer

[Arthur <ajs...@op...>]

> We found  that distutils just doesn't have enough power and capability to
handle the
> wide range of Linux/Unix environments, at least with the current
> implementation of Visual in C++ with dependencies on CXX.

Don't disagree.

I am moving toward making Linux my "default" working environmnent- and so
have done a good deal of installing of Python modules on Linux recently.
What I am finding is that most of them that have at all complex dependencies
do a configure script.  Many also include a setup.py - which seems to be
there to allow one to "give it a shot" , and fall back on the configure
script if it doesn't go out of the box.

I am finding the versioning issues related to GTK, gcc, gltkarea, etc quite
hairy - in areas that I am playing that are not directly related to VPython
(e.g., trying to get pygtkglarea - a python binding for gtkglarea)  working.
So I have a better undertanding of what Jonathan  is trying to deal with.


Art

[Visualpython-users] New Linux installer

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

At http://vpython.org is a new source-based installer for Linux (and
possibly some flavors of Unix) created by Jonathan Brandmeyer, an
engineering student at North Carolina State University. This installer uses
the powerful autoconfig machinery, which attempts to determine the details
of the particular Linux/Unix environment and creates a suitable make file
for the particular environment.

It has had enough testing to imply that it is better than what we had
before, but we much appreciate feedback from Linux/Unix users as to whether
it works for them, and/or how it fails. Unfortunately we have not yet been
successful in using it to install on Mac OSX 10.2, where for some reason it
fails to resolve something associated with gtkglarea. Sigh.

The older installer, aimed especially at RedHat 7.0 but used with some other
Linux situations is still available, with a link of the new installer page.

Thanks, Jonathan!

I should mention that we were stimulated by Arthur Siegel's experiments to
investigate various alternatives, especially including distutils. We found
that distutils just doesn't have enough power and capability to handle the
wide range of Linux/Unix environments, at least with the current
implementation of Visual in C++ with dependencies on CXX.

Bruce Sherwood

[Visualpython-users] [Fwd: Re: [scintilla] POV-Ray SDL lexer]

[Arthur <ajs...@op...>]

  Forwarding this here from the scintilla, SciTE list - as it is 
relevant to those of us who routinely export form VPython to PovRay. 
Especially to those who use SciTE, and espcially to the population of 
one who use a VPython aware version of SciTE.

Which reminds me, I also use a modified version of the povexport.py 
file, to which I added the ability  to export the VPython faces 
primitive. It only works with the current version of PovRay - 3.5.

I sent it along to Bruce some time ago. He sent it along to Ruth, who 
original wrote that extremely useful code. I was hoping my contributiion 
would be vetted and integrated into the file available on the VPython site.

I'm always kvetching, its true.
 
But it is  discouraging to someone hoping to make VPython more of an 
opensource community project, that this effort at a contribution seems 
to have dropped into a void, without comment.

The modifed povray export file is available on rewuest.

Art


Philippe Lhoste wrote:

>Hello.
>
>I finally finished a project started some months ago: a lexer for the Scene
>Description Language (SDL) of 
>POV-Ray (Persistance of Vision Raytracer). 
>
That's good news. Was hoping somewbody might be up to that.  

I am using SciTE for a project that exports to PovRay, and was hoping to 
have the ability to have some enhanced editing capabilites for the 
exported files from the same editor I was using to create the files. Now 
apparently I will.

How does one get one's greedy hands on the work?

Art

Re: [Visualpython-users] User survey

[Gary P. <pa...@in...>]

I think 2,3, or 4 would be acceptable, slight preference for an executive
decision, i.e., 2 or 3 rather than 4.

On the other hand, maybe we (i.e., you) should check with the greater python
communitiy and solicit opinions.  Maybe ask Guido.  They may have good
arguments.  I would prefer above all a solution that does not lead to the
installation becoming a rat's nest: if every package attaches to python a
different way, yuck.  Philosophically I agree with you about /usr vs
/usr/local, but there might be good reason to prefer consistancy over
philosophy.

-Gary


> By default, Python only searches under /usr/lib/python/site-packages for
> third-party extension modules on more than one platform, so an extension
> module installed under /usr/local/lib/python/site-packages will not be
> imported by python on these platforms.
>
> IMO, /usr belongs to the OS distributor, and local packages that are not
> installed by under the distribution's package management system (eg apt,
> rpm) should be installed under the /usr/local hirearchy.  There are
> several work-arounds that we can make in the installer, or leave it up
> to the user to fix.  Please let us know what behavior you expect from
> our source distribution.
>
> [ ] 1) Install with a default installation prefix of /usr.
> [ ] 2) Automatically extend the python module search path by appending
> to sitecustomize.py
> [ ] 3) Automatically extend the python module search path by adding a
> file named "Visual.pth" in the existing search path.
> [ ] 4) Provide instructions for the user to manually choose one of the
> above.
> [ ] 5) Something else: _____________
>
>
> Thanks for your feedback,
> Jonathan Brandmeyer
>
> P.S. Dr. Sherwood and I are leaning towards 2 and 4.
>
> Detailed descritption for extending sys.path.  Although part of the 2.3
> docs, it is completely relavant for 2.2.
>
http://www.python.org/dev/doc/devel/inst/search-path.html#SECTION00041000000
0000000000
>
> See the blurb about sitecustomize at the end.
> http://www.python.org/doc/current/lib/module-site.html
>
> See the description of sys.path.
> http://www.python.org/doc/current/lib/module-sys.html
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

[Visualpython-users] User survey

[Jonathan B. <jbr...@ea...>]

By default, Python only searches under /usr/lib/python/site-packages for
third-party extension modules on more than one platform, so an extension
module installed under /usr/local/lib/python/site-packages will not be
imported by python on these platforms.

IMO, /usr belongs to the OS distributor, and local packages that are not
installed by under the distribution's package management system (eg apt,
rpm) should be installed under the /usr/local hirearchy.  There are
several work-arounds that we can make in the installer, or leave it up
to the user to fix.  Please let us know what behavior you expect from
our source distribution.

[ ] 1) Install with a default installation prefix of /usr.
[ ] 2) Automatically extend the python module search path by appending
to sitecustomize.py
[ ] 3) Automatically extend the python module search path by adding a
file named "Visual.pth" in the existing search path.
[ ] 4) Provide instructions for the user to manually choose one of the
above.
[ ] 5) Something else: _____________


Thanks for your feedback,
Jonathan Brandmeyer

P.S. Dr. Sherwood and I are leaning towards 2 and 4.

Detailed descritption for extending sys.path.  Although part of the 2.3
docs, it is completely relavant for 2.2.
http://www.python.org/dev/doc/devel/inst/search-path.html#SECTION000410000000000000000

See the blurb about sitecustomize at the end.
http://www.python.org/doc/current/lib/module-site.html

See the description of sys.path.
http://www.python.org/doc/current/lib/module-sys.html

Re: [Visualpython-users] GtkGLExt vs GtkGLArea

[Jonathan B. <jbr...@ea...>]

Beta.  We are still working out kinks on OSX.  If you want to try on
Mandrake, that would be a good data point for us.  We know that it works
on Debian Woody and Red Hat 8.0 (with one tweek).

-Jonathan Brandmeyer

On Thu, 2003-04-03 at 08:40, Gary Pajer wrote:
> > being made. Jonathan has created a "configure"-based installer for
> > Unix/Linux systems. It works on Linux, but we're still working on issues
> for
> 
>  I happen to be installing visual on a fresh Mandrake 9.1  Not exactly
> smooth, but I'm sure I'll get there.
> What's the status of the "configure" installer?  Ready for prime time? beta?
> need a tester?
> 
> -Gary

Re: [Visualpython-users] GtkGLExt vs GtkGLArea

[Gary P. <pa...@in...>]

> being made. Jonathan has created a "configure"-based installer for
> Unix/Linux systems. It works on Linux, but we're still working on issues
for

 I happen to be installing visual on a fresh Mandrake 9.1  Not exactly
smooth, but I'm sure I'll get there.
What's the status of the "configure" installer?  Ready for prime time? beta?
need a tester?

-Gary

Re: [Visualpython-users] GtkGLExt vs GtkGLArea

[Jonathan B. <jbr...@ea...>]

I started some skeleton code using gtkglextmm a while ago.  As a new
feature, it has been on hold while we overhaul the Unix installation
tools.  If you want to look at what has been started you can look at the
files xgl2.cpp and xgl2.h in the CVS cvisual module.  We will not be
including the code in any distributions until it has been fully tested. 
You won't even get it to compile without some other patches to the
source tree.  If you want it, ask and you shall recieve.

Even after we have full support for GtkGLext, we will probably keep the
GtkGLarea code around for compatability with the slow movers (eg,
Debian).

-Jonathan Brandmeyer


On Wed, 2003-04-02 at 18:26, Arthur wrote:
> Something to consider as to VPython's future development. The quote
> below is, I believe, by the gtkglarea developer.
> 
> http://www.student.oulu.fi/~jlof/gtkglarea/
> 
> 
> """
> 
> GtkGLArea
> OpenGL widget for GTK+
> 
> GtkGLArea source can be found from cvs.gnome.org
> 
> Another OpenGL solution for GTK+: GtkGLExt is an interface to use OpenGL
> on any GTK+ widget.
> 
> I recommend that you select GtkGLExt over GtkGLArea since GtkGLExt is
> actively maintained. (It is probably technically superior too.)
> 
> """
> 
> Art
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb: 
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] GtkGLExt vs GtkGLArea

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

We too had picked up on this. We'll be keeping this in mind in a major
overhaul that Jonathan Brandmeyer is beginning to replace CXX by Boost, as
per your suggestion a while ago.

I'll take this opportunity to say that it might seem like we haven't been
keeping up on various initiatives and suggestions recently, but progress is
being made. Jonathan has created a "configure"-based installer for
Unix/Linux systems. It works on Linux, but we're still working on issues for
Mac OSX.

Bruce Sherwood

----- Original Message -----
From: "Arthur" <ajs...@op...>
To: <vis...@li...>
Sent: Wednesday, April 02, 2003 6:26 PM
Subject: [Visualpython-users] GtkGLExt vs GtkGLArea


> Something to consider as to VPython's future development. The quote
> below is, I believe, by the gtkglarea developer.
>
> http://www.student.oulu.fi/~jlof/gtkglarea/
>
>
> """
>
> GtkGLArea
> OpenGL widget for GTK+
>
> GtkGLArea source can be found from cvs.gnome.org
>
> Another OpenGL solution for GTK+: GtkGLExt is an interface to use OpenGL
> on any GTK+ widget.
>
> I recommend that you select GtkGLExt over GtkGLArea since GtkGLExt is
> actively maintained. (It is probably technically superior too.)
>
> """
>
> Art
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>

Re: [Visualpython-users] tube.py?

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

See the section of http://vpython.org labeled "Programs contributed by
users".

Bruce Sherwood

----- Original Message -----
From: "Toan T Nguyen" <nt...@uc...>
To: <vis...@li...>
Sent: Wednesday, April 02, 2003 8:38 PM
Subject: [Visualpython-users] tube.py?


>
>
> Hi, I remember sometime ago someone made a "tube.py" to draw hollow
cylinder
> but could not find the email. Can somebody send me this file? Thanks a
lot.
>
> Toan

[Visualpython-users] tube.py?

[Toan T N. <nt...@uc...>]

Hi, I remember sometime ago someone made a "tube.py" to draw hollow cylinder 
but could not find the email. Can somebody send me this file? Thanks a lot.

Toan

[Visualpython-users] GtkGLExt vs GtkGLArea

[Arthur <ajs...@op...>]

Something to consider as to VPython's future development. The quote
below is, I believe, by the gtkglarea developer.

http://www.student.oulu.fi/~jlof/gtkglarea/


"""

GtkGLArea
OpenGL widget for GTK+

GtkGLArea source can be found from cvs.gnome.org

Another OpenGL solution for GTK+: GtkGLExt is an interface to use OpenGL
on any GTK+ widget.

I recommend that you select GtkGLExt over GtkGLArea since GtkGLExt is
actively maintained. (It is probably technically superior too.)

"""

Art

[Visualpython-users] Cannot import cvisual on Mac OS X

[Brian E. G. <bgr...@cf...>]

I am trying to get VPython working on my Mac that is running OS X 
10.2.4.  I installed using the install script that is included in the 
OS X bundle of VPython.  I am running python2.2 installed using fink.
When I try "import cvisual" I get the following error:

 >>> import cvisual
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
ImportError: Failure linking new module
 >>>

Does anyone know what the problem is and how to fix it?  Thanks

Brian Granger

[Visualpython-users] Re:wrieframe polyhedron

[Arthur <ajs...@op...>]

# the previous phi3.py is now an import.  Demo is same as phi.py, but with
polyhedron in  wireframe (using edge mappings)

from phi3 import *

scene=display(background=[.7,.8,.9],autoscale=False,range=30,30,30],width=80
0,height=800)

angle=pi/100
t=[]
i=0
for tetra in tetras:
   t.append(frame())
   for edge in poly_edges(tetra):
       curve(frame=t[i],pos=edge,color=color.blue,radius=.2)
   t[i].pos=[6+6*i,6+6*i,0]
   i+=1

i=0
c=[]
for cube in cubes:
   c.append(frame())
   for edge in poly_edges(cube):
      curve(frame=c[i],pos=edge,color=color.cyan,radius=.2)
   c[i].pos=[-8-8*i,8+8*i,0]
   i+=1
o=[]
i=0
for octa in octahedrons:
   o.append(frame())
   for edge in poly_edges(octa):
       curve(frame=o[i],pos=edge,color=color.red,radius=.2)
   o[i].pos=[-8-8*i,-8-8*i,0]
   i+=1

r=[]
i=0
for rhomba in rhombics:
   r.append(frame())
   for edge in poly_edges(rhomba):
       curve(frame=r[i],pos=edge,color=color.green,radius=.2)
   r[i].pos=[8+8*i,-8-8*i,0]
   i+=1

p=frame()
for edge in poly_edges(poly120):
          curve(frame=p,pos=edge,color=color.black,radius=.1)


d=frame()
for edge in poly_edges(dodeca):
       curve(frame=d,pos=edge,color=color.magenta,radius=.2)
d.pos=[24,0,0]

i=frame()
for edge in poly_edges(isohedron):
       curve(frame=i,pos=edge,color=color.yellow,radius=.2)
i.pos=[-24,0,0]

w=frame()
for edge in poly_edges(triaconta):
       curve(frame=w,pos=edge,color=color.magenta,radius=.2)
w.pos=[0,24,0]

while 1:
   from random import random
   rate(100)
   axis=[random(),random(),random()]
   for f in t:
     f.rotate(axis=axis,angle=angle)
   axis=[random(),random(),random()]
   for f in c:
     f.rotate(axis=axis,angle=angle)
   axis=[random(),random(),random()]
   for f in o:
     f.rotate(axis=axis,angle=angle)
   axis=[random(),random(),random()]
   for f in r:
     f.rotate(axis=axis,angle=angle)
   axis=[random(),random(),random()]
   p.rotate(axis=axis,angle=angle)
   axis=[random(),random(),random()]
   d.rotate(axis=axis,angle=angle)
   axis=[random(),random(),random()]
   i.rotate(axis=axis,angle=angle)
   axis=[random(),random(),random()]
   w.rotate(axis=axis,angle=angle)

[Visualpython-users] polyhedon120 "library"

[Arthur <ajs...@op...>]

Though I'd send this along.  Its a VPython "library" of the
polyhedra derivable form the 120 Polyhedron, as per

http://www.rwgrayprojects.com/Lynn/Coordinates/coord01.html

__main__ is a little demo - sort of an explosion of the 120 Polyhedron.

Comments welcome.

Art

Re: [Visualpython-users] Additions to the next offical release?

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

We're delighted by the flurry of activity and contributions, but right at
this moment we're not in good shape to respond quickly to the opportunities
presented, because we're trying to clean up some long-standing structural
problems with installation procedures. Jonathan is making rapid progress on
a autoconfig approach for Linux/Unix platforms which promises to solve a
host of nagging problems. When our basic house is in order we'll catch our
breaths and try to fold into Visual the good contributions that have
recently been offered. I'll also reiterate that Jonathan very much wants to
change from CXX to Boost, as Arthur Siegel alerted us to, which would make
it both easier for people to make contributions and easier to manage the
inputs.

Another answer is that there isn't really any formal mechanism in place for
what goes into the "official" package, because until very recently there
hadn't been any contributions to consider!

Bruce Sherwood

----- Original Message -----
From: "Press, Shaun" <sha...@ai...>
To: <vis...@li...>
Sent: Tuesday, March 18, 2003 11:20 PM
Subject: [Visualpython-users] Additions to the next offical release?


> It looks as though there is a bit of extra development work going into the
> current release of VPython, which is to be expected for any good open
source
> package. At the same time it also seems people are "rolling their own",
> which is also to be expected. Is their a mechanism for deciding which mods
> and additions might make it into the next official release? Bruce,
Jonathan,
> anyone?

[Visualpython-users] Additions to the next offical release?

[Press, S. <sha...@ai...>]

It looks as though there is a bit of extra development work going into the
current release of VPython, which is to be expected for any good open source
package. At the same time it also seems people are "rolling their own",
which is also to be expected. Is their a mechanism for deciding which mods
and additions might make it into the next official release? Bruce, Jonathan,
anyone?

Re: [Visualpython-users] small "feature" request

[Jonathan B. <jbr...@ea...>]

To add that attribute, everything should be done in pvector.cpp, and maybe a
little in pvector.h.
You will need to change Vector::init_type, Vector::get_attr, possibly
Vector::set_attr to report that you cannot assign to that attribute, and
possibly a member function to construct the right return to python.

Note that the return to python should be wrapped around FromAPI() aka
asObject () (see CXX/Include/CXX_Objects.h for some documentation).

I don't know if there is more to it than simply printing or returning a
string, you will have to look at other stuff to figure out the solid way to
get the job done.

Don't worry about immutableVector.  It is used internally to have the effect
of a 'const Vector'.  All it's properties and methods are obtained through
public inheritance of Vector, and an override of set_attr that always
reports that you cannot change the attributes.  Thanks to polymorphism, from
python, they look just like a const Vector.

Good luck,
Jonathan

P.S.  Please don't CC me directly, I read the list.

----- Original Message -----
From: <ajsiegel at optonline dot net>
Sent: Tuesday, March 18, 2003 12:23 PM
Subject: [Visualpython-users] small "feature" request


> The fact that the VPython vector object has no __class__ attribute seems
inconsistent with the current status of Python objects.Happens that it is
creating a practical problem in something I am attempting.
>
> The issue is illustrated as  follows:
>
> >>> from visual import *
> Visual-2003-03-15
> >>> lis = [1,2,3]
> >>> tup =(1,2,3)
> >>> vec = vector(1,2,3)
> >>> lis.__class__
> <type 'list'>
> >>> tup.__class__
> <type 'tuple'>
> >>> vec.__class__
> Traceback (most recent call last):
>   File "<pyshell#6>", line 1, in ?
>     vec.__class__
> AttributeError: __class__
>
> If I am not mistaken, the __class__ attributte of lists and tuples did not
exist at the time VPython was originally written.  So at that time, it was
consistent.  The change I have in mind would, I think, bring the vector obje
ct more in line with the type/class unification scheme to which Python has
moved.
>
> I have not - at this point - looked at the VPython code in this regard.
But assume it is a minor patch.
>
> My problem is, assuming that I can do the patch myself, I need to know
that what I am doing using it  will ultimately work with the official
distributiion.

[Visualpython-users] small "feature" request

[<ajs...@op...>]

The fact that the VPython vector object has no __class__ attribute seems inconsistent with the current status of Python objects.Happens that it is creating a practical problem in something I am attempting.

The issue is illustrated as  follows:

>>> from visual import *
Visual-2003-03-15
>>> lis = [1,2,3]
>>> tup =(1,2,3)
>>> vec = vector(1,2,3)
>>> lis.__class__
<type 'list'>
>>> tup.__class__
<type 'tuple'>
>>> vec.__class__
Traceback (most recent call last):
  File "<pyshell#6>", line 1, in ?
    vec.__class__
AttributeError: __class__

If I am not mistaken, the __class__ attributte of lists and tuples did not exist at the time VPython was originally written.  So at that time, it was consistent.  The change I have in mind would, I think, bring the vector object more in line with the type/class unification scheme to which Python has moved.

I have not - at this point - looked at the VPython code in this regard.  But assume it is a minor patch.

My problem is, assuming that I can do the patch myself, I need to know that what I am doing using it  will ultimately work with the official distributiion.

So.....

Art

[Visualpython-users] MacOSX tester wanted

[Jonathan B. <jdb...@un...>]

We are looking for a MacOS X owner to help test a new installer for VPython
on Unix-like systems.
The new installer is based on autoconf and automake.  Since it is a
significant departure from our previous installation methods, we want to
thoroughly test the scripts before releasing them into the wild.
System requirements:
    MacOSX
    Gtk+ 1.2 or higher with header files
    GtkGLArea with header files
    GThreads, with header files
    python 2.2 or higher with header files
    pkg-config

Developer requirements:
    Know enough to be able to fix your installation of VPython if this one
trashes it.
    Be familiar with the configure && make routine.

If you want to help us test the new installer, please send e-mail to
jbr...@us....  I will send e-mail you the package
(500K).

Thanks,
Jonathan Brandmeyer

Re: [Visualpython-users] new files

[<ba...@ph...>]

Maybe I can add a few more arguments to this:
Imagine you wrote a module which does some computation
(say 1-3 mins) and then you would like to explore the results,
eg. plot some data. This is much more easily done with
an interactive session than using the editor and run
(because you do not know yet how the output looks like).
For example I use IPython (http://www-hep.colorado.edu/~fperez/ipython/)
a lot which has many nice features (TAB completion, session logging,
macros, colored exception traceback, is embeddable, easy access
to gnuplot, etc. etc. ...)

I think that this approach (together with embedding IPython) is
great for debugging.

A bit off-topic: did you manage to solve
the problems with sockets and idle(fork) ?
((I brought this question up on the idlefork mailing list,
but did not get any response ;-))

Arnd


On Sun, 16 Mar 2003, Arthur wrote:

> > Arthur, you may be in a position to clear up something for me. Evidently
> > you, like many other users of Python, find it convenient/useful/natural to
> > do these little explorations in the shell rather than typing
> >
> > import cmath
> > print dir(cmath)
>
> Probably not much more to it than instant gratification, or flow, or
> whatever you might want to call it.  At the prompt, I feel myself to be in
> inquiry, exploration, and experiment mode.
>
> Even though there is no compile cycle in Python, there is a "run" cycle when
> working from script. And I associate a certain amount of  formality with
> working in that mode.
>
> Working at the prompt has a flow to it that can become something of a
> dialogue with the language, in some sense.
>
> All a little soft, as an explanation.  But as you say, I think I am not at
> all unusual in using the interactive prompt in this manner.
>
> Art
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now open!
> Get cracking and register here for some mind boggling fun and
> the chance of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

Re: [Visualpython-users] new files

[Arthur <ajs...@op...>]

> Arthur, you may be in a position to clear up something for me. Evidently
> you, like many other users of Python, find it convenient/useful/natural to
> do these little explorations in the shell rather than typing
>
> import cmath
> print dir(cmath)

Probably not much more to it than instant gratification, or flow, or
whatever you might want to call it.  At the prompt, I feel myself to be in
inquiry, exploration, and experiment mode.

Even though there is no compile cycle in Python, there is a "run" cycle when
working from script. And I associate a certain amount of  formality with
working in that mode.

Working at the prompt has a flow to it that can become something of a
dialogue with the language, in some sense.

All a little soft, as an explanation.  But as you say, I think I am not at
all unusual in using the interactive prompt in this manner.

Art

Re: [Visualpython-users] new files

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

Arthur, you may be in a position to clear up something for me. Evidently
you, like many other users of Python, find it convenient/useful/natural to
do these little explorations in the shell rather than typing

import cmath
print dir(cmath)

into an edit window and hitting F5. Why is this? I feel much more
comfortable in an edit window, where the full history and context is clear
(including the import status), and where I can easily make modifications to
try a change after the first try.

Bruce Sherwood

----- Original Message -----
From: "Arthur" <ajs...@op...>
To: "Bruce Sherwood" <bas...@un...>; "vpusers"
<vis...@li...>
Sent: Sunday, March 16, 2003 3:39 PM
Subject: Re: [Visualpython-users] new files


> Thinking about it though, beyond the "political" issues, IDLE is probably
a
> better solution than ScITE for a standalone environment.  I do think that
> both an interactive prompt, and an editing environment are necessary.
ScITE
> is only an editor.  I think of this in the context of documentation,
because
> I am actually more likely to do something like:
>
> Python 2.2.2 (#37, Nov 26 2002, 10:24:37) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> IDLE 0.8 -- press F1 for help
> >>> import cmath
> >>> dir(cmath)
> ['__doc__', '__name__', 'acos', 'acosh', 'asin', 'asinh', 'atan', 'atanh',
> 'cos', 'cosh', 'e', 'exp', 'log', 'log10', 'pi', 'sin', 'sinh', 'sqrt',
> 'tan', 'tanh']
>
> then I am to access the html docs, at least as a first step, in trying to
> get a handle on some specific area of Python.
>
> Of course there is always the cmd prompt, which isn't hideous on XP.  But
I
> do much prefer IDLE for interactive experimentation, and the like.
>
> Art

Re: [Visualpython-users] new files

[Arthur <ajs...@op...>]

> In the latest Windows installer the VPython index.html is in
> Lib\site-packages\visual\docs. It has a link to the local Python
> documentation, because it is present in the standard Python Windows
> distribution; I see no reason to link to the web except in the possible
> context of a stripped-down Python that didn't include documentation.

I agree.

But this is my intended solution specifically as to a stand-alone
environment that would not include the Python documentation locally.

Thinking about it though, beyond the "political" issues, IDLE is probably a
better solution than ScITE for a standalone environment.  I do think that
both an interactive prompt, and an editing environment are necessary.  ScITE
is only an editor.  I think of this in the context of documentation, because
I am actually more likely to do something like:

Python 2.2.2 (#37, Nov 26 2002, 10:24:37) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.8 -- press F1 for help
>>> import cmath
>>> dir(cmath)
['__doc__', '__name__', 'acos', 'acosh', 'asin', 'asinh', 'atan', 'atanh',
'cos', 'cosh', 'e', 'exp', 'log', 'log10', 'pi', 'sin', 'sinh', 'sqrt',
'tan', 'tanh']

then I am to access the html docs, at least as a first step, in trying to
get a handle on some specific area of Python.

Of course there is always the cmd prompt, which isn't hideous on XP.  But I
do much prefer IDLE for interactive experimentation, and the like.

Art

Re: [Visualpython-users] new files

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

We do use sourceforge for CVS, bug tracking, etc., all aimed at developer
needs. But it seemed better to put the user-oriented web site vpython.org
somewhere else.

Bruce Sherwood

----- Original Message -----
From: "Steve Spicklemire" <st...@sp...>
To: "Bruce Sherwood" <bas...@un...>
Cc: "Steve Spicklemire" <st...@sp...>; "vpusers"
<vis...@li...>
Sent: Sunday, March 16, 2003 2:45 PM
Subject: Re: [Visualpython-users] new files

> Is the VPython group interested in the possibility of using something
> like sourceforge? The vpython.org site could just be a reference point,
> but most "real" development could happen on sourceforge.net. That gets
> you an instant array of mirrored worldwide servers, plus CVS, plus easy
> developer/documentation management, etc..