Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
Perhaps there are two separable issues. Many of us see it as extremely
important that some IDLE be part of the standard Python distribution
("batteries included"), for the reasons that several people have given.
However, there is merit to the suggestion to have an active separate
development, with the understanding that periodically this separate
development is a candidate for inclusion in the standard distribution,
replacing whatever IDLE had been there.
In the 2009 Google Summer of Code I was the mentor for a Brazilian
student, Guilherme
Polo, who completed and extended important improvements to IDLE made during
the previous year by David Scherer. Given the somewhat official nature of
this work, I assumed that these needed improvements would make it into the
standard distribution, but as far as I know that hasn't happened. It would
seem that if even this "sponsored" project didn't impact the standard Python
distribution, something is broken in the procedures, and probably what is
needed is, as Guido says, that someone be given the authority to get
improvements to IDLE into the standard distribution. Making a significant
change to the update procedures is clearly needed.
Even if this needed change is made, there is also merit to Tai's suggestion
of creating a separate project, to encourage developers like him to work
together to improve IDLE, without having as a first priority to worry about
getting it into the standard distribution, but with the clear understanding
that this is the place to go for improvements to migrate into the standard
distribution.
Bruce Sherwood
P.S. I'll add that IDLE has been EXTREMELY important for a large population
of relatively casual users of Python, the thousands of science and
engineering university students enrolled in the "Matter & Interactions"
intro physics curriculum developed by Ruth Chabay and me (
matterandinteractions.org). A major feature of this curriculum is a serious
introduction to computational modeling, in which students write short Python
programs to model physical systems. Computational modeling is now central to
all of science and engineering but alas has not made its way into
undergraduate curricula in an institutionalized way.
A big difficulty is that students come to college knowledgeable about all
aspects of computers save one: programming. So the programming environment
has to be exceptionally easy to learn and use. Python itself has the
necessary properties, and Python+Visual (called VPython, vpython.org) lets
the students focus on the physics while VPython generates real-time
navigable 3D animations of the computational models, as a side effect of the
computational code.
IDLE has proved to be the right editing tool for this population, as
essentially nothing needs to be learned, and there is near-instantaneous
edit/run transitions which encourage rapid testing. In a physics course we
have to focus on strict minimalism as far as the programming is concerned.
We teach a bare minimum of needed concepts; for example, we introduce while
loops but not for loops. We cannot afford to teach about a professional IDE;
IDLE is fine and has worked well for us. (We're currently bundling with
VPython the Scherer/Polo version of IDLE, which for reasons of clarity we're
calling VIDLE.)
A final personal note is that while I use Eclipse for working on the Visual
module, which is written in C++, I find VIDLE a delightful environment for
developing Python programs for physics education.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On the notion that IDLE is fatally flawed and is driving away potential users of Python (to put the statements in their most extreme form): It seems that there are (at least) two very different communities people have in mind. I can appreciate that highly expert programmers may find IDLE insufficient for their needs, and it might even be the case that these people should be advised not to even try IDLE. But I want to stress as strongly as possible that for a very large community of nonexpert users of Python, IDLE has been extremely important and works very well for their purposes. Editing is pretty much like what they're already used to in word processors, which is certainly not the case with professional tools such as vim or Emacs. That said, yes, there are some significant deficiencies with the current IDLE (which is why there's a VIDLE, for instance). I'm very glad to hear from Martin that Guilherme is free to commit his important bug fixes and improvements. I'm afraid that neither Guilherme nor I understood the procedures and thought that we had to wait for others to act. Bruce Sherwood ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Mon, Jul 12, 2010 at 3:20 AM, Kurt B. Kaiser wrote: > > > As I recollect, much of what Scherer did in VIDLE related to running > multiple IDLE copies. > > For that reason, the VIDLE changes have to be evaluated carefully to > determine what has already been incorporated. I believe I added a > couple of his smaller changes, also. > > Bruce, speaking of Dave Scherer, we've been trying to get a Python > Contributor Agreement from him. Is that something you can help us with? > > -- > KBK > I don't recall that VIDLE has anything to do with running multiple IDLE copies. What's in VIDLE is a lot of bug fixes and some improvements. For example, you can configure it to not require having to save a file, which makes it as easy to use for quick testing as the shell. Another improvement, of high importance for our physics students and other novice programmers, is to bring an error display forward. Many students fill the screen with the edit window and the error message could be hidden, leaving them puzzled as to why their program wasn't running. Stuff like that, all aimed at issues we had seen with a large population of science and engineering students. I'll say again that IDLE/VIDLE is an excellent environment for novices. Issues identified here about look and feel etc. have just not been of any importance in that context. If you'll send me what you want from Scherer, I can contact him. Bruce Sherwood ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Visualpython-users] How VPython 6 differs from VPython 5
Since this was copied to the Python-Dev list, I want to go on record as stating firmly that there is no evidence whatsoever to substantiate claims that there has ever been some kind of conflict between VPython and Python. Since __future__ was also mentioned, I'll take the opportunity to say that I've been very impressed by the way the Python community has handled the difficult 2->3 transition. For example, it has been a big help to the educational uses of VPython that we could tell students simply to start with "from __future__ import division, print_function", put parens around print arguments, and thereby make it irrelevant whether they used Python 2 or Python 3. Many thanks to the Python development community! Bruce Sherwood On Sun, Jan 13, 2013 at 6:41 PM, Mark Janssen wrote: > On Sun, Jan 13, 2013 at 12:14 PM, Bruce Sherwood > wrote: > > For the record, I do not know of any evidence whatsoever for a supposed > > "split" between the tiny VPython community and the huge Python community > > concerning floating point variables. Nor do I see anything in Python that > > needs to be "fixed". > > Well it was bit enough that the python community created a brand-new > language construct called import __future__ -- something never > considered before then and which actually changes the behavior of > python unlike any other module. And perhaps I've just felt it more > because I was a big proponent of both 3-d graphics as a way to keep > python a draw for beginning programmers and also a big fan of > scientific simulation. No one had anything near vpython back then. > (But ultimately I need to stop mentioning this issue to this vpython > list because it's really the Python group which need to get back in > sync.) > > > The new (currently experimental) version of VPython based on wxPython > must, > > in order to run in a Cocoa environment on the Mac, make the interact > loop be > > the primary thread, with the user's Python calculations at worst a > secondary > > thread, which is the opposite of the older VPython, where the > > interval-driven rendering thread was secondary to the user's > calculations. > > By the unusual stratagem of having VPython import the user's program it > has > > been possible to make this work, and at the same time greatly simplify > the > > C++ component of VPython by eliminating threading, with additional > important > > simplification from eliminating essentially all platform-dependent code > > thanks to the multiplatform character of wxPython. The result is that > nearly > > all existing VPython programs will work without change, at the very small > > cost of a few marginal cases requiring minor tweaking. I should alter the > > documentation to make this important property of the new version more > > salient. > > I need to analyze this more carefully before commenting further > > mark > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Visualpython-users] How VPython 6 differs from VPython 5
For the record, I do not know of any evidence whatsoever for a supposed "split" between the tiny VPython community and the huge Python community concerning floating point variables. Nor do I see anything in Python that needs to be "fixed". The new (currently experimental) version of VPython based on wxPython must, in order to run in a Cocoa environment on the Mac, make the interact loop be the primary thread, with the user's Python calculations at worst a secondary thread, which is the opposite of the older VPython, where the interval-driven rendering thread was secondary to the user's calculations. By the unusual stratagem of having VPython import the user's program it has been possible to make this work, and at the same time greatly simplify the C++ component of VPython by eliminating threading, with additional important simplification from eliminating essentially all platform-dependent code thanks to the multiplatform character of wxPython. The result is that nearly all existing VPython programs will work without change, at the very small cost of a few marginal cases requiring minor tweaking. I should alter the documentation to make this important property of the new version more salient. Minor point: The meaning of the new VPython "sleep" is precisely to relinquish control to the OS, including the GUI. During sleep one wants the wxPython window controls to remain active, which will not be the case with time.sleep, which knows nothing about the wxPython interact loop. So I think the meaning of "sleep" is the usual meaning. Bruce Sherwood On Sun, Jan 13, 2013 at 9:13 AM, Mark Janssen wrote: > On Sun, Jan 13, 2013 at 1:15 AM, Bruce Sherwood > wrote: > > Here is detailed information on how VPython 6 differs from VPython 5, > which > > will be incorporated in the Help for upcoming releases of VPython 6. Note > > that the fact that in a main program __name__ isn't '__main__' is an > > unavoidable "feature", not a bug. That is, there doesn't seem to be a > way to > > make this work. > > Hi, Bruce. I think there are two ways of fixing this. One is to get > down to the C language level, and share the C main() loop, which will > percolate back up into the CPython loop. The other involves mending > the split that I've been mentioning that happened over floating point > between the VPython developers and the Python-dev group. Then perhaps > Guido will accept VPython using/sharing the __main__ "loop". (I'm > CC'ing him in this message.) So, either of these tracks should fix > this problem. This is why I keep mentioning the important of healing > that split between the parties arguing in the two camps. Perhaps Tim > Peters will be able help bridge this gap. > > > Changes from VPython 5 > > > > The new version makes an essential change to the syntax of VPython > programs. > > Now, an animation loop MUST contain a rate or sleep statement, which > limits > > the number of loop iterations per second as before but also when > appropriate > > (about 30 times per second) updates the 3D scene and handles mouse and > > keyboard events. Without a rate or sleep statement, the scene will not be > > updated until and unless the loop is completed. > > I think this is perfectly acceptible and is just a necessary > restriction wherefrom the OS *must* maintain ultimate control of I/O. > Python sits in userspace surrounded by the larger computation > environment, so this is only fair that an OS call is made so that it > can keep things in "check". Naming it "sleep" is okay, but makes it > sound more like a voluntary thing, and as you probably know, is the > traditional name for relinquishng some control to the OS. (cf. Unix > Systems Programming, Robbins, et al.) > > > You should use the new function sleep rather than time.sleep. The new > > function periodically renders the scene and processes mouse events, > making > > it possible to continue using zoom and rotate, whereas time.sleep does > not > > do this. > > This is strange to me. I think this is where VPython must be ahead of > the curve and not close enough to the Linux development communities. > > > For technical reasons, it is necessary for VPython 6 to do something > rather > > unusual. When you import visual (or vis), your own program is in turn > > imported by the visual module. > > Again this is because of the faction that was created by in 200?, > regarding the Vpython community vs. the python-dev. Really, this > should be mended. > > Anyway, I hope that any of this made sense. > > Thanks for your help! > > Mark > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
