pycrust-users — PyCrust Users and Developers

Re: [PyCrust] Some enhancements. Any interest?

[Sebastian H. <ha...@ms...>]

Hi Patrick!
Good to hear from you !
That sounds great that you are still with us and with PyCrust ;-)

+ why is there a need for a special "PyCrust subversion" - isn't PyCrust now 
"part" of wxPython !? see below...

+ I would really suggest to stop using  the pycrust-users list for now ... 
(I'm cross posting to wxPython-users)
+ Further I would suggest to IMMEDIATELY make a note to the sourceforge page 
that PyCrust 0.6 from 2001(?) is NOT the latest and that instead there it is 
now (more) incorporated into wxPython itself ( refer wxPython.org frontpage 
and also the wxPython wiki)
+ To clarify on the name: As Robin wrote just recently (2006-02-15 14:08: "Re: 
[wxPython-users]  Re: Pycrust enhancement with plugins")  I would like get 
your - Patrick - blessing of officially calling the whole project  "PyCrust"  
again - "Py" is too often used as generic prefix as not googleble either !

+ I had some improvements myself that mostly made it into the 2.6.2 wPython 
version (see ChangeLog): most often I use the "free edit"-mode to clean out 
100s of lines of "accidental" output; also I like using the search function;  
the folding function should be made to support nested folds, but I'm not 
really using it much anymore...
What I do use a lot is: drag&drop of files into the shell window to trigger a 
"paste" of the filename. (I don't think this made it into wxPython !)

+ I like Bill's idea of adding 'ls' and 'cd' (or other shell functions) - the 
same way IPython does it -- but I'm not clear of what a good "syntax" would 
be for this (maybe just a '.[a-zA-Z ]' at the start of the line (or even a 
space ' ') -- I just think that IPython is much to complex and should not be 
followed all the way ... 

+ I /would/ like "tab"-completion on variable-, module-, function-, 
module-attributes-,... names (if not unique a popup)  -- but this is just an 
idea...

Thanks for PyCrust !
Sebastian Haase



On Wednesday 01 March 2006 04:51, Patrick K. O'Brien wrote:
> Sebastian Haase wrote:
> > Hi Bill,
> > Yes *I* was somehow on this list (didn't know though) ;-)
> > Good to hear that PyCrust is alive !
> > I would suggest:
> > Please repost your message directly to the wxPython-users list.
> > With the last update of 2.6.2  there have been some improvements to
> > PyCrust  - some overlap with yours ...
> >
> > I certainly agree that the sourceforge page is nothing but a trap !! It
> > should be deleted ! Or clearly stated that wxPython.org (maybe it's
> > wiki) is the place to look.
>
> I am interested in changes and enhancements to PyCrust.  I'm planning to
> provide Subversion and Trac support as well as a website (pycrust.org)
> to support these community efforts.  Once that is in place I will shut
> down the sourceforge project, or at least make sure it redirects better.
>  For now the wxPython-users list is the best place to discuss these things.

Re: [PyCrust] Some enhancements. Any interest?

[Bill B. <wb...@gm...>]

> I am interested in changes and enhancements to PyCrust.  I'm planning to
> provide Subversion and Trac support as well as a website (pycrust.org)
> to support these community efforts.  Once that is in place I will shut
> down the sourceforge project, or at least make sure it redirects better.
> For now the wxPython-users list is the best place to discuss these things=
.
>
>
Cool.  I put the files for my changes to pycrust up at
  http://www.billbaxter.com/tmp/bb-pycrust-0.1.0.zip
They're in their own package, but you should be able to diff the files
against the corresponding wx/py files to see changes.

--Bill

Re: [PyCrust] Some enhancements. Any interest?

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

Sebastian Haase wrote:
> Hi Bill,
> Yes *I* was somehow on this list (didn't know though) ;-)
> Good to hear that PyCrust is alive !
> I would suggest:
> Please repost your message directly to the wxPython-users list.
> With the last update of 2.6.2  there have been some improvements to
> PyCrust  - some overlap with yours ...
> 
> I certainly agree that the sourceforge page is nothing but a trap !! It
> should be deleted ! Or clearly stated that wxPython.org (maybe it's
> wiki) is the place to look.

I am interested in changes and enhancements to PyCrust.  I'm planning to
provide Subversion and Trac support as well as a website (pycrust.org)
to support these community efforts.  Once that is in place I will shut
down the sourceforge project, or at least make sure it redirects better.
 For now the wxPython-users list is the best place to discuss these things.

-- 
Patrick K. O'Brien
Orbtech       http://www.orbtech.com
Schevo        http://www.schevo.org
Louie         http://www.pylouie.org

Re: [PyCrust] Some enhancements. Any interest?

[Sebastian H. <ha...@ms...>]

Hi Bill,
Yes *I* was somehow on this list (didn't know though) ;-)
Good to hear that PyCrust is alive !
I would suggest:
Please repost your message directly to the wxPython-users list.
With the last update of 2.6.2  there have been some improvements to 
PyCrust  - some overlap with yours ...

I certainly agree that the sourceforge page is nothing but a trap !! It 
should be deleted ! Or clearly stated that wxPython.org (maybe it's 
wiki) is the place to look.

Thanks for your work.
- Sebastian Haase



Bill Baxter wrote:
> Don't know if anyone reads this list these days or is working on pycrust 
> at all anymore (sourceforge is proudly announcing the 0.6 release from 
> 2001 still), but I made some changes to my version of pycrust and 
> wondered if there was any interest in them.  Basically I've haven't been 
> using python that long, but it seems to me that among the shells I've 
> tried pycrust is the best.  But it lacks some of the nice features of 
> ipython.   I talked to the main fellow behind iPython and he said there 
> is talk about merging ipython and pycrust, but it's still a long ways 
> off, blah blah blah. 
> 
> So here's a summary of the changes I made in no particular order:
> 
> * Made up and down arrows go through history (currently ctrl-up 
> ctrl-down).  I don't see why anyone would want the most common option to 
> be moving the cursor around the screen.  Most shells don't have any way 
> to move the cursor around the screen other than click and drag.
> 
> * Added forward history search (to go with the backward history search 
> bound to F8).  Also made the history search default to normal non-search 
> history scrolling if done at the beginning of the line (instead of doing 
> nothing like it used to)
> 
> * Made ctrl-up and ctrl-down do up and down history search (ctrl-up does 
> what F8 does)
> 
> * Added Ctrl-U key combo to erase the current line (like in bash, and 
> like Esc currently does)
> 
> * Modified the about dialog so it doesn't beep (using 
> ScrolledMessageDialog instead of MessageDialog)  (Beep was annoying me)
> 
> * Modified the help dialog so it doesn't beep (again using 
> ScrolledMessageDialog), and made it actually display the help text 
> rather than telling you to type 'shell.help()'.  (Annoying!)
> 
> * Made exit,close,quit actually quit the shell, after asking if it's ok, 
> rather than tell you to click on the close box.  (also annoying to me 
> :-) )  [incidentally this was done by creating a little helper class 
> whose __repr__ method does the closing.  Not sure if this is considered 
> horrible python style or not, but it lets you type just 'quit' instead 
> of 'quit()'.
> 
> * Changed the settings to be saved in $HOME on all platforms if $HOME is 
> set.  wx's GetUserDataDir() ignores $HOME on Windows because it's not 
> standard, but my opinion is that a lot of programmers do set it, and so, 
> if it's set, it should be used instead of the standard "Documents and 
> Settings" folder.
> 
> * In my own settings I added a 'cd' and 'ls' command to navigate the 
> directory structure more easily. These might be nice to have in pycrust 
> itself.
> 
> 
> Wishes for further pycrust features that should be relatively easy to add:
> 
> * A current directory display, perhaps with history of recently used 
> directoryies.  I'm thinking a popdown combobox, like Matlab has.
> * A way to change the shell's font
> * A better way to handle magic shell level commands like 'exit' or 'cd' 
> or 'ls'.  I looked at the interpreter class a bit, but it wasn't clear 
> right off where the best place to examine commands and "intervene" if 
> they shouldn't be evaluated by python.  It would be nice if you could 
> make those more like unix shell commands.  i.e. 'ls c:\foo' would work 
> (instead of) "ls(r'c:\foo')", and you could get tab completion of 
> filenames etc.
> 
> Wishes for things that would be slightly more work:
> * User settable key combos instead of hard coded keys.
> * Debugger integration
> 
> Let me know if anyone is interested in these changes and I can post the 
> code.  For now I just made copies of the only files I changed 
> (PyCrust.py, crust.py, shell.py, and version.py) and put them in a 
> separate module so that I can have both the original pycrust and my 
> modded version coexisting. 
> 
> --Bill

[PyCrust] Some enhancements. Any interest?

[Bill B. <wb...@gm...>]

Don't know if anyone reads this list these days or is working on pycrust at
all anymore (sourceforge is proudly announcing the 0.6 release from 2001
still), but I made some changes to my version of pycrust and wondered if
there was any interest in them.  Basically I've haven't been using python
that long, but it seems to me that among the shells I've tried pycrust is
the best.  But it lacks some of the nice features of ipython.   I talked to
the main fellow behind iPython and he said there is talk about merging
ipython and pycrust, but it's still a long ways off, blah blah blah.

So here's a summary of the changes I made in no particular order:

* Made up and down arrows go through history (currently ctrl-up ctrl-down).
I don't see why anyone would want the most common option to be moving the
cursor around the screen.  Most shells don't have any way to move the curso=
r
around the screen other than click and drag.

* Added forward history search (to go with the backward history search boun=
d
to F8).  Also made the history search default to normal non-search history
scrolling if done at the beginning of the line (instead of doing nothing
like it used to)

* Made ctrl-up and ctrl-down do up and down history search (ctrl-up does
what F8 does)

* Added Ctrl-U key combo to erase the current line (like in bash, and like
Esc currently does)

* Modified the about dialog so it doesn't beep (using ScrolledMessageDialog
instead of MessageDialog)  (Beep was annoying me)

* Modified the help dialog so it doesn't beep (again using
ScrolledMessageDialog), and made it actually display the help text rather
than telling you to type 'shell.help()'.  (Annoying!)

* Made exit,close,quit actually quit the shell, after asking if it's ok,
rather than tell you to click on the close box.  (also annoying to me :-) )
[incidentally this was done by creating a little helper class whose __repr_=
_
method does the closing.  Not sure if this is considered horrible python
style or not, but it lets you type just 'quit' instead of 'quit()'.

* Changed the settings to be saved in $HOME on all platforms if $HOME is
set.  wx's GetUserDataDir() ignores $HOME on Windows because it's not
standard, but my opinion is that a lot of programmers do set it, and so, if
it's set, it should be used instead of the standard "Documents and Settings=
"
folder.

* In my own settings I added a 'cd' and 'ls' command to navigate the
directory structure more easily. These might be nice to have in pycrust
itself.


Wishes for further pycrust features that should be relatively easy to add:

* A current directory display, perhaps with history of recently used
directoryies.  I'm thinking a popdown combobox, like Matlab has.
* A way to change the shell's font
* A better way to handle magic shell level commands like 'exit' or 'cd' or
'ls'.  I looked at the interpreter class a bit, but it wasn't clear right
off where the best place to examine commands and "intervene" if they
shouldn't be evaluated by python.  It would be nice if you could make those
more like unix shell commands.  i.e. 'ls c:\foo' would work (instead of)
"ls(r'c:\foo')", and you could get tab completion of filenames etc.

Wishes for things that would be slightly more work:
* User settable key combos instead of hard coded keys.
* Debugger integration

Let me know if anyone is interested in these changes and I can post the
code.  For now I just made copies of the only files I changed (PyCrust.py,
crust.py, shell.py, and version.py) and put them in a separate module so
that I can have both the original pycrust and my modded version coexisting.


--Bill

Re: [PyCrust] dispatcher problem

[<po...@or...>]

Thomas Heller <th...@py...> writes:

> I hope this forum is the correct one to ask questions about Patrick's
> dispatcher module ;-)

Actually, I recently created a separate SourceForge project just for
dispatcher.  Mike Fletcher gets the credit for helping out quite a lot
with enhancements, documentation, examples, etc.

http://sourceforge.net/projects/pydispatcher/

We haven't made any announcements about the project yet, but we will
soon.  So you probably want to join that mailing list and ask your
questions again over there:

http://lists.sourceforge.net/lists/listinfo/pydispatcher-devel

In the mean time, I'll try to look into the issues you raised, though
I am quite swamped with work at the moment (on a project that is
making heavy use of dispatcher, btw).

-- 
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

[PyCrust] dispatcher problem

[Thomas H. <th...@py...>]

I hope this forum is the correct one to ask questions about Patrick's
dispatcher module ;-)

I'm using an old and slightly patched version of the dispatcher module
to 'connect' models to widgets in my program.

The model instances in my program trigger certain events by calling

    dispatcher.send(signal=(self._name, "show"), visible=self._active)

The gui creates zero, one or more widgets which should display the
'state' of the model, and the the gui connects the widgets to the
models:

    def on_create(self, widget):
         name = widget.label
         dispatcher.connect(signal=(name, "show"),
                            receiver=widget.show))

The above code arranges that the widget is made visible when the model
becomes active, and invisible when the model becomes inactive.

The above code works very well, I don't need to disconnect the widgets
from the model when they are destroyes, dispatcher does this
automatically with it's weak references.

The problem occurs when the event handling become more complicated, and
cannot simply be done by a simple (bound) method call in a widget
instance.

What I want to achive is something like this:

    def on_create(self, widget):
        name = widget.label
        import registry
        model = registry.get(name)
        
        def handler(model, widget=widget):
            data = model.get_some_data()
            widget.show_value(data)

        dispatcher.connect(signal=(name, "changed"),
                           receiver=handler)

In other words, the handler for the event must do an operation on the
model for some data, and then call a method on the widget. (The
'changed' event in the above code has the model as a parameter to make
this possible).

This code doesn't work, because when the the on_create method returns,
the handler function is destroyed, and dispatcher drops the connection.

One possibility would be to assign handler to widget as an attribute so
that its lifetime is the same as the widget, but this is ugly. And it
has a further consequence: because there is a reference cycle between
the handler function and the widget, the widget is not destroyed any
more (before the next gc.collect() run).

Equally ugly would be to make the handler function a method of the
widget class, because this would break the separation between the model and
the widget.

Any ideas, anyone? Is this a common problem?

Thanks,

Thomas

Re: [PyCrust] C++ "throw" crashes PyCrust instead of triggering python traceback

[Sebastian H. <ha...@ms...>]

> [Sorry, I didn't see this message right wawy because of a fault in my
> filters.]
>
> Patrick K. O'Brien wrote:
> > "Sebastian Haase" <ha...@ms...> writes:
> >
> >
> >>Hi all,
> >>I am writing C++ code that I make wrap (using SWIG) so that it's callabl
> >>from python.
> >>When there is a exception on the C++ level (C++ throw) this should be
get
> >>converted into an exception on the Python level, that is, I should see a
> >>python traceback.  If I run python in the normal terminal window it
works
> >>like that. Also IDLE behaves well - giving the traceback.
> >>
> >>PyCrust on Linux used to seg-fault on this (2+ month ago?) but now it
works
> >>(since PyCrust 0.9 or so) -- THATS THE GOOD NEWS !!
> >>But the bad news is that on Windows it crahes -- I get
> >>"Runtime Error!  Program: C:\python22\pythonw.exe -- abnormal program
> >>termination" -- and then 'OK' closes everything ...
> >>Here are the versions I use - I just got it yesterday from wxWindows CVS
> >>(2.4 branch)
> >>shell.about()
> >>Author: "Patrick K. O'Brien <po...@or...>"
> >>Py Version: 0.9.2
> >>Py Shell Revision: 1.1.2.5
> >>Py Interpreter Revision: 1.1.2.2
> >>Python Version: 2.2.2
> >>wxPython Version: 2.4.1.0p1
> >>Platform: win32
> >
> >
> > Thanks for the info.  That's the latest version.
> >
> >
> >>Please help - or tell me how I can help ;-)
> >
> >
> > I wish I knew.  I don't do any work with C++.  Robin, got any ideas
> > about this?  Anyone else?  If not, you may want to post something to
> > comp.lang.python, since there are many more people there than on this
> > list.
>
> Please tell me a bit more about it.  Does the exception work correctly
> on Windows if not run from PyCrust?  What about if it is run from some
> other wxPython app?  Can you extract and show us the code that is
> converting the c++ exception into the Python exception?
>
Hi Robin - Hi all,

I just ran some more test - and in fact the exceptions don't work right in
either PyCrust, IDLE or command-line...
When I did the tests before - that was on Linux ! and I got the 'abort' only
from PyCrust and not from IDLE or xterm.
(But as said above - now it works for me in Linux !)

I use  SWIG  * Version 1.3.17u-20021123-0854
on windows - the wrapper code has this code:

    try {
        result = (PriismFile *)new PriismFile((char const *)arg1,arg2,arg3);
    }
    catch(char const *&_e) {
        {
            PyErr_SetString(PyExc_RuntimeError, _e);
            SWIG_fail;
        }
    }
    catch(...) {
        throw;
    }

 and PriismFile::PriismFile(...) contains this:

if(!pfStream) {
     throw "Could not open file" ;
}

****
I JUST LEARNED ABOUT IT !!!!!
putting in printf- statements   I found that it goes into the   "catch(...)
" part !!!

So the problem seems to be that "text" doesn't get matched by  "char const
*&"...
I'm using VC6++

Thanks for your interest - and making me think !!!!
Cheers,
Sebastian Haase

Re: [PyCrust] C++ "throw" crashes PyCrust instead of triggering python traceback

[Robin D. <ro...@al...>]

[Sorry, I didn't see this message right wawy because of a fault in my 
filters.]

Patrick K. O'Brien wrote:
> "Sebastian Haase" <ha...@ms...> writes:
> 
> 
>>Hi all,
>>I am writing C++ code that I make wrap (using SWIG) so that it's callabl
>>from python.
>>When there is a exception on the C++ level (C++ throw) this should be get
>>converted into an exception on the Python level, that is, I should see a
>>python traceback.  If I run python in the normal terminal window it works
>>like that. Also IDLE behaves well - giving the traceback.
>>
>>PyCrust on Linux used to seg-fault on this (2+ month ago?) but now it works
>>(since PyCrust 0.9 or so) -- THATS THE GOOD NEWS !!
>>But the bad news is that on Windows it crahes -- I get
>>"Runtime Error!  Program: C:\python22\pythonw.exe -- abnormal program
>>termination" -- and then 'OK' closes everything ...
>>Here are the versions I use - I just got it yesterday from wxWindows CVS
>>(2.4 branch)
>>shell.about()
>>Author: "Patrick K. O'Brien <po...@or...>"
>>Py Version: 0.9.2
>>Py Shell Revision: 1.1.2.5
>>Py Interpreter Revision: 1.1.2.2
>>Python Version: 2.2.2
>>wxPython Version: 2.4.1.0p1
>>Platform: win32
> 
> 
> Thanks for the info.  That's the latest version.
> 
> 
>>Please help - or tell me how I can help ;-)
> 
> 
> I wish I knew.  I don't do any work with C++.  Robin, got any ideas
> about this?  Anyone else?  If not, you may want to post something to
> comp.lang.python, since there are many more people there than on this
> list.

Please tell me a bit more about it.  Does the exception work correctly 
on Windows if not run from PyCrust?  What about if it is run from some 
other wxPython app?  Can you extract and show us the code that is 
converting the c++ exception into the Python exception?


-- 
Robin Dunn
Software Craftsman
http://wxPython.org  Java give you jitters?  Relax with wxPython!

Re: [PyCrust] C++ "throw" crashes PyCrust instead of triggering python traceback

[<po...@or...>]

"Sebastian Haase" <ha...@ms...> writes:

> Hi all,
> I am writing C++ code that I make wrap (using SWIG) so that it's callabl
> from python.
> When there is a exception on the C++ level (C++ throw) this should be get
> converted into an exception on the Python level, that is, I should see a
> python traceback.  If I run python in the normal terminal window it works
> like that. Also IDLE behaves well - giving the traceback.
> 
> PyCrust on Linux used to seg-fault on this (2+ month ago?) but now it works
> (since PyCrust 0.9 or so) -- THATS THE GOOD NEWS !!
> But the bad news is that on Windows it crahes -- I get
> "Runtime Error!  Program: C:\python22\pythonw.exe -- abnormal program
> termination" -- and then 'OK' closes everything ...
> Here are the versions I use - I just got it yesterday from wxWindows CVS
> (2.4 branch)
> shell.about()
> Author: "Patrick K. O'Brien <po...@or...>"
> Py Version: 0.9.2
> Py Shell Revision: 1.1.2.5
> Py Interpreter Revision: 1.1.2.2
> Python Version: 2.2.2
> wxPython Version: 2.4.1.0p1
> Platform: win32

Thanks for the info.  That's the latest version.

> Please help - or tell me how I can help ;-)

I wish I knew.  I don't do any work with C++.  Robin, got any ideas
about this?  Anyone else?  If not, you may want to post something to
comp.lang.python, since there are many more people there than on this
list.

> Thanks for PyCrust - it's great !!

Glad you think so.  Sorry I couldn't help.

-- 
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

[PyCrust] C++ "throw" crashes PyCrust instead of triggering python traceback

[Sebastian H. <ha...@ms...>]

Hi all,
I am writing C++ code that I make wrap (using SWIG) so that it's callabl
from python.
When there is a exception on the C++ level (C++ throw) this should be get
converted into an exception on the Python level, that is, I should see a
python traceback.  If I run python in the normal terminal window it works
like that. Also IDLE behaves well - giving the traceback.

PyCrust on Linux used to seg-fault on this (2+ month ago?) but now it works
(since PyCrust 0.9 or so) -- THATS THE GOOD NEWS !!
But the bad news is that on Windows it crahes -- I get
"Runtime Error!  Program: C:\python22\pythonw.exe -- abnormal program
termination" -- and then 'OK' closes everything ...
Here are the versions I use - I just got it yesterday from wxWindows CVS
(2.4 branch)
shell.about()
Author: "Patrick K. O'Brien <po...@or...>"
Py Version: 0.9.2
Py Shell Revision: 1.1.2.5
Py Interpreter Revision: 1.1.2.2
Python Version: 2.2.2
wxPython Version: 2.4.1.0p1
Platform: win32

Please help - or tell me how I can help ;-)

Thanks for PyCrust - it's great !!
Sebastian Haase

Re: [PyCrust] PyAlaMode

[<po...@or...>]

Fernando Perez <fp...@co...> writes:

> Patrick K. O'Brien wrote:
> [snip]
> 
> > Like PyCrust, PyAlaMode has a modular design and is both a library of
> > components that you can use in your own programs as well as a set of
> > standalone applications.  Now that I've started this thing, I'd like
> > it to become the best Python source code editor of all (even though
> > I'm partial to Emacs).  If you've got suggestions or would like to
> > help, please let me know.
> 
> This sounds great.  But as much as I'd like to, so far I've been
> unable to stop using Xemacs.  I've tried a bunch of 'new' editors and
> keep coming back to Xemacs because some basic _editing_ features that
> make 'real life' coding efficient are missing from most other tools
> out there.

I'm using Emacs to create PyAlaMode, so I know exactly how you feel.
In fact, I even use Emacs Gnus as my email client.  ;-)

> So here's my _personal_ laundry list of things any editor needs to
> fill out to compete with (X)Emacs:
> 
> - Fully configurable keyboard bindings.  This one is an absolute
> requirement for me.  If I can't set a  tool to use exactly my bindings
> (so I can uniformize them across tools), I won't use it. Period.

I don't yet know how easy this will be using Scintilla.  I have a
feeling it won't be easy, which is a shame.

> - Fast keyboard-based opening of files and buffers with
> tab-completion. Graphical dialogs are great, but when I know where
> things are in my directory structure, it is far more efficient just to
> type names in the minibuffer.

I'll keep this in mind.  Perhaps a configurable choice between the
native file selector dialog and a more keyboard-friendly file selector.

> - Minibuffer for functional control of the editor.  Emacs, jed and lyx
> (my 3 favorite text editing tools) all have this, and I find it
> essential for real life work.

Sounds good.

> - Incremental search like in Emacs, with instant highlighting of all
> occurrences in the current page.
> 
> - Regexp search/replace without graphical dialogs (again, that minibuffer thingy).

More good stuff.

> - Multiple windows open with the same list of underlying buffers.
> This allows me to view two parts of the same file.

Right now you can open more than one file.  I haven't figured out all
the checks that need to be in place to have more than one buffer over
the same file, but the design should allow it.  You would think
someone would have a design document out there somewhere for a good
object model for a document editor.  I haven't found it.

> - Split one window in two or more parts (vertically/horizontally)
> showing the same buffer or different ones.

Should be possible, but I won't try it for the first release.

> - Grep/diff support (emacs' ediff mode is incredibly useful when doing
> complicated code merges, for example).
> 
> - ChangeLog support built into the editor.  When I fix code, all I
> need to do is type C-x-4-a and I get my changelog entry pre-made with
> all the relevant info.  This is a huge time-saver which I need every
> day.

And I use the CVS features of Emacs every day, but that won't be at
the top of my priority list for a while.

> - Code indent/dedent features and code commenting/uncommenting for
> blocks. Since python doesn't have multi-line comments, emacs' ability
> to comment/uncomment a large section with one command is extremely
> useful.

This needs to be there soon.

> - Syntax highlighting for many languages.  I don't want to think in
> terms of 'python editor', 'C editor', 'shell script editor', etc.
> They are all text files, and I want to edit them all, with proper
> color highlighting and auto-indenting, in one single tool.

This is possible with the Scintilla control, but my initial focus is
on editing Python files, since the introspection capabilities
(autocompletion and calltips) are the main thing that PyAlaMode has
that Emacs (and most other editors) does not.

> So there it is :)
> 
> I know that you are just announcing an early pre-release (well, CVS),
> so I understand that some of this things are probably nowhere close
> yet.  But I've just seen too many 'new editor' projects come out
> which, while promising, end up just feeling like toys for real work.
> 
> I'd love to have a modern editor with a good graphical toolkit (Xemacs
> is horrible there) and robust python support.  So I truly wish you
> success with this, and I'll  be the first to use it.  But for that
> unfortunately it will have to meet a relatively stiff standard for me,
> because I need the tool to help me deal productively and quickly with
> large codebases.
> 
> So I hope this project does indeed succeed, because having a well
> integrated python environment with editing/ python shell interaction
> would be fantastic.
> Best of luck!

Thanks for the feedback and encouragement.  If you (or anyone else
reading this) have any idea how to accomplish any of this, please let
me know.  In particular, I'm looking for information on a good object
design for an editing framework.  I've looked through all my design
patterns and programming books and haven't found anything particularly
good.  But since I'd rather improve a wheel than reinvent one, I'm
still looking.

Does anyone know how Emacs is designed?  And how the design allows for
such configurability?  And how to do something similar in Python?

-- 
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

Re: [PyCrust] PyAlaMode

[Fernando P. <fp...@co...>]

Patrick K. O'Brien wrote:
[snip]

> Like PyCrust, PyAlaMode has a modular design and is both a library of
> components that you can use in your own programs as well as a set of
> standalone applications.  Now that I've started this thing, I'd like
> it to become the best Python source code editor of all (even though
> I'm partial to Emacs).  If you've got suggestions or would like to
> help, please let me know.

This sounds great.  But as much as I'd like to, so far I've been unable to 
stop using Xemacs.  I've tried a bunch of 'new' editors and keep coming back 
to Xemacs because some basic _editing_ features that make 'real life' coding 
efficient are missing from most other tools out there.

So here's my _personal_ laundry list of things any editor needs to fill out to 
compete with (X)Emacs:

- Fully configurable keyboard bindings.  This one is an absolute requirement 
for me.  If I can't set a  tool to use exactly my bindings (so I can 
uniformize them across tools), I won't use it. Period.

- Fast keyboard-based opening of files and buffers with tab-completion. 
Graphical dialogs are great, but when I know where things are in my directory 
structure, it is far more efficient just to type names in the minibuffer.

- Minibuffer for functional control of the editor.  Emacs, jed and lyx (my 3 
favorite text editing tools) all have this, and I find it essential for real 
life work.

- Incremental search like in Emacs, with instant highlighting of all 
occurrences in the current page.

- Regexp search/replace without graphical dialogs (again, that minibuffer thingy).

- Multiple windows open with the same list of underlying buffers.  This allows 
me to view two parts of the same file.

- Split one window in two or more parts (vertically/horizontally) showing the 
same buffer or different ones.

- Grep/diff support (emacs' ediff mode is incredibly useful when doing 
complicated code merges, for example).

- ChangeLog support built into the editor.  When I fix code, all I need to do 
is type C-x-4-a and I get my changelog entry pre-made with all the relevant 
info.  This is a huge time-saver which I need every day.

- Code indent/dedent features and code commenting/uncommenting for blocks. 
Since python doesn't have multi-line comments, emacs' ability to 
comment/uncomment a large section with one command is extremely useful.

- Syntax highlighting for many languages.  I don't want to think in terms of 
'python editor', 'C editor', 'shell script editor', etc.  They are all text 
files, and I want to edit them all, with proper color highlighting and 
auto-indenting, in one single tool.


So there it is :)

I know that you are just announcing an early pre-release (well, CVS), so I 
understand that some of this things are probably nowhere close yet.  But I've 
just seen too many 'new editor' projects come out which, while promising, end 
up just feeling like toys for real work.

I'd love to have a modern editor with a good graphical toolkit (Xemacs is 
horrible there) and robust python support.  So I truly wish you success with 
this, and I'll  be the first to use it.  But for that unfortunately it will 
have to meet a relatively stiff standard for me, because I need the tool to 
help me deal productively and quickly with large codebases.

So I hope this project does indeed succeed, because having a well integrated 
python environment with editing/ python shell interaction would be fantastic.
Best of luck!

Cheers,

f.

[PyCrust] PyAlaMode

[<po...@or...>]

I couldn't pass up this opportunity to announce something I'm close to
releasing, since it's going to sound like a good April Fools joke.  In
spite of a great deal of reluctance on my part, I finally broke down
and developed a code editor with the same autocompletion and calltip
features as PyCrust.  The new editor will be named PyAlaMode (thanks
for the name, Robin) and an early version is in the PyCrust CVS
repository.

Since it uses the Scintilla control (wxStyledTextCtrl) it will have a
lot of the same features as Scite, but, like PyCrust, it will be very
dynamic and will build autocompletion lists and calltips on the fly.
But since you are editing source code, rather than entering commands
into a shell, you have to explicitly rebuild the module namespace when
your file is in a shape where it's code can be executed.  There is a
menu choice and keybinding for updating the namespace.

Like PyCrust, PyAlaMode has a modular design and is both a library of
components that you can use in your own programs as well as a set of
standalone applications.  Now that I've started this thing, I'd like
it to become the best Python source code editor of all (even though
I'm partial to Emacs).  If you've got suggestions or would like to
help, please let me know.

-- 
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

[PyCrust] CVS Commits List

[<po...@or...>]

I created a new list for PyCrust cvs commit notifications. The list
info is available here:

http://lists.sourceforge.net/lists/listinfo/pycrust-cvs

Please subscribe if you want to be notified of PyCrust cvs commits.

-- 
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

[PyCrust] Re: AW: Great PyCrust and Great Unicode

[<po...@or...>]

"Massa, Harald" <har...@su...> writes:

> > With Unicode there is a bug in pycrust: I type the following letters......
> 
> >> If I find a fix, I will pass it to you.
> >That would be great. I don't fully understand these international issues.
> 
> I found a fix. It works, but I don't feel very well about it.
> 
> It is fixable by replacing
> 
> command = str(command)  # In case the command is unicode.
> 
> with
> 
> try:
>     command = str(command)  # In case the command is unicode, which fails.
> except UnicodeError:
>     command =command.encode("UTF-8")
> 
> that has to be done in interpreter.py and introspect.py
> 
> I have now idea how this will behave with other languages, especially
> languages using UTF-16 or sth.

Me either. Anyone?

-- 
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

[PyCrust] Re: Great PyCrust and Great Unicode

[<po...@or...>]

"Massa, Harald" <har...@su...> writes:

> Patrick,
>=20
> have you allready been complemented on how great it is to use PyCrust to =
do
> MS-COM develepment?

No. This is a first.

> It is really phantastic: if I instantiate a COM-Object (let's say an
> Excel-Spreadsheet)=20
> 	xlw=3DExcel.Aplication()
> With a lot of "subobject" in the COM-Tree PyCrust really displays the
> Method-Names INCLUDING the named Parameters from Excel / Word Object mode=
l!
> that is MORE THAN GREAT. Even Microsofts own development tools don't prov=
ide
> this in this quality.

Cool.

> Do you use PyCrust for COM-Develepment? I am thinking about entering a
> speech-proposal for Europython concerning Python in business, and the gre=
at
> ease of COM-Development with Python and the additional help of PyCrust
> should be in it - but if you are planning to speek about sth. similiar I
> would be in the audience :-)

I've not done any COM using PyCrust or Python for that matter. I'm in
the US and I'm not attending this EuroPython so please feel free to
enter a proposal.

> Big compliments!

Thanks!

> With Unicode there is a bug in pycrust: I type the following letters
> >>>datei=3D"c:/test/n=E4senb=F6r.
> in Pycrust, and with typing the "." dot, autocomplete tries to jump in an=
d:
>=20
> Traceback (most recent call last):
>   File "C:\Python22\Lib\site-packages\wxPython\lib\PyCrust\shell.py", line
> 523, in OnKeyDown
>     self.processLine()
>   File "C:\Python22\Lib\site-packages\wxPython\lib\PyCrust\shell.py", line
> 742, in processLine
>     self.push(command)
>   File "C:\Python22\Lib\site-packages\wxPython\lib\PyCrust\shell.py", line
> 824, in push
>     self.more =3D self.interp.push(command)
>   File "C:\Python22\Lib\site-packages\wxPython\lib\PyCrust\interpreter.py=
",
> line 62, in push
>     command =3D str(command)  # In case the command is unicode.
> UnicodeError: ASCII encoding error: ordinal not in range(128)
>=20
> fails terrible.=20
>=20
> This happens if site.py is on the default:
> encoding =3D "ascii" # Default value set by _PyUnicode_Init()
>=20
> changing it to
> encoding =3D "UTF-8"=20
>=20
> stopps this error from appearing.
>=20
> International characters ... causing as many problems then international
> ways of life, aren't they?
>=20
> If I find a fix, I will pass it to you.

That would be great. I don't fully understand these international
issues.

I'm copying this to the PyCrust mailing list. I hope you don't
mind. That way someone else might be able to offer a solution. If
you'd like to join the list the details are here:

http://lists.sourceforge.net/lists/listinfo/pycrust-users

> Thank you very much for this great tool,

You're most welcome. It's nice to hear from you.

--=20
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

[PyCrust] Re: PyCrust and IPython

[Fernando P. <fp...@co...>]

Hi Patrick,

> Yes, and the details are here:
> 
> http://lists.sourceforge.net/lists/listinfo/pycrust-users
> 
>>> As far as IPython integration, it seems both projects should work
>>> together to make sure the correct hooks are in the right places.  I
>>> don't know enough about how IPython yet to say whether it can be
>>> re-factored in a way that it can "plug-in" to PyCrust either in the real
>>> sense of a plug-in or as a mix-in class or what ever.  
> 

I'm already playing with pycrust because I actually need a visual class
browser for a large code I didn't write and which I'm trying to understand.
I'd suggest you download ipython
(http://www-hep.colorado.edu/~fperez/ipython/) and play a bit with it.  It
will probably make further discussion and interaction much smoother if we both
familiarize a bit with each other's stuff, and it shouldn't take you more than 
a few minutes to get it going.

I think that ipython and pycrust would really complement each other very well, 
and that they would make a great shell for scientific computing work.  I hope 
we can get good work out of this.

> Okay. Once everyone is subscribed to the PyCrust list I can point out
> the current support for alternate interpreters and we can see what
> might need to be added.
> 
> 
>>> Everyone:
>>> I would suggest we subscribe to the PyCrust list and use that for most
>>> of the initial discussion.  That will keep it all in one place and easy
>>> to follow.

I'm already subscribed, and I also sent this message to the list to get things 
moving there.  If others are also subscribed, we can probably continue the 
discussion there.  I still sent this message with personal copies in case not 
all are in.

Best regards,

Fernando

[PyCrust] PyCrust Now 42% More Filling!

[<po...@or...>]

But seriously, I just checked in changes that make the PyFilling
namespace tree dynamically updated whenever the main namespace
changes. I think it's pretty cool, and it's something I've wanted to
do for a long time.

Of course, it's hard to be perfect, so there are two things not quite
working to my satisfaction. The first is that an object deleted from
the main namespace is not automatically deleted from the tree if it is
the currently selected item (or the currently selected item is a child
of the deleted object). I have some thoughts on how to handle this,
but it will take more time to code it.

The second issue is similar and has to do with items that are
immutable. If the current selection is an immutable object you won't
see a change in the namespace display. While this makes sense if you
understand the mutability issue, it doesn't necessarily match user
expectations. For example, if I do something like this:

    >>> i = 3

The select the "i" item in the filling tree.  Then do this in the
shell:

    >>> i = 35

I expect to see the new value reflected in the namespace display.
Again, I have some ideas on how to handle this but need more time to
code it.

Let me know what you think of the new feature.

-- 
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

Re: [PyCrust] New stuff

[<po...@or...>]

"Raul Cota" <co...@uc...> writes:

> Hi Patrick,
> 
> I run win XP and tried testing the new changes and the crashes are
> pretty nasty. After playing around with it for a while I found that the
> exact line causing it was
> 
> self.AutoCompSetAutoHide(False)
> 
> in the config method of shell.py
> 
> Is it possible to change the code to something like this until the bug
> gets fixed??
> 
> if wx.wxPlatform != '__WXMSW__':
>     self.AutoCompSetAutoHide(False)
> 
> Now that I think about it... could it be my version of wxPython??? I run
> 2.3.3.1 unicode

Sorry about the problems. This is a bug in wxPython that Robin has now
fixed, but the fix hasn't made it into a wxPython release yet. Since
this PyCrust feature will work fine in the next release of wxPython,
I'm reluctant to add a patch to the CVS version. But feel free to
patch your local copy. Unless you plan to stay on that older version
of wxPython, in which case I probably need to patch PyCrust for this
bug for version of wxPython at 2.4.0.2 or older. Let me know what you
think.

-- 
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

RE: [PyCrust] New stuff

[Raul C. <co...@uc...>]

Hi Patrick,

I run win XP and tried testing the new changes and the crashes are
pretty nasty. After playing around with it for a while I found that the
exact line causing it was

self.AutoCompSetAutoHide(False)

in the config method of shell.py

Is it possible to change the code to something like this until the bug
gets fixed??

if wx.wxPlatform != '__WXMSW__':
    self.AutoCompSetAutoHide(False)

Now that I think about it... could it be my version of wxPython??? I run
2.3.3.1 unicode


Take care,

Raul



> -----Original Message-----
> From: pyc...@li... [mailto:pycrust-users-
> ad...@li...] On Behalf Of Patrick K. O'Brien
> Sent: Tuesday, February 04, 2003 9:40 AM
> To: PyCrust-users
> Subject: [PyCrust] New stuff
> 
> 
> Just wanted to point out some recent changes to the CVS version of
> PyCrust,
> in case some of you might want to play with them. In particular, the
most
> recent change at the bottom of the list is kind of fun.
> 
> CHANGES
> =======
> 
> Wrapped sys.ps1, sys.ps2, and sys.ps3 in str(). (Thanks, Kieran
> Holland.)
> 
> Fixed minor things found by PyChecker.
> 
> Changed locals to use __main__.__dict__ and added code to clean up the
> namespace, making it as close to the regular Python environment as
> possible. This solves the problem of pickling and unpickling instances
> of classes defined in the shell.
> 
> Made shell.PasteAndRun() a little more forgiving when it finds a ps2
> prompt line with no trailing space, such when you copy code from a web
> page.
> 
> Improved autocomplete behavior by adding these to shell:
>     self.AutoCompSetAutoHide(False)
>     self.AutoCompStops(' .')
> 
> Added decor directory, decorator.py, stcDecor.py, and
> stcConstants.py. These all serve the purpose of adding docstrings to
> existing wxPython classes, in particular the wxStyledTextControl.
> 
> Added wrap.py, a command line utility for running a wxPython app with
> additional runtime-tools loaded, such as PyCrust (the only tool at
> this point).
> ---------------------------------------------------------------------
> 
> With the wrap utility you can run an existing wxPython program (as
long as
> it has a wxApp subclass that doesn't require any __init__ parameters)
and
> you'll automatically get a PyCrust frame with an `app` variable in the
> local namespace so you can interact with your app. Just run wrap.py
from
> the directory containing your wxPython program and pass the name of
your
> program as a command line arg, like this:
> 
>     wrap.py myProgram.py
> 
> or: wrap.py myProgam
> 
> or: python wrap.py myProgram.py
> 
> or: python wrap.py myProgram
> 
> or: ~/Code/PyCrust/wrap.py myProgam.py
> 
> or: C:\Code\PyCrust\wrap.py myProgram
> 
> Let me know how you like it. Also note that the autocomplete changes
> appear
> to be causing a problem on non-Linux platforms.
> 
> --
> Patrick K. O'Brien
> Orbtech      http://www.orbtech.com/web/pobrien
> -----------------------------------------------
> "Your source for Python programming expertise."
> -----------------------------------------------
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> PyCrust-users mailing list
> PyC...@li...
> https://lists.sourceforge.net/lists/listinfo/pycrust-users

[PyCrust] New stuff

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

Just wanted to point out some recent changes to the CVS version of PyCrust, 
in case some of you might want to play with them. In particular, the most 
recent change at the bottom of the list is kind of fun.

CHANGES
=======

Wrapped sys.ps1, sys.ps2, and sys.ps3 in str(). (Thanks, Kieran
Holland.)

Fixed minor things found by PyChecker.

Changed locals to use __main__.__dict__ and added code to clean up the
namespace, making it as close to the regular Python environment as
possible. This solves the problem of pickling and unpickling instances
of classes defined in the shell.

Made shell.PasteAndRun() a little more forgiving when it finds a ps2
prompt line with no trailing space, such when you copy code from a web
page.

Improved autocomplete behavior by adding these to shell:
    self.AutoCompSetAutoHide(False)
    self.AutoCompStops(' .')

Added decor directory, decorator.py, stcDecor.py, and
stcConstants.py. These all serve the purpose of adding docstrings to
existing wxPython classes, in particular the wxStyledTextControl.

Added wrap.py, a command line utility for running a wxPython app with
additional runtime-tools loaded, such as PyCrust (the only tool at
this point).
---------------------------------------------------------------------

With the wrap utility you can run an existing wxPython program (as long as 
it has a wxApp subclass that doesn't require any __init__ parameters) and 
you'll automatically get a PyCrust frame with an `app` variable in the 
local namespace so you can interact with your app. Just run wrap.py from 
the directory containing your wxPython program and pass the name of your 
program as a command line arg, like this:

    wrap.py myProgram.py

or: wrap.py myProgam

or: python wrap.py myProgram.py

or: python wrap.py myProgram

or: ~/Code/PyCrust/wrap.py myProgam.py

or: C:\Code\PyCrust\wrap.py myProgram

Let me know how you like it. Also note that the autocomplete changes appear 
to be causing a problem on non-Linux platforms.

-- 
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

Re: [PyCrust] Recent Changes

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

On Friday 08 November 2002 01:55 pm, Raúl Cota wrote:
> I got it from CVS,
>
> Big question... where did "True" and "False" come from???

I believe they were added to Python 2.1.3 and 2.2.1. I'm now on Python 
2.2.2 and I may target that version as the minimum for PyCrust starting 
with PyCrust 0.8.

> Hope it's worth something. Notice that I only spent 15 min on these
> tests. I'll look into it in more detail tonight or tomorrow

I may have slipped in some other new Python features. Any chance of you 
upgrading to Python 2.2.2?

-- 
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

Re: [PyCrust] Recent Changes

[<co...@uc...>]

I got it from CVS,

If I run PyShellApp.py normally, I get errors of the type...
Error in shell.py line 238. "Global name False is not defined"
I changed "False" for "wx.false" and "True" for "wx.true" everywhere, and
then it worked fine but....
Autocomplete doesn't work at all in Python mode


In my app...
Autocomplete still doesn't work on Python mode, but when I switch to the
simulator mode which is my "non-standard" code autocomplete works just fine
(I can switch back and forth pressing Ctrl-F)


Big question... where did "True" and "False" come from???

Hope it's worth something. Notice that I only spent 15 min on these tests.
I'll look into it in more detail tonight or tomorrow

Raul


----- Original Message -----
From: "Patrick K. O'Brien" <po...@or...>
To: <PyC...@li...>
Cc: "Raul Cota" <co...@uc...>
Sent: Friday, November 08, 2002 6:35 AM
Subject: [PyCrust] Recent Changes


>
> I've changed the way that PyCrust determines the object for which
> autocompletion options and calltips should be presented. The new way
> uses the tokenize module (plus the usual jumping through hoops that I
> always have to do) and does a better job supporting whitespace within
> commands and empty types: '', "", '''''', """""", [], (), {}.
>
> The new version passes all the old unit tests as well as some additional
> unit tests. What I'm not sure about is whether it interferes with
> anyone who is using PyCrust for non-standard code. In particular, I'm
> worried about you, Raul Cota. :-)
>
> Anyone who relies on autocompletion for commands that aren't pure Python
> code should get the latest PyCrust from CVS and make sure I haven't
> broken their application. If I have, let me know and hopefully we can
> figure out a solution.
>
> --
> Patrick K. O'Brien
> Orbtech      http://www.orbtech.com/web/pobrien
> -----------------------------------------------
> "Your source for Python programming expertise."
> -----------------------------------------------
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> PyCrust-users mailing list
> PyC...@li...
> https://lists.sourceforge.net/lists/listinfo/pycrust-users
>

[PyCrust] Recent Changes

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

I've changed the way that PyCrust determines the object for which 
autocompletion options and calltips should be presented. The new way 
uses the tokenize module (plus the usual jumping through hoops that I 
always have to do) and does a better job supporting whitespace within 
commands and empty types: '', "", '''''', """""", [], (), {}.

The new version passes all the old unit tests as well as some additional 
unit tests. What I'm not sure about is whether it interferes with 
anyone who is using PyCrust for non-standard code. In particular, I'm 
worried about you, Raul Cota. :-)

Anyone who relies on autocompletion for commands that aren't pure Python 
code should get the latest PyCrust from CVS and make sure I haven't 
broken their application. If I have, let me know and hopefully we can 
figure out a solution.

-- 
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------