pycrust-users — PyCrust Users and Developers

RE: [PyCrust] PyCrust.ico problem

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

I had botched this up when I added the file to cvs and didn't mark it as
binary the first time around. This is now fixed and if you update from cvs
it should work. If not, feel free to holler again. Thanks for the feedback.

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Raul Cota
Sent: Friday, September 07, 2001 1:05 PM
To: pyc...@li...
Subject: [PyCrust] PyCrust.ico problem


Patrick,
I just got PyCrust from cvs, and I realized that the icon doesn't work.
This is the error message that pops up:
"Failed to load icon form the file 'PyCrust.py'"

What's wrong with it ??? I so wanted to see the pie :) , but I'm back to
the smiley face

Raul

Win NT

_______________________________________________
PyCrust-users mailing list
PyC...@li...
https://lists.sourceforge.net/lists/listinfo/pycrust-users

Re: [PyCrust] PyCrust.ico problem

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

> Sorry. It works fine for me. When exactly do you get this error and can
you
> capture the entire error message? And what platform are you running on?
> Oops, I see that you are on Win NT, right?

I've seen it too.  I expect that the icon in CVS has gotten corrupted.

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

RE: [PyCrust] PyCrust.ico problem

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

Sorry. It works fine for me. When exactly do you get this error and can you
capture the entire error message? And what platform are you running on?
Oops, I see that you are on Win NT, right?

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Raul Cota
Sent: Friday, September 07, 2001 1:05 PM
To: pyc...@li...
Subject: [PyCrust] PyCrust.ico problem


Patrick,
I just got PyCrust from cvs, and I realized that the icon doesn't work.
This is the error message that pops up:
"Failed to load icon form the file 'PyCrust.py'"

What's wrong with it ??? I so wanted to see the pie :) , but I'm back to
the smiley face

Raul

Win NT

_______________________________________________
PyCrust-users mailing list
PyC...@li...
https://lists.sourceforge.net/lists/listinfo/pycrust-users

[PyCrust] PyCrust.ico problem

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

Patrick,
I just got PyCrust from cvs, and I realized that the icon doesn't work.
This is the error message that pops up:
"Failed to load icon form the file 'PyCrust.py'"

What's wrong with it ??? I so wanted to see the pie :) , but I'm back to
the smiley face

Raul

Win NT

[PyCrust] New command history retrieval features

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

The cvs version of PyCrust now has some command history retrieval features
submitted by Richie Hindle that are quite handy to have until I revamp the
underlying structure of the shell session. And even then, the implementation
may change but the features themselves probably will not. Richie has done a
very nice job of giving us most of the command retrieval functionality that
users expect. Attached is part of his email to me, which explains in detail
how the new features work.

In a nutshell, Control-Up and Control-Down scroll through the buffer of
previous commands. If you select one in the middle of the list it remembers
that position so you can get subsequent commands with Control-Down, making
it very easy to get back a sequence of commands that form a code block, such
as a block starting with "for n in range(10):". Another cool feature is that
typing a few letters and hitting F8 does a search to find previous commands
that start with those letters. See the message below for details.

Thanks a bunch, Richie.

P.S. I'm sticking with binding the retrieval commands to Control-Up and
Control-Down until we have a proper way to allow user configuration of these
things, or until I get a bunch of flame mail. I have two reasons for this:
first, I like these key bindings and second, that's the way PythonWin does
it. Feel free to disagree, or, better, design a really cool way to do user
configurations. <wink>

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

-----Original Message-----
From: Richie Hindle [mailto:ri...@en...]
Sent: Monday, September 03, 2001 2:46 PM
To: po...@or...
Subject: Re: Command history for PyCrust

Hi Patrick,

Thanks for the quick feedback, and thanks for incorporating my edits!

> I bound it to the Control-Up and Control-Down keys [...] Did you have
> a reason for wanting the Alt-key combos?

Only that the Control-modified keys were already in use, for scrolling the
window.  (In fact there's now a bugette in there whereby Control-Up will
revert to scrolling the window when you get to the top end of the history;
easily fixed, but maybe Alt-Up/Down would be better?)

> How does it handle multi-line commands?

It doesn't - it's not Python-savvy.  However, attached is another patch
(against the CVS version this time) which has support for recall of groups
of commands, which is also useful for multi-line commands.  It works like
the NT command prompt: if you go Up-Up-Up-Enter, then go Down, it takes you
to the command following the one you just went back Up to.  Hence repeating
a group of commands over and over again becomes as easy as going
Down-Enter-Down-Enter-Down-Enter.

It's hard to visualise if you haven't used it before - have a go.  It's
designed for sequences that you tend to repeat over and over again while
developing, like "reload( module ) // x = module.Foo() // x.bar()", but it
works well for multi-line commands like "for i in range( 10 ): // print i".

The patch also includes searching of the history - hitting F8 searches the
history for commands starting with the text up to the cursor.  Hitting it
again repeats the search, and when it falls off the end it loops round.
This is based on the NT command prompt as well, hence the choice of the F8
key.

These two features together mean that recalling the above "reload..."
sequence from anywhere in the recent history takes about eight keystrokes:
"<r> <e> <F8> <enter> <control-down> <enter> <control-down> <enter>"

Re: [PyCrust] Significant refactoring

[Chin H. W. <ch...@mi...>]

If anyone is interested, here is the new CmdCrust.py that works with
PyCrust-0.5.4.

----- Original Message -----
From: "Patrick K. O'Brien" <po...@or...>
To: <pyc...@li...>
Sent: Monday, August 20, 2001 11:43 PM
Subject: RE: [PyCrust] Significant refactoring


> Attached is the latest version of the code, including some things that
> aren't even in cvs yet. As you can see, a few things are being rearranged.
> Let me know what you think. And thanks for sharing your program as well.
>
> ---
> Patrick K. O'Brien
> Orbtech
> "I am, therefore I think."
>
> -----Original Message-----
> From: pyc...@li...
> [mailto:pyc...@li...]On Behalf Of Chin H. Wu
> Sent: Tuesday, August 21, 2001 12:41 AM
> To: pyc...@li...
> Subject: Re: [PyCrust] Significant refactoring
>
> Please e-mail me the modifications. I don't have CVS installed in my
machine
> yet.
>
> Here is the program I mentioned. As you can see, the modification is quite
> simple. If you have a window machine, you can double click on
CmdConsole.py
> to get started. You can try CmdCrust if you have PyCrust-0.5.1. I can
update
> it after I get your new version of PyCrustAlaCarte.py.
>

RE: [PyCrust] Significant refactoring

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

Attached is the latest version of the code, including some things that
aren't even in cvs yet. As you can see, a few things are being rearranged.
Let me know what you think. And thanks for sharing your program as well.

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

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Chin H. Wu
Sent: Tuesday, August 21, 2001 12:41 AM
To: pyc...@li...
Subject: Re: [PyCrust] Significant refactoring

Please e-mail me the modifications. I don't have CVS installed in my machine
yet.

Here is the program I mentioned. As you can see, the modification is quite
simple. If you have a window machine, you can double click on CmdConsole.py
to get started. You can try CmdCrust if you have PyCrust-0.5.1. I can update
it after I get your new version of PyCrustAlaCarte.py.


----- Original Message -----
From: "Patrick K. O'Brien" <po...@or...>
To: <pyc...@li...>
Sent: Monday, August 20, 2001 1:44 PM
Subject: RE: [PyCrust] Significant refactoring


> I have changed the Shell class to allow you to pass an
> Interpreter-compatible class (or subclass of Interpreter) and any number
of
> additional parameters required by your class. PyCrustAlaCarte.py was also
> fixed and now uses a subclass of PyCrust.interpreter.Interpreter called
> InterpreterAlaCarte. I think this should give you the flexibility you are
> looking for. If not, holler.
>
> The changes have been checked into CVS and are available there now. A zip
> file release should be available later this week. Let me know if you can't
> do CVS and need the files sooner.
>
> P.S. Is there any chance you'd like to share your program? It sounds like
> you might have some interesting enhancements.
>
> ---
> Patrick K. O'Brien
> Orbtech
> "I am, therefore I think."
>
> -----Original Message-----
> From: pyc...@li...
> [mailto:pyc...@li...]On Behalf Of Chin H. Wu
> Sent: Sunday, August 19, 2001 11:24 PM
> To: pyc...@li...
> Subject: Re: [PyCrust] Significant refactoring
>
> I have a program that runs from the command line. This program is a hybrid
> of cmd.py and code.py that I can take an arbitrary program and turns that
> into something like a builtin keyword. For example, I have a command
called
> foo, which will prints out the input contents:
>     def foo(in):
>         print in
>
> And I can call this command like:
>     Python > foo 1
> or
>     Python > foo a
> where "a" is a defined variable.
> But it goes beyond calling the commands in a simple statement like above,
I
> can also do this:
>     for i in range(3):
>         foo i
>
> For all practical purpose, the command behaves like a builtin keyword like
> 'print'. It is very similar to PyCrust.pseudo.PseudoKeyword if you know
what
> I means.
>
> I wrote the program by modifying the code.py and by subclassing the
> InteractiveInterpreter. The idea is very similar to Interpreter class in
> PyCrust. In PyCrust-0.5.1, I can make minimum modification to my program
and
> make it work with PyCrust and wxPython. This doesn't work with
PyCrust-0.5.3
> because I don't see an easy way to subclass the Interpreter class. I like
> some of the features PyCrust provides and wish to make my program work
with
> PyCrust. Hence I would petition to keep the Interpreter class
subclassable.
> That opens a lot of possiblity.
>
>
>
> _______________________________________________
> PyCrust-users mailing list
> PyC...@li...
> http://lists.sourceforge.net/lists/listinfo/pycrust-users

Re: [PyCrust] Significant refactoring

[Chin H. W. <ch...@mi...>]

Please e-mail me the modifications. I don't have CVS installed in my machine
yet.

Here is the program I mentioned. As you can see, the modification is quite
simple. If you have a window machine, you can double click on CmdConsole.py
to get started. You can try CmdCrust if you have PyCrust-0.5.1. I can update
it after I get your new version of PyCrustAlaCarte.py.


----- Original Message -----
From: "Patrick K. O'Brien" <po...@or...>
To: <pyc...@li...>
Sent: Monday, August 20, 2001 1:44 PM
Subject: RE: [PyCrust] Significant refactoring


> I have changed the Shell class to allow you to pass an
> Interpreter-compatible class (or subclass of Interpreter) and any number
of
> additional parameters required by your class. PyCrustAlaCarte.py was also
> fixed and now uses a subclass of PyCrust.interpreter.Interpreter called
> InterpreterAlaCarte. I think this should give you the flexibility you are
> looking for. If not, holler.
>
> The changes have been checked into CVS and are available there now. A zip
> file release should be available later this week. Let me know if you can't
> do CVS and need the files sooner.
>
> P.S. Is there any chance you'd like to share your program? It sounds like
> you might have some interesting enhancements.
>
> ---
> Patrick K. O'Brien
> Orbtech
> "I am, therefore I think."
>
> -----Original Message-----
> From: pyc...@li...
> [mailto:pyc...@li...]On Behalf Of Chin H. Wu
> Sent: Sunday, August 19, 2001 11:24 PM
> To: pyc...@li...
> Subject: Re: [PyCrust] Significant refactoring
>
> I have a program that runs from the command line. This program is a hybrid
> of cmd.py and code.py that I can take an arbitrary program and turns that
> into something like a builtin keyword. For example, I have a command
called
> foo, which will prints out the input contents:
>     def foo(in):
>         print in
>
> And I can call this command like:
>     Python > foo 1
> or
>     Python > foo a
> where "a" is a defined variable.
> But it goes beyond calling the commands in a simple statement like above,
I
> can also do this:
>     for i in range(3):
>         foo i
>
> For all practical purpose, the command behaves like a builtin keyword like
> 'print'. It is very similar to PyCrust.pseudo.PseudoKeyword if you know
what
> I means.
>
> I wrote the program by modifying the code.py and by subclassing the
> InteractiveInterpreter. The idea is very similar to Interpreter class in
> PyCrust. In PyCrust-0.5.1, I can make minimum modification to my program
and
> make it work with PyCrust and wxPython. This doesn't work with
PyCrust-0.5.3
> because I don't see an easy way to subclass the Interpreter class. I like
> some of the features PyCrust provides and wish to make my program work
with
> PyCrust. Hence I would petition to keep the Interpreter class
subclassable.
> That opens a lot of possiblity.
>
>
>
> _______________________________________________
> PyCrust-users mailing list
> PyC...@li...
> http://lists.sourceforge.net/lists/listinfo/pycrust-users

RE: [PyCrust] Significant refactoring

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

I have changed the Shell class to allow you to pass an
Interpreter-compatible class (or subclass of Interpreter) and any number of
additional parameters required by your class. PyCrustAlaCarte.py was also
fixed and now uses a subclass of PyCrust.interpreter.Interpreter called
InterpreterAlaCarte. I think this should give you the flexibility you are
looking for. If not, holler.

The changes have been checked into CVS and are available there now. A zip
file release should be available later this week. Let me know if you can't
do CVS and need the files sooner.

P.S. Is there any chance you'd like to share your program? It sounds like
you might have some interesting enhancements.

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

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Chin H. Wu
Sent: Sunday, August 19, 2001 11:24 PM
To: pyc...@li...
Subject: Re: [PyCrust] Significant refactoring

I have a program that runs from the command line. This program is a hybrid
of cmd.py and code.py that I can take an arbitrary program and turns that
into something like a builtin keyword. For example, I have a command called
foo, which will prints out the input contents:
    def foo(in):
        print in

And I can call this command like:
    Python > foo 1
or
    Python > foo a
where "a" is a defined variable.
But it goes beyond calling the commands in a simple statement like above, I
can also do this:
    for i in range(3):
        foo i

For all practical purpose, the command behaves like a builtin keyword like
'print'. It is very similar to PyCrust.pseudo.PseudoKeyword if you know what
I means.

I wrote the program by modifying the code.py and by subclassing the
InteractiveInterpreter. The idea is very similar to Interpreter class in
PyCrust. In PyCrust-0.5.1, I can make minimum modification to my program and
make it work with PyCrust and wxPython. This doesn't work with PyCrust-0.5.3
because I don't see an easy way to subclass the Interpreter class. I like
some of the features PyCrust provides and wish to make my program work with
PyCrust. Hence I would petition to keep the Interpreter class subclassable.
That opens a lot of possiblity.

Re: [PyCrust] Significant refactoring

[Chin H. W. <ch...@mi...>]

I have a program that runs from the command line. This program is a hybrid
of cmd.py and code.py that I can take an arbitrary program and turns that
into something like a builtin keyword. For example, I have a command called
foo, which will prints out the input contents:
    def foo(in):
        print in

And I can call this command like:
    Python > foo 1
or
    Python > foo a
where "a" is a defined variable.
But it goes beyond calling the commands in a simple statement like above, I
can also do this:
    for i in range(3):
        foo i

For all practical purpose, the command behaves like a builtin keyword like
'print'. It is very similar to PyCrust.pseudo.PseudoKeyword if you know what
I means.

I wrote the program by modifying the code.py and by subclassing the
InteractiveInterpreter. The idea is very similar to Interpreter class in
PyCrust. In PyCrust-0.5.1, I can make minimum modification to my program and
make it work with PyCrust and wxPython. This doesn't work with PyCrust-0.5.3
because I don't see an easy way to subclass the Interpreter class. I like
some of the features PyCrust provides and wish to make my program work with
PyCrust. Hence I would petition to keep the Interpreter class subclassable.
That opens a lot of possiblity.

----- Original Message -----
From: "Patrick K. O'Brien" <po...@or...>
To: <pyc...@li...>
Sent: Saturday, August 18, 2001 10:04 PM
Subject: RE: [PyCrust] Significant refactoring


> Yeah, the AlaCarte demo is temporarily broken. I probably need to refactor
> the Interpreter class as well to account for the changes to the shell and
> loss of the editor class. Your question about the RIGHT way of subclassing
> the Interpreter class is a good one. I don't have an answer for you
tonight.
> Could you tell me what you want to accomplish by subclassing so that I can
> work on an answer for you?
>
> ---
> Patrick K. O'Brien
> Orbtech
> "I am, therefore I think."
>
> -----Original Message-----
> From: pyc...@li...
> [mailto:pyc...@li...]On Behalf Of Chin H. Wu
> Sent: Saturday, August 18, 2001 11:13 PM
> To: pyc...@li...
> Subject: [PyCrust] Significant refactoring
>
> I just download the PyCrust-0.5.3 and the demos/PyCrustAlaCarte is now
> broken due to the non-existence of Editor class and module. My plan is to
> subclass Interpreter class. But because the Editor class is gone and with
it
> the writeOut, writeErr, and readIn has been moved to Shell class. So what
is
> the RIGHT way of subclassing the Interpreter class?
>
>
>
>
> _______________________________________________
> PyCrust-users mailing list
> PyC...@li...
> http://lists.sourceforge.net/lists/listinfo/pycrust-users
>
>
> _______________________________________________
> PyCrust-users mailing list
> PyC...@li...
> http://lists.sourceforge.net/lists/listinfo/pycrust-users

RE: [PyCrust] Significant refactoring

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

Yeah, the AlaCarte demo is temporarily broken. I probably need to refactor
the Interpreter class as well to account for the changes to the shell and
loss of the editor class. Your question about the RIGHT way of subclassing
the Interpreter class is a good one. I don't have an answer for you tonight.
Could you tell me what you want to accomplish by subclassing so that I can
work on an answer for you?

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

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Chin H. Wu
Sent: Saturday, August 18, 2001 11:13 PM
To: pyc...@li...
Subject: [PyCrust] Significant refactoring

I just download the PyCrust-0.5.3 and the demos/PyCrustAlaCarte is now
broken due to the non-existence of Editor class and module. My plan is to
subclass Interpreter class. But because the Editor class is gone and with it
the writeOut, writeErr, and readIn has been moved to Shell class. So what is
the RIGHT way of subclassing the Interpreter class?




_______________________________________________
PyCrust-users mailing list
PyC...@li...
http://lists.sourceforge.net/lists/listinfo/pycrust-users

[PyCrust] Significant refactoring

[Chin H. W. <ch...@ix...>]

I just download the PyCrust-0.5.3 and the demos/PyCrustAlaCarte is now
broken due to the non-existence of Editor class and module. My plan is to
subclass Interpreter class. But because the Editor class is gone and with it
the writeOut, writeErr, and readIn has been moved to Shell class. So what is
the RIGHT way of subclassing the Interpreter class?

[PyCrust] PyCrust 0.5.2 now available

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

Project: PyCrust  (pycrust)
Package: pycrust
Date   : 2001-08-16 10:02

Project "PyCrust" ('pycrust') has released the new version of package
'pycrust'.
You can download it from SourceForge by following this link:
<http://sourceforge.net/project/showfiles.php?group_id=31263&release_id=4849
0>
or browse Release Notes and ChangeLog by visiting this link:
<http://sourceforge.net/project/shownotes.php?release_id=48490>

[PyCrust] Significant refactoring

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

I just committed to cvs the result of a fairly significant refactoring. In a
complete about-face from my original plans, I actually eliminated the Editor
class (and editor module) by merging it's functionality with the Shell
class. This means that Shell "is a" wxStyledTextCtrl now, rather than a
non-gui class that "has a" editor. There just wasn't enough non-gui code to
justify the separation. Plus, now Shell will be much easier for gui toolkits
and designers to deal with.

The fact that Editor is no longer available as a plug-in may seem like a
step backward. But the reality is that everything but the gui stuff was
already moved into other modules. So the way to get a Tkinter version is to
code a Shell class in Tkinter from the ground up, making use of interpreter,
introspect, pseudo, etc., and modeling its behavior on the wxPython version
of Shell. Any volunteers?

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

RE: [PyCrust] Thoughts...

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

Wow. I don't know what I was thinking. In reality I'd be lucky to get 10%
common code in the Editor class. The better approach is to just let the
Tkinter version recreate the necessary functionality and supply the required
methods. There just isn't enough non-gui code to pull into a base class
after all.

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

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Patrick K.
O'Brien
Sent: Wednesday, August 15, 2001 7:46 PM
To: pyc...@li...
Subject: RE: [PyCrust] Thoughts...

Making everything a plugin is priority number one, to me at least. In fact,
I plan to refactor the Editor() class into Editor(), wxEditor(Editor) and
tkEditor(Editor). Then PyCrust.py will probably become wxPyCrust.py and
tkPyCrust.py. I'm hoping to have 80% of the code in common between the
wxPython version and the Tkinter version. We'll see.

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

RE: [PyCrust] Thoughts...

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

Making everything a plugin is priority number one, to me at least. In fact,
I plan to refactor the Editor() class into Editor(), wxEditor(Editor) and
tkEditor(Editor). Then PyCrust.py will probably become wxPyCrust.py and
tkPyCrust.py. I'm hoping to have 80% of the code in common between the
wxPython version and the Tkinter version. We'll see.

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

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Robin Dunn
Sent: Wednesday, August 15, 2001 5:47 PM
To: pyc...@li...
Subject: Re: [PyCrust] Thoughts...

> I think we're on the same page now, thanks. The problem is mostly my
> ignorance of wxPython, but I'm working on that. I just started doing some
> pretty hefty refactoring to get you all this and more. I'll keep you
posted.

BTW, I also liked the idea of being able to plug different Editors and
Interpreters into Shell, so if your refactoring can preserve that it would
be nice.  I just think that the common case should be simple and so that is
what led me to want a ShellWindow.

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





_______________________________________________
PyCrust-users mailing list
PyC...@li...
http://lists.sourceforge.net/lists/listinfo/pycrust-users

Re: [PyCrust] Thoughts...

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

> I think we're on the same page now, thanks. The problem is mostly my
> ignorance of wxPython, but I'm working on that. I just started doing some
> pretty hefty refactoring to get you all this and more. I'll keep you
posted.

BTW, I also liked the idea of being able to plug different Editors and
Interpreters into Shell, so if your refactoring can preserve that it would
be nice.  I just think that the common case should be simple and so that is
what led me to want a ShellWindow.

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

RE: [PyCrust] Thoughts...

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

I think we're on the same page now, thanks. The problem is mostly my
ignorance of wxPython, but I'm working on that. I just started doing some
pretty hefty refactoring to get you all this and more. I'll keep you posted.

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

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Robin Dunn
Sent: Wednesday, August 15, 2001 4:57 PM
To: pyc...@li...
Subject: Re: [PyCrust] Thoughts...

> I'm not sure if this gets you exactly what you want, but here is an
example.

Not quite, I had already done something like that.  What I was saying is it
would be nice if there was a class, say ShellWindow, that had wxWindow as an
ancestor and had the same basic __init__ interface (parent, id, pos, size,
style) plus any extra parameters for the Shell such as a locals dict, intro
text, etc.  That way you wouldn't have to know that the "window" is really
"shell.editor" and not just "shell", and it could more easily be used as a
control/widget/component like any other in app builders like Boa or
wxDesigner.

What I've got:

> from PyCrust.shell import Shell
>
> #----------------------------------------------------------------------
>
> def runTest(frame, nb, log):
>     shell = Shell(nb)
>     return shell.editor
>

What I would like:

from PyCrust.shell import ShellWindow   # or whatever

def runTest(frame, nb, log):
    shell = ShellWindow(nb)
    return shell


Creating a ShellWindow class that derives from both Shell and Editor almost
does it, but there are attribute and method name clashes between the two so
it never quite worked right when I tried it.



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





_______________________________________________
PyCrust-users mailing list
PyC...@li...
http://lists.sourceforge.net/lists/listinfo/pycrust-users

Re: [PyCrust] Thoughts...

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

> I'm not sure if this gets you exactly what you want, but here is an
example.

Not quite, I had already done something like that.  What I was saying is it
would be nice if there was a class, say ShellWindow, that had wxWindow as an
ancestor and had the same basic __init__ interface (parent, id, pos, size,
style) plus any extra parameters for the Shell such as a locals dict, intro
text, etc.  That way you wouldn't have to know that the "window" is really
"shell.editor" and not just "shell", and it could more easily be used as a
control/widget/component like any other in app builders like Boa or
wxDesigner.

What I've got:

> from PyCrust.shell import Shell
>
> #----------------------------------------------------------------------
>
> def runTest(frame, nb, log):
>     shell = Shell(nb)
>     return shell.editor
>

What I would like:

from PyCrust.shell import ShellWindow   # or whatever

def runTest(frame, nb, log):
    shell = ShellWindow(nb)
    return shell


Creating a ShellWindow class that derives from both Shell and Editor almost
does it, but there are attribute and method name clashes between the two so
it never quite worked right when I tried it.



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

RE: [PyCrust] Thoughts...

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

I'm not sure if this gets you exactly what you want, but here is an example.
I modified the wxPython demo file, PyShellWindow.py, to load PyCrust in the
wxPython Demo application. This loads the PyCrust editor into the demo app
the same exact way as the previous one, inside the sliders and all that.
Does this help? (Note that this uses the PyCrust version 0.5.2 module names
and I had to add a docstring to the shell module to keep Main from hanging
at lead = text[:6])


from PyCrust.shell import Shell

#----------------------------------------------------------------------

def runTest(frame, nb, log):
    shell = Shell(nb)
    return shell.editor

#----------------------------------------------------------------------

import PyCrust.shell

overview = PyCrust.shell.__doc__


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

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Robin Dunn
Sent: Monday, August 13, 2001 10:26 AM
To: pyc...@li...
Subject: Re: [PyCrust] Thoughts...


> I'd like to see more discussion about this. The Shell and Editor are
> intentionally separate and Shell has no wxPython code. If you want more
> control over the location of the Editor, you can. It's just a wxSTC
derived
> class. I'm not sure I fully understand what you want to accomplish.

Basically to have a Shell object that is also a window, so I only have to
construct a single object and use it as a window (ie, using all the wxWindow
methods, passing to sizer.Add, etc.) without having to know the guts of the
class to have the knowledge that to do all that I have to use
shellobj.editor to do it.

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





_______________________________________________
PyCrust-users mailing list
PyC...@li...
http://lists.sourceforge.net/lists/listinfo/pycrust-users

[PyCrust] Module names shortened in 0.5.2

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

Prompted by Robin, I have shortened the PyCrust module names in version
0.5.2 (currently under development and available only on CVS). The new
module names:

shell.py, editor.py, interpreter.py, version.py

I also changed the constant in version.py from "version" to "VERSION".

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

[PyCrust] PyCrust-0.5.1.zip now available

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

PyCrust 0.5.1 is now available in CVS and in zip format:

http://sourceforge.net/project/showfiles.php?group_id=31263

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

[PyCrust] Dynamic attribute introspection discussion on c.l.p.

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

Thank you, Neil, for starting the "Dynamic attribute introspection"
discussion on the Python newsgroup. For those who would like to follow the
thread it is available here:

http://aspn.activestate.com/ASPN/Mail/Message/728936

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

RE: [PyCrust] Should ._getAttributeNames() be recursive?

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

Note: I was, of course, characterizing *my* implementation as far from
perfect.

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

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Patrick K.
O'Brien
Sent: Tuesday, August 14, 2001 10:10 AM
To: pyc...@li...
Cc: Pythoncard
Subject: RE: [PyCrust] Should ._getAttributeNames() be recursive?

This implementation was far from perfect, and couldn't really be fixed. So I
have reversed my position and made ._getAttributeNames() responsible for
walking its own tree. The changes have been checked into cvs for both
PyCrust and PythonCard.

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

RE: [PyCrust] Should ._getAttributeNames() be recursive?

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

This implementation was far from perfect, and couldn't really be fixed. So I
have reversed my position and made ._getAttributeNames() responsible for
walking its own tree. The changes have been checked into cvs for both
PyCrust and PythonCard.

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

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Patrick K.
O'Brien
Sent: Monday, August 13, 2001 10:41 AM
To: pycr
Subject: [PyCrust] Should ._getAttributeNames() be recursive?

PythonCard has implemented the previously discussed ._getAttributeNames()
method to expose magic attributes to introspection to extend command
autocompletion in the PyCrust shell. As discussed, this method was going to
walk up its inheritance tree recursively. When I added this method to the
PyCrust function that gets attributes, I added it in such a way that it
would be called recursively as well. (See implementation below.)

So the question is, who should be responsible for walking the tree. I see
two possible arguments:

1. From a pure design point-of-view, I would agree with the original plan
that said ._getAttributeNames() should walk the tree. That solves the
problem one time and in the right place.

2. From a Python point-of-view, I would say that dir() has been broken a
long time and most everyone already has code to walk the tree, just like I
did. Adding an extra call to object._getAttributeNames() is easy, so why not
just work the way dir() does, which is to not walk the tree.

The rebuttal to the second argument is that just because dir() is broken
doesn't mean we should get sloppy ourselves. And there has been some talk
(IIRC) of fixing dir() as part of the whole "type unification" effort. (Or
whatever it's called.) So dir() may actually get fixed.

Below is the current PyCrust code. If we decide that ._getAttributeNames()
should walk the tree I can change these PyCrust functions:

def getAttributeNames(object):
    """Return list of unique attributes, including inherited, for an
object."""
    attributes = []
    dict = {}
    # Remove duplicates from the attribute list.
    for item in getAllAttributeNames(object):
        dict[item] = None
    attributes += dict.keys()
    attributes.sort()
    return attributes

def getAllAttributeNames(object):
    """Return list of all attributes, including inherited, for an object.

    Recursively walk through a class and all base classes.
    """
    attributes = []
    try:
        # Get attributes available through the normal convention.
        attributes += dir(object)
        # Try to get any magic attributes.
        try:
            attributes += object._getAttributeNames()
        except AttributeError:
            pass
        # For a class instance, get the attributes for the class.
        if hasattr(object, '__class__'):
            attributes += getAllAttributeNames(object.__class__)
        # Also get attributes from any and all parent classes.
        if hasattr(object, '__bases__'):
            for base in object.__bases__:
                attributes += getAllAttributeNames(base)
    finally:
        return attributes

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



_______________________________________________
PyCrust-users mailing list
PyC...@li...
http://lists.sourceforge.net/lists/listinfo/pycrust-users