Laura MacDougal, Patrick Smith, and Tim Smith
from the University of Toronto collaborated
with students and professors there to produce
a new version of drpython.
It includes a full graphical debugger, beginner and advanced modes,
pydoc generation, and a host of other small features and bugfixes.
The current version of drpython, 3.10.12, is a bit unstable
with indentation and encoding support, but otherwise
There are three immediate new steps to take:
1. Make a maintenance release, fixing outstanding bugs. (Done!)
2. Work the current codebase into the Toronto Release.
3. 4.x development
The code for drpython is messy. The more and more I program, the more obvious this becomes. Here are the steps planned to address the current state of drpy:
General Code Reorganization:
A new directory structure:
(32x32 icon file, general purpose files)
(Scripts for genrating Doc HTML)
(modules that manipulate data, processes, etc)
(drpy widgets, such as drtext, and drstc)
(dialog files, main drpython file)
any files setup.py requires
(a few example drscripts)
(setup.py, drpython.pyw. readme.txt, install.txt)
The code will be more modular, with a design goal of no more than
300 to 500 lines per file. I will try to minimize the amount of code in
the main drpython.py file.
DocStrings for all methods.
Consistent Method Naming Convention.
(This is a bit odd, as wxPython uses one convention, python another, and standard (eg Zope/Java) another.
I am thinking:
Leave .FooFoo for wxPython functions
Leave .foofoo for Python
Use .fooFoo for drpython
Use ._fooFoo for private functions.
methods need to be rewritten so they work properly on the current stc.
This check could be a bit expensive, so have changing the focus set an
integer value that tells drpy which drSTC to return.
This is towards making side panels work exactly like a normal document. This may be unecessaru/not happen.
The general theme here will be making it easier to get around,
in the filesystem and in files. A focus on moving interaction to the keyboard (while still allowing for mouse control) will also drive development.
A Firefox style toolbar (optionally on the top or bottom), will replace the current system.
Find will become incremental (a la vim).
Regexs that are not valid will act like normal targets that are not found. (*???*)
A not found error will result in validation (the text control will flash red or orange).
Replace will run from the toolbar alone, with no pop ups obscuring text.
Regex Backwards: For all valid regex's, you will be able to search backwards. (*Maybe*)
You can enter a new nested rule (or load a saved one),
and then run find on the matches (which will be incremental).
For example, if you know you want a call that begins with "get",
you can choose "get.*?\(", and then whenever you want to find
a specific "get" function call, simply select that nested find rule,
and find will now search an array of matches from the document.
Source Find will replace SourceCode Go To. (Uses nested find).
Keyboard navigation, only one location bar (always absolute),
no more access to recent files from the combo box(*Done*),
and always opening in the directory of the active file.
Autocomplete for the location bar.
There are a lot of prefs, and they are not organized in a very intuitive way. Both the organization of prefs and implementation of the dialog need to change.
Check For New Version:
To be implemented for the core, and for all plugins.
This is basically it. The major work will be reorganizing the code into a solid structure. Everything here should be taken as changeable and open to discussion.
The basic goals are:
Clean/Readable, Stable, Modular Codebase
New Cool Stuff from Toronto, and focus on beginner/advanced modes.
More powerful functionality to make it easy to manipulate/traverse files more efficiently. Small but nifty features that will make other developers drool when they see drpy in action ;)
(Suggestions for such functionality most welcome).
Sounds great. The debugger will be so nice. DrPy will be an IDE to envy in the python world. I'm glad to see .13 is out. I'll try and play around with it this evening but I have lame housework to do :) lol. The road map is very nice for the peon like me to follow the development. It's much appreciated. Oh just thought I would mention that I had a feature request post up not too long ago. Do you think you will implement some of those features? Either way I know you are busy and what not and I'm not trying to be selfish, it's just I would like a couple of them in the next big release if possible.
Sound too good to be true ;-) Thanks for getting on with drPython and good luck and success with your new working place...
The integration of Bicycle Repair Man could be a great addition to DrPython. Or something else to do refactoring in DrPy.
The integration of things like subversion can also be useful.
Feature Requests: Yes (If you had a post up and it is not active, please repost/activate it, or I may forget).
I just ignored feature requests for this release, as I wanted to work on the stability. I will try to get as many feature requests into 4.0 as I can, unless the request itself is bad (which would be up for debate).
Refactoring would be cool, although I'd be inclined to make it a plugin. Ditto for subversion support. (This depends on whether or not it would be suitable for complete newbies. If any feature request is geared towards new programmers, it will likely get the highest priority for inclusion in the core. Advanced features are more likely to become plugins.
That being said, I want some way to allow some plugins to be installed even in beginner mode (like search in files). In essence, to keep some plugins out of the core, but include them in the release installed by default. But the specifics of that can be hashed out in a later thread.)
Some of the plugins, I wrote, are also quite messy.
But important, they work.
If someone, want to improve the code, or similar, no problem.
Yes, all actions should be also able to be performed
by the keyboard.
Incremental Find: like the plugin (taken from Scite)?
But you keep the normal file dialog, isn't it?
Yes, reorganisation of preferences I would greet.
BTW: What do you people mean by subversion support?
A quick definitions of Sub:
What Is Subversion?
The goal of the Subversion project is to build a version control system that is a compelling replacement for CVS in the open source community. The software is released under an Apache/BSD-style open source license.
An open-source revision control system, which aims to be a compelling replacement
I thought you would not get to the feature requests which is entirely understandable. The ideas stated above about plugins sounds very nice. Did you decide what you are going to do with version numbering? I remember you said you wanted to change it and wasn't sure if you ironed that out yet. Perhaps we should start a " Advanced Feature Requests " and a " Beginnger Feature Request " posts to help track them a little easier? I can't wait to get my hands on the next major release. What fun it will be to have new toys :).....