visualpython-users

[Visualpython-users] Macintosh update

[David A. <dm...@an...>]

I've brought the Macintosh version on our Web site up to date.

Re: [Visualpython-users] VRML Export

[David A. <dm...@an...>]

I've brought the Macintosh version on our Web site up to date.

Re: [Visualpython-users] VRML Export

[ruth c. <rc...@an...>]

Very cool!  We'll definitely add it to the VPython website.

What's a good VRML viewer for windows?  I downloaded one at random 
(cortona) but find it somewhat unintuitive.

	Ruth Chabay

--On Monday, July 16, 2001 12:34 AM -0400 Michael Zadok Katzhyman 
<mz...@an...> wrote:

> Everyone,
>
> Attached is a python module, based on povexport, which will export a
> VPython scene into VRML97 (2.0).  Feel free to integrate this into the
> VPython package and/or post on the VPython webpage.
>
> Everything is implemented except convex objects, text, textures, lighting,
> and camera positions.  Right now curves look like crap and I think I'll
> need to come up with some interpolation code.  Arrows are currently
> implemented as cylinders and cones instead of boxes and pyramids.  VRML
> has no primative for toruses (rings) but the code uses extrusions to make
> a torus (the only problem being rendering is slower since an extrusion is
> madup of a bunch of smaller shapes).
>
> Included in the file are routines to convert axis/angle rotations to
> quaternions (originally I was planning to implement them to combine
> rotations) and I have left them in there for future use.
>
> The code is call-compatible with povexport, if you pass an inc list to it
> it will ignore it (same with the Shadowless flag).  The only thing you
> haev to cahnge is the import string from "import povexport" to "import
> vrmlexport" and the calling code from "povexport.export(..." to
> "vrmlexport.export(..."
>
> The code itself has been tested on a couple of the demos, the
> electromagnetic wave problem from 33-132 at CMU, and a VPython model of
> the G0 Detector being installed at Jefferson Lab (I wrote this myself and
> it included nested frames with rotations and was what I used to initially
> test my code).
>
> VRML can be easily imported to other 3D rendering software
> (and then back into povray, I think).  Also VRML can be embedded in
> webpages which might be good for class webpages, etc.
>
> Cheers,
> Michael Katz-Hyman

Re: [Visualpython-users] VRML Export

[Michael Z. K. <mz...@an...>]

One thing I forgot to mention is that the code currently does not support
frame's with an axis other then the default. It will work but with
unexpected results.  Rotations are only supported with frames when
rotating it's position, not its orientation.  I am working on the
solution.

-Michael

On Mon, 16 Jul 2001, Michael Zadok Katzhyman wrote:

> Everyone,
> 
> Attached is a python module, based on povexport, which will export a
> VPython scene into VRML97 (2.0).  Feel free to integrate this into the
> VPython package and/or post on the VPython webpage.
> 
> Everything is implemented except convex objects, text, textures, lighting,
> and camera positions.  Right now curves look like crap and I think I'll
> need to come up with some interpolation code.  Arrows are currently
> implemented as cylinders and cones instead of boxes and pyramids.  VRML
> has no primative for toruses (rings) but the code uses extrusions to make
> a torus (the only problem being rendering is slower since an extrusion is
> madup of a bunch of smaller shapes).
> 
> Included in the file are routines to convert axis/angle rotations to
> quaternions (originally I was planning to implement them to combine
> rotations) and I have left them in there for future use.
> 
> The code is call-compatible with povexport, if you pass an inc list to it
> it will ignore it (same with the Shadowless flag).  The only thing you
> haev to cahnge is the import string from "import povexport" to "import
> vrmlexport" and the calling code from "povexport.export(..." to
> "vrmlexport.export(..."
> 
> The code itself has been tested on a couple of the demos, the
> electromagnetic wave problem from 33-132 at CMU, and a VPython model of
> the G0 Detector being installed at Jefferson Lab (I wrote this myself and
> it included nested frames with rotations and was what I used to initially
> test my code).
> 
> VRML can be easily imported to other 3D rendering software
> (and then back into povray, I think).  Also VRML can be embedded in
> webpages which might be good for class webpages, etc.
> 
> Cheers,
> Michael Katz-Hyman
> 

[Visualpython-users] VRML Export

[Michael Z. K. <mz...@an...>]

Everyone,

Attached is a python module, based on povexport, which will export a
VPython scene into VRML97 (2.0).  Feel free to integrate this into the
VPython package and/or post on the VPython webpage.

Everything is implemented except convex objects, text, textures, lighting,
and camera positions.  Right now curves look like crap and I think I'll
need to come up with some interpolation code.  Arrows are currently
implemented as cylinders and cones instead of boxes and pyramids.  VRML
has no primative for toruses (rings) but the code uses extrusions to make
a torus (the only problem being rendering is slower since an extrusion is
madup of a bunch of smaller shapes).

Included in the file are routines to convert axis/angle rotations to
quaternions (originally I was planning to implement them to combine
rotations) and I have left them in there for future use.

The code is call-compatible with povexport, if you pass an inc list to it
it will ignore it (same with the Shadowless flag).  The only thing you
haev to cahnge is the import string from "import povexport" to "import
vrmlexport" and the calling code from "povexport.export(..." to
"vrmlexport.export(..."

The code itself has been tested on a couple of the demos, the
electromagnetic wave problem from 33-132 at CMU, and a VPython model of
the G0 Detector being installed at Jefferson Lab (I wrote this myself and
it included nested frames with rotations and was what I used to initially
test my code).

VRML can be easily imported to other 3D rendering software
(and then back into povray, I think).  Also VRML can be embedded in
webpages which might be good for class webpages, etc.

Cheers,
Michael Katz-Hyman

RE: [Visualpython-users] Problems with current version

[David S. <dsc...@vy...>]

This code in cxx_extensions.cxx appears to (incorrectly) check only the
major version of Python (I believe these two features were added in
Python 2.1, not 2.0):

#if PY_MAJOR_VERSION < 2
	table->tp_xxx7 =3D 0L;
	table->tp_xxx8 =3D 0L;
#else
	table->tp_richcompare =3D 0;
	table->tp_weaklistoffset =3D 0;
#endif

I can't test this, but probably it should read something like

#if PY_MAJOR_VERSION < 2 || PY_MINOR_VERSION < 1

Dave

> -----Original Message-----
> From: vis...@li...=20
> [mailto:vis...@li...] On=20
> Behalf Of Herr Wagner
> Sent: Saturday, July 14, 2001 7:48 AM
> To: vis...@li...
> Subject: [Visualpython-users] Problems with current version
>=20
>=20
> I have used the most recent version of vpython.=20
> Unfortunately, a make doesn't work.
>=20
> This is the message produced by make.
>=20
> g++ -O3 -I. -I./CXX/Include -I/usr/include/python2.0=20
> g++ -I/usr/include/python2.0/Numeric `gtk-config --cflags gtk=20
> gthread` -w -c CXX/Src/cxx_extensions.cxx -o CXX/Src/cxx_extensions.o
> CXX/Src/cxx_extensions.cxx: In method=20
> `Py::PythonType::PythonType(unsigned int,
> int)':
> CXX/Src/cxx_extensions.cxx:246: `struct _typeobject' has no=20
> member named `tp_richcompare'
> CXX/Src/cxx_extensions.cxx:247: `struct _typeobject' has no=20
> member named `tp_weaklistoffset'
> make: *** [CXX/Src/cxx_extensions.o] Error 1
>=20
> Is there anyone who can help ?
>=20
> Thanks in advance.
>=20
>  Nils=20
> --=20
>=20
> Die sch=F6nen Seiten des Urlaubs bei Libri.de: Sonnige B=FCcher=20
> portofrei bestellen: http://www.libri.de/content/urlaub.html
>=20
> _______________________________________________
> Visualpython-users mailing list=20
> Vis...@li...
> http://lists.sourceforge.net/lists/listinfo/visualpython-users
>=20

[Visualpython-users] Problems with current version

[Herr W. <nil...@fr...>]

I have used the most recent version of vpython. Unfortunately, a make doesn=
't work.

This is the message produced by make.

g++ -O3 -I. -I./CXX/Include -I/usr/include/python2.0 -I/usr/include/python2=
.0/Numeric `gtk-config --cflags gtk gthread` -w -c CXX/Src/cxx_extensions.c=
xx -o CXX/Src/cxx_extensions.o
CXX/Src/cxx_extensions.cxx: In method `Py::PythonType::PythonType(unsigned =
int,
int)':
CXX/Src/cxx_extensions.cxx:246: `struct _typeobject' has no member named `t=
p_richcompare'
CXX/Src/cxx_extensions.cxx:247: `struct _typeobject' has no member named `t=
p_weaklistoffset'
make: *** [CXX/Src/cxx_extensions.o] Error 1

Is there anyone who can help ?

Thanks in advance.

 Nils=20
--=20

Die sch=F6nen Seiten des Urlaubs bei Libri.de: Sonnige B=FCcher portofrei b=
estellen: http://www.libri.de/content/urlaub.html

[Visualpython-users] new demo

[Bruce S. <ba...@an...>]

On the Windows download page at http://cil.andrew.cmu.edu/projects/visual 
is a new demo zip file that includes an improved version of 
doublependulum.py.

The original version had two pendulums unphysically interpenetrating each 
other. The new version is a device that actually exists.

Bruce Sherwood

[Visualpython-users] More fixes

[Bruce S. <ba...@an...>]

New DLL and new VPython for Windows at 
http://cil.andrew.cmu.edu/projects/visual

Recently I discovered that large coordinates (bigger than about 1e45) were 
not handled correctly. This broke when we went from Python 1.5 to Python 
2.0 but wasn't noticed until now. (A program that worked last December 
didn't work any more.)

David Scherer suggested changing floats to doubles in some critical parts 
of Visual. David Andersen tried this and found that it indeed fixes the 
problem.

It turns out that this also fixes a seemingly unrelated problem that crept 
in with Python 2.0. The demo programs wave.py and drape.py sometimes 
flickered, putting a curve endpoint momentarily at the upper right corner 
of the window. This bug is now gone.

Our best guess, but it is only a guess at this time, is that some aspect of 
the Numeric module changed with the change to Python 2.0, in a way that 
affected Visual, which uses Numeric arrays in various ways.

Bruce Sherwood

[Visualpython-users] Minor change

[Bruce S. <ba...@an...>]

Update at http://cil.andrew.cmu.edu/projects/visual for Windows.

The fix to updating a convex object could fail under certain conditions. 
David Andersen plugged the hole.

Bruce Sherwood

P.S. For a few hours today there was an incorrect DLL on the web site, 
dated 07-09. If you installed it, do get the 07-10 version.

Re: [Visualpython-users] New stuff

[Markus G. <gr...@iu...>]

QnJ1Y2UgU2hlcndvb2Qgd3JvdGU6DQoNCj4gTnVtZXJpYzogYWRkZWQgdGhlIE51bWVyaWMg
Ki5oIGZpbGVzIHRvIFB5dGhvbjIxXGluY2x1ZGUNCg0KSSBkb24ndCB0aGluayB0aGV5IHNo
b3VsZCBwb2xsdXRlIFB5dGhvbnMgaW5jbHVkZS1kaXIsIGJ1dCBJJ20gbm90IHN1cmUuDQoN
Ck1hcmt1cw0KDQo=

[Visualpython-users] New stuff

[Bruce S. <ba...@an...>]

New VPython for Windows available at 
http://cil.andrew.cmu.edu/projects/visual.

Ruth Chabay and I fixed a bug in the convex object. Formerly, if you 
changed one or more points in the pos list by direct calculations on the 
array, the display was not updated. Thanks to David Scherer for explaining 
what we had to do. Also made a tiny change so that the default title of a 
window is "VPython" rather than the old name "Visual Python".

You can get this fix to an existing VPython 2.1 simply by downloading the 
DLL.

Various other minor updates:

Demos: deleted a no-longer-necessary line from convex.py
Numeric: added the Numeric *.h files to Python21\include
Visual: updated the date in __init__.py (which you see when you run)
Source files: updates to convex.cpp and a few others, including the project 
file
Install scripts: updated

Bruce Sherwood

RE: [Visualpython-users] Wireframe

[David S. <dsc...@vy...>]

There is not currently a throw switch for wireframe rendering.  If you
are willing to do a bit more work, you can build your own wireframes
with curves (and even manipulate then as if they were primitives, using
frame).

Dave

> -----Original Message-----
> From: vis...@li... 
> [mailto:vis...@li...] On 
> Behalf Of David Andersen
> Sent: Monday, July 09, 2001 6:40 AM
> To: Vis...@li...
> Subject: Re: [Visualpython-users] Wireframe
> 
> 
> There currently is no way to do this.
> 
> 
> 
> _______________________________________________
> Visualpython-users mailing list 
> Vis...@li...
> http://lists.sourceforge.net/lists/listinfo/visualpython-users
> 

Re: [Visualpython-users] Wireframe

[Ari H. <ahe...@an...>]

On Mon, 9 Jul 2001, David Andersen wrote:

> There currently is no way to do this.

would have been easy to add when things were still rendered with GLUT :)

wouldn't be that terribly hard now.


ari

Re: [Visualpython-users] Wireframe

[David A. <dm...@an...>]

There currently is no way to do this.

[Visualpython-users] Wireframe

[Michael Z. K. <mz...@an...>]

Everyone,

Is there a way to have objects drawn as a wireframe instead of being
filled in?  

-Michael

[Visualpython-users] New releases

[Bruce S. <ba...@an...>]

There is a new DLL and VPython for Windows, and a new package for the Mac, 
to fix the problem reported by Arthur Siegel and Ruth Chabay. Fix by David 
Andersen.

Bruce Sherwood

Re: [Visualpython-users] povexport and New VPython

[Arthur S. <aj...@ix...>]

Ruth - 

Thanks  - but half a shucks.  I had proudly tracked 
it down and reported a fix - but my message - 
below didn't post up for some reason.

>Further to my prior post re: povexport.

>The issue seems to be that in curve_export the
>a.color[ii] is an array and the constructor wants
>a list.  Sounds familiar as to the core problems
>related to the VPython compatibilities with 
>Python2.1 which I overheard on the list.

>But a.color[ii].tolist() seems to work as a quick
>fix at least.  And I have yet to run into any other
>problems related to the phenom.

>ART

Nonetheless I shall download the official povexport.

Thanks particularly for doing povexport.  By my lights
as important contribution to VPython.

ART

----- Original Message ----- 
From: "ruth chabay" <rc...@an...>
To: <Art...@rs...>; <vis...@li...>
Sent: Saturday, June 23, 2001 2:29 PM
Subject: Re: [Visualpython-users] povexport and New VPython


> Yes, this is reproducible; thanks for reporting it.  
> There is a new version of povexport.py on the web site that contains a
> workaround, as well as a change by Markus Gritsch to allow "shadowless=1"
> as a keyword in the export function.
> 
> (The error is caused by attempting to assign an array to object.color -
> apparently this is no longer allowed.)
> 
> Ruth
> 

Re: [Visualpython-users] povexport and New VPython

[ruth c. <rc...@an...>]

Yes, this is reproducible; thanks for reporting it.  
There is a new version of povexport.py on the web site that contains a
workaround, as well as a change by Markus Gritsch to allow "shadowless=1"
as a keyword in the export function.

(The error is caused by attempting to assign an array to object.color -
apparently this is no longer allowed.)

	Ruth

--On Friday, June 22, 2001, 6:54 PM -0500 Art...@rs... wrote:

> On running and clicking on povexample.py I get:
> 
> Traceback (innermost last)
>   File "c:\python21\programs\demos\povexample.py", line 46, in ?
>     code = povexport.export(display=scene, include_list = inclist)
>   File "c:\python21\programs\demos\povexport.py", line 334, in export
>     object_code = function(obj)
>   File "c:\python21\programs\demos\povexport.py", line 157, in
>   export_curve frame=a.frame, visible=0)
> TypeError: function not supported for these types, and can't coerce to 
> supported types
> 
> a)  Does this problem duplicate for others.
> 
> b) If so, anybody have a clue??
> 
> c) Notice tangentially that I get another level of traceback when I run
> it in  my usual
> text editor 
>     "c:\python21\visual\__init__py  line 58 in __call__
>         return apply(self.constr, args, kw)"
> That seems to be where the bounce out is.
> 
> Thanks for any help.
> 
> In the mean time I shall play.
> 
> ART
> 
> 
> ART
> 
> 
> 
> 
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> http://lists.sourceforge.net/lists/listinfo/visualpython-users

[Visualpython-users] povexport and New VPython

[<Art...@rs...>]

First the good news -  

Could be my imagination, but there seems to me to be a *significant*
boost in performance with VPython running on Python21 and 
related Numeric.

Then the less than good - 

On running and clicking on povexample.py I get:

Traceback (innermost last)
  File "c:\python21\programs\demos\povexample.py", line 46, in ?
    code = povexport.export(display=scene, include_list = inclist)
  File "c:\python21\programs\demos\povexport.py", line 334, in export
    object_code = function(obj)
  File "c:\python21\programs\demos\povexport.py", line 157, in export_curve
    frame=a.frame, visible=0)
TypeError: function not supported for these types, and can't coerce to 
supported types

a)  Does this problem duplicate for others.

b) If so, anybody have a clue??

c) Notice tangentially that I get another level of traceback when I run it in 
my usual
text editor 
    "c:\python21\visual\__init__py  line 58 in __call__
        return apply(self.constr, args, kw)"
That seems to be where the bounce out is.

Thanks for any help.

In the mean time I shall play.

ART


ART

[Visualpython-users] Mac minor corrections

[Bruce S. <ba...@an...>]

Minor corrections to the VPython download for the Mac. The file describing 
how to install was not included (it was always on the web site), and there 
were some misdirections in an html documentation file. These were old 
errors.

Bruce

Re: [Visualpython-users] VPythonMac for Python 2.1

[Dethe E. <de...@al...>]

on 01/6/22 05:58 AM, David Andersen at dm...@an... wrote:

> I've updated our web site with VPythonMac-2001-06-22 for Macintosh Python
> 2.1.
> 

Excellent.  With this (and removing a dependency on mxTools -- tired of
struggling with it), I can work entirely in 2.1 now.  Thank you!

-- 

Dethe Elza 
Chief Mad Scientist
Burning Tiger Technologies

[Visualpython-users] VPythonMac for Python 2.1

[David A. <dm...@an...>]

I've updated our web site with VPythonMac-2001-06-22 for Macintosh Python 
2.1.

[Visualpython-users] RE: [Edu-sig] Python Shell - was: RE: IDLE's save-before-run r equirement

[Kirby U. <pd...@te...>]

At 10:57 AM 6/21/2001 -0500, Patrick K. O'Brien wrote:
>Well, the current IDLE is 0.8. So any difference in the Shell
>capability between 0.5 and 0.8 are going to show up.

Absolutely.  But we're just comparing IDLE with itself --
it's not a whole other IDE/shell with VPython, like Pythonwin,
Boa or whatever.

I think ideally the standard IDLE will run user programs in
a different thread (what VPython's version does) and at that
point VPython might be able to stop doing a whole separate
IDLE.  That would seem an appropriate division of labor to
me (let the VPython team get out of the IDE business -- what
a recent post said was happening anyway, owing to time
constraints).  It was just extra work for them, to have to
go to the trouble of doing a separate version of IDLE.

I agree with Kurt B. Kaiser:  IDLE is great IDE to include
in the standard distro and there should *not* be some attempt
to rip out its guts in favor of some Scintilla-based thing
or whatever.  It's too far along, and works too well, to
be overhauled in such a fundamental way.  Tweek the key
bindings and some other things maybe.  Improve it
incrementally.  But don't overhaul from the ground up.

Too bad for Mac users that Tk is broken on that platform.
Maybe this will change with the newer UNIX-based OS?

I think at the heart of the issue is that Python, as a language,
is not GUI-centric, i.e. there's not GUI built in.  What you
have are wrapper/APIs around other languages for your GUI frames
and widgets, be that GNOME, Tk or Microsoft Foundation Classes
(Windows widgets).

In contrast, Java has its own native cross-platform AWT/Swing
classes, so it makes sense to write a Java IDE in pure Java.
The Java language isn't wrapping around something else (yes,
there are peer classes pairing the Java to platform-specific
implementations -- but this isn't the same thing (we're still
'thinking in Java' all the way down to button size and color)).

So when we talk Python IDE, we're talking Python + Something,
and there's no one other language that Python is "best" designed
to work with.  Because Python is ideally suited as a glue language,
which means, by definition, it gets along pretty well with a lot
of others.  So the "one way to do it" concept is coming up against
the "versatile glue language" concept, and I think in the case of
IDEs, it's the versatility that wins.

There's no reason to have just one IDE (certainly that's not
the case in Java world either, or many other worlds -- any
number (and they don't have shell mode because Java, like C,
like Pascal, is not interactive).  However, it is arguable
that there should be one IDE that ships standard with Python
under the same license agreement.  IDLE is currently that IDE,
and I think should continue in that role.

As for everyone standardizing on the same "right" IDE for
their own development work:  it ain't never going to happen,
nor should it.  IDLE is great for learning, has a bright
future in the classroom (where Python is catching on).  But
it doesn't need to be "the" IDE, even if it's the one that
ships as the default, as part of the standard distro (same
with Linux GUIs -- KDE, Gnome... there's no "one right
interface" there either).  It's only in the imperial paradigm
that we standardize at this level (closer to the Microsoft
model).

Kirby

[Visualpython-users] Python Shell - was: RE: IDLE's save-before-run r equirement

[Patrick K. O'B. <po...@or...>]

Thank you, Guido, for bearing with me on this whole issue. I think we are
getting to the heart of the matter. Because I, too, am an instant
gratification person. So let's just talk about the Python Shell
(interactive) capabilities as they exist in the various IDEs. I will attempt
to explain my take on this situation, what bothers me, and what I'd like to
see happen.

The four tools under discussion. IDLE, Boa, PythonWin and VPython all have a
Python Shell capability. But they all vary in their support of keybindings,
coloring, indenting, etc. When someone uses all of these tools and makes use
of each Shell, they have to keep in mind all the variations that exist. This
is counter-productive and takes away from what should be "instant
gratification at all times." I would rather have a common feature set within
all Shells, even if it meant giving up features, rather than have the
variations that exist now. I would like to see the Python Shell exist as
some kind of plug-in or shared code base that all the IDEs could use so that
the Python Shell was uniform in all tools on all platforms. I think this
fits the Python philosophy and would make life a lot easier for beginners as
well as experts. It would also make the Shell available for new,
special-case tools that have been discussed, such as a Python Tutor or
Python Trivial Pursuit game, where the variations would be solely within the
value-add portions and not the fundamental Shell capability (and without
creating yet more forks).

Here are some specific examples of the variations that bother me (Please
don't anyone take offense at these comparisons. I believe they are all
objective, demonstrable differences and not just my opinion, though I am
clearly opinionated. And if I'm wrong about any of this please let me
know.):

PYTHONSTARTUP: IDLE and VPython support it with the -s command line switch.
Boa will have this feature in the next release (because I asked for it).
PythonWin has no support whatsoever for PYTHONSTARTUP to my knowledge.

Home key: Type a line of code at the shell prompt (>>>) and then hit the
Home key. PythonWin puts the cursor in front of your code (very nice). IDLE
and VPython put the cursor in front of the prompt and then beep when you try
to continue typing (yuck). Boa puts the cursor in front of the prompt and
lets you type over the prompt. When you hit enter it truncates the first
four characters from what you typed and tries to execute that (big yuck). I
use this feature a lot in PythonWin when I'm copying previous lines down and
want to get to the beginning of the line to add more code, like assigning to
a variable or some such. When I switch to one of the other tools I have to
do Home, Right, Right, Right, Right - way too many keystrokes.

Command history: IDLE and VPython have Alt-P (previous) and Alt-N (next),
which is very nice. PythonWin has a way to add these bindings, but by
default has Ctrl-Up and Ctrl-Down (just to be different?). I don't know how
to add the PythonWin bindings to IDLE or VPython. Boa has no command
history.

Call tips: PythonWin has the best as far as showing what is in a module.
IDLE/VPython have the best as far as showing function parameters and
docstrings. Boa is way behind.

Win32All: PythonWin is the only tool that can deal with the win extensions,
like dde or com. This is a major pain. There are times when I'd love to use
IDLE but since I'm developing a Windows app that requires DDE I can only use
PythonWin. (And I don't really understand why this is but it definitely
irritates me to no end.)

I'm sure there are other differences, but these are good enough to get my
point across. So I will finish with a question - What, if anything, can be
done about this situation, or am I barking up the wrong tree?

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: gu...@cj...
[mailto:gu...@cj...]On Behalf Of Guido van Rossum
Sent: Thursday, June 21, 2001 7:41 AM
To: ala...@bt...
Cc: is...@li...; po...@or...; ma...@la...;
idl...@py...; Ed...@py...; tu...@py...
Subject: Re: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run r
equirement

> > What would switching over to using Scintilla accomplish that
> > sticking with IDLE and continuing it's development wouldn't?
>
> In a word "Reuse". That means one editor to maintain for most
> of the Python IDEs. Add a feature to Scintilla and its pretty
> trivial for all the IDEs to pick up the new feature without
> having to reimplemnent it from scratch. Effort gets concentrated
> on the value add bits rather than the nitty gritty of text editing.

But IDLE has a bunch of requirements that I don't think Scintilla can
provide.  IDLE has really two editing modes: the regular module/file
editor, and the "Python Shell".  IDLE's most redeeming feature, IMO,
is the Python Shell.  Compare editing an interactive session in
PythonWin's console window with IDLE's Python Shell.  IMO again, IDLE
is infinitely better, because it uses the exact same editing features
as the module/file editor, meaning you get proper syntax coloring,
automatic indentation, call tips, magic expansion; and on top of that
you get per-line syntax checking, whole-command editing, and history
recall.  In PythonWin's much more primitive console, it's very easy to
mess up the input or the output or confuse the auto-indenter.

(I'm an instant gratification person, so Python's interactive mode is
very important to me.)

I could be wrong about Scintilla not supporting this, but if it did,
why would PythonWin not use it for *its* console?

--Guido van Rossum (home page: http://www.python.org/~guido/)