pycrust-users — PyCrust Users and Developers

RE: [PyCrust] Attribute list hook

[Mark H. <Ma...@Ac...>]

>    If not, I propose a convention which is to provide a getAttributeNames
> method on any class that wants to expose its dynamic (or semi-dynamic)
> attributes to shells. Thus
>
> class D11:
>     def getAttributeNames(self):
>         return ["woderwick", "woger", "weginald"]

I like the idea, but would prefer to see one or 2 leading "_" on the name.
Considering a COM object, for example, the potential exists that
"getAttributeNames" could be a real method on the object.  A leading _ also
helps reinforce this is not a method designed to be called by the "average"
user of the object.

Mark.

Re: [PyCrust] Attribute list hook

[Neil H. <ne...@sc...>]

Me:
>    If not, I propose a convention which is to provide a getAttributeNames
> method on any class that wants to expose its dynamic (or semi-dynamic)
> attributes to shells.

   Here is an implementation to stick on PythonCard's widget class:

    def getAttributeNames(self):
        names = []
        for method in self.__class__.__dict__.keys():
            if method.startswith("get"):
                name = method[3:]
                if name and self.__class__.__dict__.has_key("set" + name):
                    names.append(name[0].lower() + name[1:])
        for base in self.__class__.__bases__:
            for method in base.__dict__.keys():
                if method.startswith("get"):
                    name = method[3:]
                    if name and base.__dict__.has_key("set" + name):
                        names.append(name[0].lower() + name[1:])
        return names

   This implementation only returns names where there is both a set* and a
get* method available. Other implementations may allow read only attributes
or may interrogate a database to find the list.

   PyCrust can be changed to use this with the getAttributes method in
PyCrustInterp.py changed to:

    def getAttributes(self, object):
        # Return a list of attributes, including inherited, for an object.
        try:
            attributes = dir(object)
            if hasattr(object, '__class__'):
                attributes += self.getAttributes(object.__class__)
                try:
                    attributes += object.getAttributeNames()
                except AttributeError:
                    pass
            if hasattr(object, '__bases__'):
    ...

   Neil

RE: [PyCrust] Attribute list hook

[Kevin A. <al...@se...>]

> [mailto:pyc...@li...]On Behalf Of Neil
> Hodgson
>    Real attributes can have __doc__ attributes so it should be possible to
> implement the UI Kevin wants although it should be optional as it
> sounds too
> flashy for me.

I would want it to be optional as well. This kind of hook can be a
tremendous help when learning Python or a framework like PythonCard, but
eventually as Neil says it can be too "flashy". I've been surprised how much
I've learned about my own code and Rowland's by trying things out in the
shell rather than pondering the source or wxPython docs. The calltips and
command completion are awesome when used with the turtle library and I plan
to convert that over to dot notation sometime in the future as well.

ka

Re: [PyCrust] Attribute list hook

[Neil H. <ne...@sc...>]

Kevin Altis:

> Is it possible to have doc strings for attributes? If so, that is another
> thing I would like to be able to do, so that when you are using
> command-completion you could also have a calltip pop up as you go over an
> attribute to see what it is for and the types that are valid for it.

   There is no __doc__ attribute on 'virtual' attributes so this needs
another method, such as getAttributeDoc(name).

   Real attributes can have __doc__ attributes so it should be possible to
implement the UI Kevin wants although it should be optional as it sounds too
flashy for me.

   Neil

RE: [PyCrust] Attribute list hook

[Kevin A. <al...@se...>]

Is it possible to have doc strings for attributes? If so, that is another
thing I would like to be able to do, so that when you are using
command-completion you could also have a calltip pop up as you go over an
attribute to see what it is for and the types that are valid for it. Come to
think of it, I would like to have calltips pop up for methods when scrolling
through the command-completion menu as well.

Neil's solution might need to be expanded so the documentation for the
attributes can be made available as well.

ka

> -----Original Message-----
> From: pyc...@li...
> [mailto:pyc...@li...]On Behalf Of Neil
> Hodgson
> Sent: Saturday, August 11, 2001 12:35 AM
> To: pyc...@li...
> Subject: [PyCrust] Attribute list hook
>
>
>    On the PythonCard list I've been pushing the use of __getattr__ and
> __setattr__ to allow access to widget properties through dot notation -
>
>     self.components.btnTranslate.label = "Celsius to Fahrenheit"
>
>  rather than
>
>     self.components.getWidget("btnTranslate").setLabel("Celsius to
> Fahrenheit")
>
>    One problem with this is that interactive shells such as PyCrust can't
> find out the names of these attributes as they are not in __dict__ even
> though the set of such attributes is normally well known. This is easy
> enough to solve in the context of PythonCard using PyCrust by adding some
> code (or stuffing __dict__ with the known attributes) but this is
> a generic
> problem that should be solved for use by all interactive shells.
>
>    Has this been solved for any other shells?
>
>    If not, I propose a convention which is to provide a getAttributeNames
> method on any class that wants to expose its dynamic (or semi-dynamic)
> attributes to shells. Thus
>
> class D11:
>     def getAttributeNames(self):
>         return ["woderwick", "woger", "weginald"]
>
> class D12:
>     pass
>
> def attrList(d):
>     try:
>         print d.getAttributeNames()
>     except AttributeError, x:
>         print "Empty"
>
> Then interactively:
>
> >>> d = D11()
> >>> attrList(d)
> ['woderwick', 'woger', 'weginald']
> >>> e = D12()
> >>> attrList(e)
> Empty
>
>    If there is resistance to using exceptions here, then a more complex
> mechanism that involves checking the __class__ and
> __class__.__bases__ could
> be used or a marker attribute added.
>
>    I'll leave this message here for a day and if there are no big problems
> will copy it to comp.lang.python to see if there are more opinions.
>
>    Neil
>
>
> _______________________________________________
> PyCrust-users mailing list
> PyC...@li...
> http://lists.sourceforge.net/lists/listinfo/pycrust-users
>

[PyCrust] Attribute list hook

[Neil H. <nho...@bi...>]

   On the PythonCard list I've been pushing the use of __getattr__ and
__setattr__ to allow access to widget properties through dot notation -

    self.components.btnTranslate.label = "Celsius to Fahrenheit"

 rather than

    self.components.getWidget("btnTranslate").setLabel("Celsius to
Fahrenheit")

   One problem with this is that interactive shells such as PyCrust can't
find out the names of these attributes as they are not in __dict__ even
though the set of such attributes is normally well known. This is easy
enough to solve in the context of PythonCard using PyCrust by adding some
code (or stuffing __dict__ with the known attributes) but this is a generic
problem that should be solved for use by all interactive shells.

   Has this been solved for any other shells?

   If not, I propose a convention which is to provide a getAttributeNames
method on any class that wants to expose its dynamic (or semi-dynamic)
attributes to shells. Thus

class D11:
    def getAttributeNames(self):
        return ["woderwick", "woger", "weginald"]

class D12:
    pass

def attrList(d):
    try:
        print d.getAttributeNames()
    except AttributeError, x:
        print "Empty"

Then interactively:

>>> d = D11()
>>> attrList(d)
['woderwick', 'woger', 'weginald']
>>> e = D12()
>>> attrList(e)
Empty

   If there is resistance to using exceptions here, then a more complex
mechanism that involves checking the __class__ and __class__.__bases__ could
be used or a marker attribute added.

   I'll leave this message here for a day and if there are no big problems
will copy it to comp.lang.python to see if there are more opinions.

   Neil

Re: [PyCrust] Thoughts...

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

>
> This may not be directly relevant to what Robin is asking, but this is
what
> I'm currently doing in debug.py of the PythonCardPrototype package.
>

Not the same.  Yours is a has-a, I think an is-a makes more sense.

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

RE: [PyCrust] Thoughts...

[Kevin A. <al...@se...>]

> [mailto:pyc...@li...]On Behalf Of Robin
> Dunn
> 3. It would be nice if Shell (or maybe ShellWindow) derived from Editor.
> That way it could more easily be used as a wxWindow, moved, given
> to sizers,
> etc.  Unfortunatly doing
>
>     class ShellWindow(PyCrustShell.Shell, PyCrustEditor.Editor):
>     ...
>
> doesn't quite work because of name clashes between the classes.

This may not be directly relevant to what Robin is asking, but this is what
I'm currently doing in debug.py of the PythonCardPrototype package.

class PyCrustFrame(wxMiniFrame):
    def __init__(self, parent, ID, title, pos, size, parentApp):
        wxMiniFrame.__init__(self, parent, ID, title, pos, size,
style=wxDEFAULT_FRAME_STYLE | wxTINY_CAPTION_HORIZ)

        parentApp.shell = Shell(editorParent=self)
        # KEA this is temporary until we decide what reference
        # we want here
        parentApp.shell.interp.locals['pcapp'] = parentApp
        self.parentApp = parentApp

        EVT_CLOSE(self, self.onCloseMe)

    def onCloseMe(self, event):
        self.Show(false)



in model.py, the window is invoked with

    def showShell( self ) :

        if debug.PYCRUST_FOUND and self._showShell :
            # KEA see comments in showMessageWatcher about frames
            bg = self._iterator.getCurrentBackground()
            position = Configuration().getOption('shellPosition')
            size = Configuration().getOption('shellSize')
            self.shellFrame = debug.PyCrustFrame(None, -1, 'Shell',
                                                 position, size,
                                                 parentApp=self)
            self.shellFrame.Show(true)

ka

[PyCrust] Thoughts...

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

1. It would be nice if Shell.__init__ could accept a dict for the locals,
which could then be augmented with the locals you already provide if you
like.

2. Since PyCrust is a Python package, do we really need filenames like
PyCrustShell.py and PyCrustEditor.py?  When importing it just looks
redundant:  "from PyCrust.PyCrustShell import Shell"  Or maybe
PyCrust.__init__.py could just import the major classes into it's namespace
so we just have to use "import PyCrust" and then use "PyCrust.Shell"

3. It would be nice if Shell (or maybe ShellWindow) derived from Editor.
That way it could more easily be used as a wxWindow, moved, given to sizers,
etc.  Unfortunatly doing

    class ShellWindow(PyCrustShell.Shell, PyCrustEditor.Editor):
    ...

doesn't quite work because of name clashes between the classes.


That's all for now.

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

RE: [PyCrust] namespace viewer request

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

How does the name "PyFilling" grab you for the namespace viewer? <wink>

(And just how far can we stretch this pie pun?)

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

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Kevin Altis
Sent: Tuesday, August 07, 2001 12:15 PM
To: pyc...@li...
Subject: [PyCrust] namespace viewer request

I would like to have a namespace viewer as part of PyCrust and PythonCard.
There is one that sort of works in the wxPython 2.3.1 demo.py Cool
Contribs -> pyTree

ka


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

[PyCrust] FW: [pythoncard] updated turtle sample with doc strings and shell init

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

This is good to know for anyone else using PyCrust as a plugin.

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

-----Original Message-----
From: Patrick K. O'Brien [mailto:po...@or...]
Sent: Wednesday, August 08, 2001 6:41 PM
To: pyt...@ya...
Subject: RE: [pythoncard] updated turtle sample with doc strings and shell
init

Kevin had asked me to confirm that his example uses the shell run method the
way it was intended and, indeed, he's got it nailed. The only minor
suggestion I had was that if you had a lot of commands to run you could save
yourself a few keystrokes with this variation:

run = self.stack.app.shell.run
run('from wxTurtle import *')
run('dc = TurtleDC(pcapp.getCurrentBackground().panel)')
run('t = Pen(dc)')

You could also store all of those commands in a separate file and then do
shell.runfile('file') which simply iterates through the file calling run()
on each line.

A final variation exists if you don't want the commands echoed to the shell
editor, which is to send a verbose=0 parameter (it defaults to 1, or True)
to the run command like this:

run('from wxTurtle import *', verbose=0)
run('dc = TurtleDC(pcapp.getCurrentBackground().panel)', verbose=0)
run('t = Pen(dc)', verbose=0)

That way when the shell pops up they won't be looking at all these lines of
code that were pushed through behind the scenes. I would think in most cases
the shell user is going to want to see the commands, which is why run
defaults to verbose turned on.

Looking at the example I gave I'm tempted to suggest that "echo" might be a
better parameter name than "verbose". It also seems a bit tedious to have to
include it as a parameter on each call. I'm open to any suggestions.

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

-----Original Message-----
From: Kevin Altis [mailto:al...@se...]
Sent: Wednesday, August 08, 2001 5:49 PM
To: Pythoncard
Subject: [pythoncard] updated turtle sample with doc strings and shell init

I updated the aTurtle.py and wxTurtle.py modules of the turtle sample so
that all the methods now have doc strings. This means that if you're using
the shell to control the turtle interactively, when you type the open parens
for a method:
>>> t.fd(

you'll get a calltip telling you what the method does. That should improve
the ease of experimenting with the various turtle commands.

To highlight another benefit of the shell I added a menu item that
auto-initializes the shell, so the user doesn't have to remember the import
commands. The method in test_turtle.py looks like:

    def on_menuCommandsShellInit_select(self, menu, event):
        if self.stack.app.shell is not None:
            shell = self.stack.app.shell
            shell.run('from wxTurtle import *')
            shell.run('dc = TurtleDC(pcapp.getCurrentBackground().panel)')
            shell.run('t = Pen(dc)')
        else:
            dlg = PythonCardPrototype.dialog.AlertDialog(self,
                                                         "The shell isn't
available",
                                                         "PythonCard Error")

Given that this is probably the default initialization a user would want, I
wanted to have the shell.run commands in the __init__ of the background, but
we can't do this yet, because we need an 'openBackground' message that
occurs after all initialization is done. Right now, the Background __init__
is done before any of the Shell, Message Watcher, or Property Editor windows
are created.

As always, the changes to the turtle sample will be part of the next
release.

ka

[PyCrust] Announce: PyCrust 0.5 release now available

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

PyCrust version 0.5 has been committed to CVS and is also available as a
.zip file at
http://sourceforge.net/project/showfiles.php?group_id=31263&release_id=47302
. Please give it a try and see what you think.

PyCrust is an interactive Python Shell that can be run standalone, or
integrated into other Python applications built with wxPython. PyCrust is
built around Scintilla, and requires wxPython and Python 2.1 or greater.

http://sourceforge.net/projects/pycrust/

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

RE: [PyCrust] CallTips and AutoComp need work

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

Uggghhhh. Found the problem - missing a try: block in one spot that does an
eval().

---
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 08, 2001 1:09 PM
To: pyc...@li...
Subject: RE: [PyCrust] CallTips and AutoComp need work

The shell editor contains text and nothing else. I can't do anything
introspective with that text until I turn it into an object reference. That
means there is no way to get a call tip or auto complete list without doing
an eval() on that text. Doing an eval() may have side effects. Or it may
simply fail because the text passed to it is not valid syntax or not a known
object.

At this point, the PyCrust calltip and autocomp do NOT eval() code that
contains a method or function call, such as in your third example below. So
it won't pop up a call tip or autocomp on those. However, in your third
example, it does try to eval('.getText') and that fails, as you might
expect. But the eval() is in a try: block so the program goes on without a
hitch. The result that you are seeing is that this failure inside the try:
block writes an error message to the dos window and I'm pretty sure that has
to do with where the current functions are located and I am working on
restructuring that code.

RE: [PyCrust] CallTips and AutoComp need work

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

The shell editor contains text and nothing else. I can't do anything
introspective with that text until I turn it into an object reference. That
means there is no way to get a call tip or auto complete list without doing
an eval() on that text. Doing an eval() may have side effects. Or it may
simply fail because the text passed to it is not valid syntax or not a known
object.

At this point, the PyCrust calltip and autocomp do NOT eval() code that
contains a method or function call, such as in your third example below. So
it won't pop up a call tip or autocomp on those. However, in your third
example, it does try to eval('.getText') and that fails, as you might
expect. But the eval() is in a try: block so the program goes on without a
hitch. The result that you are seeing is that this failure inside the try:
block writes an error message to the dos window and I'm pretty sure that has
to do with where the current functions are located and I am working on
restructuring that code.

The other issue, to me, is, wouldn't it be nice to be able to get an
autocomplete list on simple code like "dir()." and so forth? Even your third
example doesn't have a serious side effect.

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

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Kevin Altis
Sent: Wednesday, August 08, 2001 12:47 PM
To: pyc...@li...
Subject: RE: [PyCrust] CallTips and AutoComp need work

I don't see how you could know whether a method has side-effects or not. I
reiterate what I said originally, which is that if you can't get a doc
string without doing an eval on the code, then you shouldn't try. That means
stuff like this in PythonCard:
bg = pcapp.getCurrentBackground() # can return a doc string
fld1 = bg.find('field1')          # can return a doc string
bg.find('field1).getText()        # can't return a doc string for getText

Does that make sense?

RE: [PyCrust] CallTips and AutoComp need work

[Kevin A. <al...@se...>]

I don't see how you could know whether a method has side-effects or not. I
reiterate what I said originally, which is that if you can't get a doc
string without doing an eval on the code, then you shouldn't try. That means
stuff like this in PythonCard:
bg = pcapp.getCurrentBackground() # can return a doc string
fld1 = bg.find('field1')          # can return a doc string
bg.find('field1).getText()        # can't return a doc string for getText

Does that make sense?

ka
---
Here's the original discussion started offlist.

pat_orbtech: It isn't really an error. I expect it to fail. That is why it
is in a try: block.
pat_orbtech: The only way I know it will fail is to try it.
pat_orbtech: The issue is what to do about the error messages that are going
to the dos window.
altis: in general it is probably a bad idea to be doing that given that the
method would be doing an action twice then, right?
altis: once when you try it and then for real
altis: i would think that if you can't just get the doc string then you
shouldn't have a call tip, executing code is not good

Not in this context. The only way to get a docstring or anything else is to
have an object. The only way to get the object is to eval a string. So I'm
doing eval() on a string to get the object. If the string isn't a valid
object then it fails. I'm limiting what I eval to object strings that can't
have side effects (at least that is the intent) but even then I might be
evaling something that isn't a valid object. I need the object to get its
attributes or docstring or whatever. This is the way it is done in IDLE,
Boa, PythinWin, etc. If there was a better way I would expect them to be
doing it.

> -----Original Message-----
> From: pyc...@li...
> [mailto:pyc...@li...]On Behalf Of Patrick
> K. O'Brien
> Sent: Wednesday, August 08, 2001 10:41 AM
> To: pycr
> Subject: [PyCrust] CallTips and AutoComp need work
>
>
> The way that python code is being evaluated to determine the object for a
> call tip or autocomplete has not been perfected. If anyone would like to
> take a look at the code and make suggestions, please do so.
> Anyone that has
> discovered an issue related to this should feel free to reply to this
> message so that we can flesh out exactly what needs improving. Thanks.
>
> ---
> Patrick K. O'Brien
> Orbtech
> "I am, therefore I think."
>
>
>
> _______________________________________________
> PyCrust-users mailing list
> PyC...@li...
> http://lists.sourceforge.net/lists/listinfo/pycrust-users
>

[PyCrust] CallTips and AutoComp need work

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

The way that python code is being evaluated to determine the object for a
call tip or autocomplete has not been perfected. If anyone would like to
take a look at the code and make suggestions, please do so. Anyone that has
discovered an issue related to this should feel free to reply to this
message so that we can flesh out exactly what needs improving. Thanks.

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

[PyCrust] Re: pycrust 0.3 that will be part of the release tonight

[Neil H. <ne...@sc...>]

Patrick:
> [Neil]
> > # Define a set of character that when typed fills up the
> > selected word.
> > set void AutoCSetFillUps=2112(, string characterSet)
>
> Say what? You've got a dumber me at the moment. And
> I still can't make heads or tails of this one. :-)

   There is a set of characters that say accept the current choice in the
list. Say you think that the user typing '!' should choose the selection
then include it in the fillup character set.

   Many of these features are contributed and I haven't done as much editing
or writing of documentation as they need.

   Neil

[PyCrust] Fw: pycrust 0.3 that will be part of the release tonight

[Neil H. <ne...@sc...>]

[I'm forwarding this to the list as these sorts of discussions should really
occur there where more people can contribute and so they will get archived]

Patrick:

> Autocomplete: When you type a dot you get the list, then you
> type n characters followed by backspacing n characters you are
> back at the dot and the list has gone away. ...

   Whether the default should be cancelling by deleting to the dot or
deleting the dot is a bit of a personal preference thing. There is a
difference here between invoking it for a dot and invoking it because the
user has started typing an identifier and asked for a list. My thinking is
that you have removed all of the characters that you put into the identifier
and so the annoying box should disappear. There should probably be another
preference setting to define this.

> AutoCSetFillUps, and AutoCSetChooseSingle: I couldn't find
> any documentation on these and Google came up empty. Is
> there a description somewhere? I don't know what they do
> or how to use them.

   These are not described in the main documentation:
http://www.scintilla.org/ScintillaDoc.html
   although there are brief comments in the
scintilla/include/scintilla.iface file which is the definition of the
Scintilla API.

# Define a set of character that when typed fills up the selected word.
set void AutoCSetFillUps=2112(, string characterSet)

# Should a single item auto-completion list automatically choose the item.
set void AutoCSetChooseSingle=2113(bool chooseSingle,)

> Coloring: I had a sense that the lexer wanted to own the whole
> doc but thought I might be missing something. You confirmed,
> thank you. I'll look at Mark's code and see if my head spins,
> which tends to happen when I try to make sense of the
> PythonWin code.

   Maybe we need a dumber Mark ;)

   Neil

[PyCrust] namespace viewer request

[Kevin A. <al...@se...>]

I would like to have a namespace viewer as part of PyCrust and PythonCard.
There is one that sort of works in the wxPython 2.3.1 demo.py Cool
Contribs -> pyTree

ka

[PyCrust] CVS Updated

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

CVS has been updated with a new revision that now has calltip support, along
with some bug fixes in the autocomplete feature. If you are using wxPython
2.3.1, PyCrust is suffering from the same accelerator key problems as
everyone else. Other than that, enjoy.

http://sourceforge.net/projects/pycrust/

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

RE: [PyCrust] how do you load and run the Data samples?

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

I had intended to add shell.savefile() when I get the command history
feature in place as basically you just want to save the command history in
its entirety (or at least to a file that you could then edit and remove what
you don't want). But to get a good command history capability I wanted to
make the editor more like a true shell where you couldn't modify previous
input/output except by recalling commands to the current prompt. There are
still a few loose ends to tie up with that and the coloring and such, with
which I'm not entirely satisfied.

As for the menu, I agree and am open to suggestions. PyCrust.py has a menu
so you can see what I've got so far - basically File, Edit and Help. And the
Edit menu choices are enabled/disabled appropriately.

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

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Kevin Altis
Sent: Friday, August 03, 2001 11:40 AM
To: pyc...@li...
Subject: RE: [PyCrust] how do you load and run the Data samples?

Okay, the obvious next question is what is the process of copying and
pasting or doing a shell.savefile() or whatever to take all or only the
selected part of the shell window contents and making it into one of these
runs? Minus the output of course?

On a related note, should we give the shell (PyCrust) a hierarchical menu in
the Debug menu of PythonCard so it has the ability to respond to some menu
commands? If so, we'll need to coordinate menu ids, functions to bind, etc.

ka

> -----Original Message-----
> From: pyc...@li...
> [mailto:pyc...@li...]On Behalf Of Patrick
> K. O'Brien
> Sent: Friday, August 03, 2001 9:19 AM
> To: pyc...@li...
> Subject: RE: [PyCrust] how do you load and run the Data samples?
>
>
> shell.runfile('Data\PythonTutorial.py')
>
> This is something fun I was toying with. PythonTutorial.py is a series of
> commands, such as one would enter in the shell directly. I actually lifted
> them directly from Guido's tutorial. runfile() runs through all
> the commands
> and pushes them into the editor. So it kind of simulates an actual user
> session except that the shell results are real live results from the
> interpreter. If runfile() finds any command intended for the shell -
> shell.whatever() - it runs those "silently" so that you can build into the
> tutorial.py file things like shell.clear() and shell.pause() and such to
> interact with the user during the tutorial.
>
> This isn't really complete. But the basics are there and it did
> force me to
> support pushing commands to the interpreter recursively, which
> was a bit of
> a mind-bender. I think this could be extended to do some wild stuff.
>
> So, for PythonCard, you could create tutorials that would
> demonstrate, live,
> how to mess with stuff from the shell.
>
> ---
> Patrick K. O'Brien
> Orbtech
> "I am, therefore I think."
>
> -----Original Message-----
> From: pyc...@li...
> [mailto:pyc...@li...]On Behalf Of Kevin Altis
> Sent: Friday, August 03, 2001 10:41 AM
> To: pyc...@li...
> Subject: [PyCrust] how do you load and run the Data samples?
>
> There is a Data directory in the distribution with:
>   PyCrustTutorial.py
>   PythonTutorial.py
>
> How can these be loaded and run from within PyCrust?
>
> ka
>
> _______________________________________________
> 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
>


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

RE: [PyCrust] how do you load and run the Data samples?

[Kevin A. <al...@se...>]

Okay, the obvious next question is what is the process of copying and
pasting or doing a shell.savefile() or whatever to take all or only the
selected part of the shell window contents and making it into one of these
runs? Minus the output of course?

On a related note, should we give the shell (PyCrust) a hierarchical menu in
the Debug menu of PythonCard so it has the ability to respond to some menu
commands? If so, we'll need to coordinate menu ids, functions to bind, etc.

ka

> -----Original Message-----
> From: pyc...@li...
> [mailto:pyc...@li...]On Behalf Of Patrick
> K. O'Brien
> Sent: Friday, August 03, 2001 9:19 AM
> To: pyc...@li...
> Subject: RE: [PyCrust] how do you load and run the Data samples?
>
>
> shell.runfile('Data\PythonTutorial.py')
>
> This is something fun I was toying with. PythonTutorial.py is a series of
> commands, such as one would enter in the shell directly. I actually lifted
> them directly from Guido's tutorial. runfile() runs through all
> the commands
> and pushes them into the editor. So it kind of simulates an actual user
> session except that the shell results are real live results from the
> interpreter. If runfile() finds any command intended for the shell -
> shell.whatever() - it runs those "silently" so that you can build into the
> tutorial.py file things like shell.clear() and shell.pause() and such to
> interact with the user during the tutorial.
>
> This isn't really complete. But the basics are there and it did
> force me to
> support pushing commands to the interpreter recursively, which
> was a bit of
> a mind-bender. I think this could be extended to do some wild stuff.
>
> So, for PythonCard, you could create tutorials that would
> demonstrate, live,
> how to mess with stuff from the shell.
>
> ---
> Patrick K. O'Brien
> Orbtech
> "I am, therefore I think."
>
> -----Original Message-----
> From: pyc...@li...
> [mailto:pyc...@li...]On Behalf Of Kevin Altis
> Sent: Friday, August 03, 2001 10:41 AM
> To: pyc...@li...
> Subject: [PyCrust] how do you load and run the Data samples?
>
> There is a Data directory in the distribution with:
>   PyCrustTutorial.py
>   PythonTutorial.py
>
> How can these be loaded and run from within PyCrust?
>
> ka
>
> _______________________________________________
> 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] how do you load and run the Data samples?

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

shell.runfile('Data\PythonTutorial.py')

This is something fun I was toying with. PythonTutorial.py is a series of
commands, such as one would enter in the shell directly. I actually lifted
them directly from Guido's tutorial. runfile() runs through all the commands
and pushes them into the editor. So it kind of simulates an actual user
session except that the shell results are real live results from the
interpreter. If runfile() finds any command intended for the shell -
shell.whatever() - it runs those "silently" so that you can build into the
tutorial.py file things like shell.clear() and shell.pause() and such to
interact with the user during the tutorial.

This isn't really complete. But the basics are there and it did force me to
support pushing commands to the interpreter recursively, which was a bit of
a mind-bender. I think this could be extended to do some wild stuff.

So, for PythonCard, you could create tutorials that would demonstrate, live,
how to mess with stuff from the shell.

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

-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Kevin Altis
Sent: Friday, August 03, 2001 10:41 AM
To: pyc...@li...
Subject: [PyCrust] how do you load and run the Data samples?

There is a Data directory in the distribution with:
  PyCrustTutorial.py
  PythonTutorial.py

How can these be loaded and run from within PyCrust?

ka

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

[PyCrust] how do you load and run the Data samples?

[Kevin A. <al...@se...>]

There is a Data directory in the distribution with:
  PyCrustTutorial.py
  PythonTutorial.py

How can these be loaded and run from within PyCrust?

ka

Re: [PyCrust] AutoComplete window size

[Neil H. <ne...@sc...>]

Patrick K. O'Brien:

   wxSTC questions should really go to the wxPython list so Robin and others
can see them.

> Is there a way to change the size, particularly the width, of the
> auto-completion list window? Some attribute names can be long
> and it seems like the window could stand to be a bit wider.

   The Windows and GTK+ platform layers size the list box to fit the widest
string. It looks like the wxSTC platform code (in
contrib\stc\contrib\src\stc\PlatWX.cpp) does not do this although there is a
call to GetBestSize which may be returning a smaller width than will fit the
widest string.

   Neil