pycrust-users Mailing List for PyCrust (Page 6)
Brought to you by:
pobrien
Menu
▾
▴
pycrust-users — PyCrust Users and Developers
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(76) |
Sep
(27) |
Oct
(5) |
Nov
(13) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(1) |
Feb
(24) |
Mar
|
Apr
(1) |
May
(3) |
Jun
(2) |
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2003 |
Jan
|
Feb
(4) |
Mar
(5) |
Apr
(3) |
May
(4) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
(2) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Patrick K. O'B. <po...@or...> - 2001-08-14 14:19:04
|
In the light of a new day, and with a fresh cup of coffee, I have renamed
these attributes to the following:
autoCompleteIncludeMagic = 1
autoCompleteExcludeSingle = 0
autoCompleteExcludeDouble = 0
These changes will be checked into cvs in a little while. Prepare
accordingly. :-)
---
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 11:46 PM
To: pycr
Subject: [PyCrust] Auto completion filters now available
I just checked into cvs some changes to support filters on the auto
completion lists.
To exclude attributes with a single underscore prefix:
shell.editor.autoCompleteFilterSingle = 1
To exclude attributes with a double underscore prefix:
shell.editor.autoCompleteFilterDouble = 1
To exclude both, set them both to true. You can set and unset these in the
shell to see how they work. Try them with the PythonCard proof.py sample
application, which has a lot of hidden attributes now.
---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."
_______________________________________________
PyCrust-users mailing list
PyC...@li...
http://lists.sourceforge.net/lists/listinfo/pycrust-users
|
|
From: Neil H. <ne...@sc...> - 2001-08-14 08:11:46
|
Kevin:
> class StaticLine( Widget ) :
> ...
> def _setLayout( self, aString ) :
> raise NotImplementedError
>
> def _getLayout( self ) :
> return self._layout
Python 2.2 will be introducing 'getset' attributes that will probably be
a better choice for widget attributes than using the __getattr__ and
__setattr__ hooks. They will look like this:
class StaticLine( Widget ) :
...
def _setLayout( self, aString ) :
raise NotImplementedError
def _getLayout( self ) :
return self._layout
layout = getset(_getLayout, _setLayout)
Python 2.2 may not be available for quite some time so its sensible to
stay with the current design for now. The getset feature is also best for
attributes that are defined statically for a class which is the case for
widgets but not for the set of components that are contained by a
background.
Neil
|
|
From: Kevin A. <al...@se...> - 2001-08-14 07:48:15
|
Apologies, it is late and I hit return too early. That was supposed to go to Patrick, not the list, it is a PythonCard issue. ka > -----Original Message----- > From: pyc...@li... > [mailto:pyc...@li...]On Behalf Of Kevin > Altis > Sent: Tuesday, August 14, 2001 12:43 AM > To: pyc...@li... > Subject: [PyCrust] __setattr__ no longer strict > > > The attribute checks used to be strict, but now they're not. > > >>> comp.button1.bob = "hello" > > shouldn't be possible, since there is no 'bob' attribute. I found > this while > trying to decide how I was going to deal with attributes that can only be > set at initialization. What I came up with was to go ahead and > define a _get > and _set but have the _set method raise an exception. As an example, I > changed StaticLine and checked in widget.py. > > class StaticLine( Widget ) : > ... > def _setLayout( self, aString ) : > raise NotImplementedError > > def _getLayout( self ) : > return self._layout > > So, then I tried: > > >>> comp.staticlineH.layout > 'horizontal' > >>> comp.staticlineH.layout = 'bob' > > The layout = 'bob' should throw an exception, but it doesn't for some > reason?! I tried this standalone in proof.py and in the shell and got the > same results. I added a _setName to the Widget class that does the same > NotImplementedError. > > Maybe your original was better before we were trying to get the > self._magicGetPrefix to work?! > > On a lighter note, it is sort of fun to define toolTips on the fly. > > comp.button1.toolTip = 'Hello World' > > And I sure do like not have _ and __ show up anymore. > > ka > > > _______________________________________________ > PyCrust-users mailing list > PyC...@li... > http://lists.sourceforge.net/lists/listinfo/pycrust-users > |
|
From: Kevin A. <al...@se...> - 2001-08-14 07:42:06
|
The attribute checks used to be strict, but now they're not.
>>> comp.button1.bob = "hello"
shouldn't be possible, since there is no 'bob' attribute. I found this while
trying to decide how I was going to deal with attributes that can only be
set at initialization. What I came up with was to go ahead and define a _get
and _set but have the _set method raise an exception. As an example, I
changed StaticLine and checked in widget.py.
class StaticLine( Widget ) :
...
def _setLayout( self, aString ) :
raise NotImplementedError
def _getLayout( self ) :
return self._layout
So, then I tried:
>>> comp.staticlineH.layout
'horizontal'
>>> comp.staticlineH.layout = 'bob'
The layout = 'bob' should throw an exception, but it doesn't for some
reason?! I tried this standalone in proof.py and in the shell and got the
same results. I added a _setName to the Widget class that does the same
NotImplementedError.
Maybe your original was better before we were trying to get the
self._magicGetPrefix to work?!
On a lighter note, it is sort of fun to define toolTips on the fly.
comp.button1.toolTip = 'Hello World'
And I sure do like not have _ and __ show up anymore.
ka
|
|
From: Patrick K. O'B. <po...@or...> - 2001-08-14 04:43:28
|
I just checked into cvs some changes to support filters on the auto completion lists. To exclude attributes with a single underscore prefix: shell.editor.autoCompleteFilterSingle = 1 To exclude attributes with a double underscore prefix: shell.editor.autoCompleteFilterDouble = 1 To exclude both, set them both to true. You can set and unset these in the shell to see how they work. Try them with the PythonCard proof.py sample application, which has a lot of hidden attributes now. --- Patrick K. O'Brien Orbtech "I am, therefore I think." |
|
From: Patrick K. O'B. <po...@or...> - 2001-08-13 21:48:07
|
I currently remove duplicates and sort the list.
---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."
-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Neil Hodgson
Sent: Monday, August 13, 2001 4:39 PM
To: pyc...@li...
Subject: Re: [PyCrust] Should ._getAttributeNames() be recursive?
Patrick K. O'Brien:
> 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.)
Do you filter out any duplicate names? My implementation of
getAttributeNames, which can be fixed if needed, will currently list all of
the attributes available on a class which includes those in base classes.
Another issue is that a subclass may decide not to offer all the
attributes of a base class, possibly because of security or modularity
reasons, although I imagine this is quite rare.
> How does that strike you folks? Anyone want to write an "Extended
> Introspection PEP?"
I think the next stage is to bring this up informally on
comp.lang.python.
Neil
_______________________________________________
PyCrust-users mailing list
PyC...@li...
http://lists.sourceforge.net/lists/listinfo/pycrust-users
|
|
From: Neil H. <ne...@sc...> - 2001-08-13 21:39:39
|
Patrick K. O'Brien:
> 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.)
Do you filter out any duplicate names? My implementation of
getAttributeNames, which can be fixed if needed, will currently list all of
the attributes available on a class which includes those in base classes.
Another issue is that a subclass may decide not to offer all the
attributes of a base class, possibly because of security or modularity
reasons, although I imagine this is quite rare.
> How does that strike you folks? Anyone want to write an "Extended
> Introspection PEP?"
I think the next stage is to bring this up informally on
comp.lang.python.
Neil
|
|
From: Kevin A. <al...@se...> - 2001-08-13 16:28:22
|
I didn't want to cross-post, so here is the link on the PythonCard list about 'pycrustrc.py' files as used by PythonCard. http://groups.yahoo.com/group/pythoncard/message/492 ka > -----Original Message----- > From: pyc...@li... > [mailto:pyc...@li...]On Behalf Of Patrick > K. O'Brien > Sent: Sunday, August 12, 2001 11:25 AM > To: pyc...@li... > Subject: RE: [PyCrust] .pycrustrc files > > > Relative works as well. So shell.runfile('.pycrustrc.py') should > pick up the > one in the current directory. > > --- > Patrick K. O'Brien > Orbtech > "I am, therefore I think." > > -----Original Message----- > From: pyc...@li... > [mailto:pyc...@li...]On Behalf Of Kevin Altis > Sent: Sunday, August 12, 2001 1:19 PM > To: pyc...@li... > Subject: RE: [PyCrust] .pycrustrc files > > I forgot shell.runfile() existed. I just pass it a full path name? > > ka > > > -----Original Message----- > > From: pyc...@li... > > [mailto:pyc...@li...]On Behalf Of Patrick > > K. O'Brien > > Sent: Sunday, August 12, 2001 11:17 AM > > To: pyc...@li... > > Subject: RE: [PyCrust] .pycrustrc files > > > > > > shell.runfile() would be better short-term, than iterating shell.run(). > > > > I haven't given enough thought to the long-term plan. > > > > --- > > Patrick K. O'Brien > > Orbtech > > "I am, therefore I think." > > > > -----Original Message----- > > From: pyc...@li... > > [mailto:pyc...@li...]On Behalf Of > Kevin Altis > > Sent: Sunday, August 12, 2001 12:38 PM > > To: Pycrust-Users > > Subject: [PyCrust] .pycrustrc files > > > > Patrick, > > have you settled on a name for files to be automatically executed when > > PyCrust starts up? .pycrustrc sounds like what we were talking > > about a week > > ago. I'm going to change how the shell starts up in PythonCard. > > If there is > > a .pycrustrc file (or whatever the name is going to be) in the package > > directory, then it will load that file first, then it will load any > > .pycrustrc file it finds in the current working directory. > > > > So, my generic .pycrustrc will probably have: > > bg = pcapp.getCurrentBackground() > > comp = bg.components > > > > The .pycrustrc for the turtle sample will have: > > from wxTurtle import * > > dc = TurtleDC(pcapp.getCurrentBackground().panel) > > t = Pen(dc) > > > > The turtle sample .pycrustrc won't rely on the main .pycrustrc , because > > users could define their own .pycrustrc that wouldn't define 'bg' > > and 'comp' > > > > I'm just going to use readlines and pass each line to > > shell.run() > > > > Does this sound reasonable? Maybe PyCrust should have its own > method that > > looks for a .pycrustrc in the directory passed in as a parameter, > > and if one > > exists, it reads it in and does the shell.run() commands? The > > return result > > would indicate success (1) or failure (0). That would increase > the chance > > that all apps using PyCrust follow the same rules. > > > > 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 > > > _______________________________________________ > PyCrust-users mailing list > PyC...@li... > http://lists.sourceforge.net/lists/listinfo/pycrust-users > |
|
From: Patrick K. O'B. <po...@or...> - 2001-08-13 15:38:03
|
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."
|
|
From: Robin D. <ro...@al...> - 2001-08-13 15:26:03
|
> 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! |
|
From: Patrick K. O'B. <po...@or...> - 2001-08-13 14:54:21
|
I'd like to bring this to something of a resolution. The bottom line is that I folded under the weight of Kevin and Neil's arguments and implemented this feature as they conceived it. Everyone should be happy with the result, as the feature is pretty sweet inside PythonCard. Feel free to check out the latest from cvs. For the record, I don't think I did a very good job explaining my idea of how to extend this to make the hook even more flexible. At the same time, my way would have resulted in a lot more code and a lot more indirection. Kevin and Neil's way is definitely shorter and cleaner. However, I still have some reservations. I'm still a little uncomfortable calling object._getAttributeNames() when there is a chance that some object may have that very method but use it for something completely different. I know it is unlikely, but I'd like to see it made even more unlikely. Now, it seems to me that we can't be the only ones to have faced this challenge. We have objects with attributes that aren't exposed through the normal Python conventions, but we would like them to be. That raises the question of whether Python itself should change. Python keeps track of object attributes in object.__dict__, object.__methods__, and object.__members___. The dir() function exposes these attributes. So it seems to me that it might be nice if Python were extended to allow the dir() function to also expose magic attributes that the object wanted exposed. Perhaps there would then be an object.__magic__ attribute for these and a standard way for the object to "expose" itself for introspection purposes. If that were the case, shells like PyCrust, PythonWin, Wing, etc. wouldn't have to change at all to get these magic attributes because dir(object) would expose them. How does that strike you folks? Anyone want to write an "Extended Introspection PEP?" --- Patrick K. O'Brien Orbtech "I am, therefore I think." -----Original Message----- From: pyc...@li... [mailto:pyc...@li...]On Behalf Of Neil Hodgson Sent: Sunday, August 12, 2001 6:29 PM To: pyc...@li... Subject: Re: [PyCrust] Attribute list hook Patrick K. O'Brien: > Rather than adopt a naming convention inside of PythonWin or PyCrust, how > about adding a function as a parameter to our "getAttributes" functions? So > PyCrust would look something like: Making it a method has the advantage that each class can redefine how this action is to be performed. For PythonCard we introspect the method names, for COM the _prop_map_get_ and _prop_map_put_ can be examined, and for a database the schema can be examined. This should be a convention so that it can be implemented independently by any library author rather than depending on the shell application knowing about particular libraries. If you want to parameterise PyCrust to avoid it knowing about the hook then that is fine, but applications embedding PyCrust will then typically instantiate PyCrust with exactly the same dynamic attribute discovery function. > pat_orbtech: Here is what I mean. In another project, say Boa for > example, _getAttributes might mean something entirely different > than how PythonCard defines it. My original name was "getAttributeNames" which is less likely to already be in use. If really necessary it can get the double underscore and a PEP to say how it must be implemented if it is implemented. > Or, Boa may have a method with a different name that returns the > list of attributes. I'd like to have the flexibility to allow for these > situations, rather than hardcode in an attempt to do object._getAttributes. Under this scheme, a class has to know about Boa (and PythonWin and Wing and ...) to expose its dynamic attributes. Or modify Boa to know about the class or library. Neil _______________________________________________ PyCrust-users mailing list PyC...@li... http://lists.sourceforge.net/lists/listinfo/pycrust-users |
|
From: Neil H. <ne...@sc...> - 2001-08-12 23:29:20
|
Patrick K. O'Brien: > Rather than adopt a naming convention inside of PythonWin or PyCrust, how > about adding a function as a parameter to our "getAttributes" functions? So > PyCrust would look something like: Making it a method has the advantage that each class can redefine how this action is to be performed. For PythonCard we introspect the method names, for COM the _prop_map_get_ and _prop_map_put_ can be examined, and for a database the schema can be examined. This should be a convention so that it can be implemented independently by any library author rather than depending on the shell application knowing about particular libraries. If you want to parameterise PyCrust to avoid it knowing about the hook then that is fine, but applications embedding PyCrust will then typically instantiate PyCrust with exactly the same dynamic attribute discovery function. > pat_orbtech: Here is what I mean. In another project, say Boa for > example, _getAttributes might mean something entirely different > than how PythonCard defines it. My original name was "getAttributeNames" which is less likely to already be in use. If really necessary it can get the double underscore and a PEP to say how it must be implemented if it is implemented. > Or, Boa may have a method with a different name that returns the > list of attributes. I'd like to have the flexibility to allow for these > situations, rather than hardcode in an attempt to do object._getAttributes. Under this scheme, a class has to know about Boa (and PythonWin and Wing and ...) to expose its dynamic attributes. Or modify Boa to know about the class or library. Neil |
|
From: Kevin A. <al...@se...> - 2001-08-12 18:30:32
|
Patrick and I started chatting on messenger and we ended up disagreeing on
implementation of Neil's idea, so I'm just copying the whole discussion
(with some minor edits) to the list.
ka
---
altis: i don't quite understand Neil's "code for PythonCard" and your own
hook. In order for Neil's stuff to work, PyCrust actually needs to call the
_getAttributes method when you build your list for a given object.
altis: i'll go ahead and add _getAttributes to the Background components if
I can understand what is going on
altis: can we make the call _getAttributes as Mark suggested?
pat_orbtech: I'm concerned that it isn't very generic. Another project might
implement it differently, or use that same call for something entirely
different.
altis: huh? the point of using the leading underscore is to indicate it is
private. your own getAttributes doesn't need the leading underscore, only
the one you're going to call for an object
pat_orbtech: Here is what I mean. In another project, say Boa for example,
_getAttributes might mean something entirely different than how PythonCard
defines it. Or, Boa may have a method with a different name that returns the
list of attributes. I'd like to have the flexibility to allow for these
situations, rather than hardcode in an attempt to do object._getAttributes.
pat_orbtech: Making the method private doesn't solve much.
altis: but you have to call the method, so you need to standardize on
something
pat_orbtech: No, I don't. I could call a function that was passed in as a
parameter and pass that function the object under investigation, like
getMorePlease(object). Since getMorePlease is a parameter, it could be a
reference to any function in PythonCard, or Boa, or whatever, that took an
object and returned a list of hidden, or magic, or whatever, attributes.
altis: yes, that is what i was just thinking, add the method name, not a
method object, to be passed in as part of the initialization
altis: that works for me
pat_orbtech: I just moved most of these functions we are talking about to a
new module called introspect, so if we want to get specific it would help to
be talking about the same thing.
pat_orbtech: In any case, the issue is having a function or method in
PythonCard that can take an object and return magic attributes. Then there
needs to be a way to tell PyCrust to use that method in its getAttributes
function.
altis: yes
altis: so, let's pass in the name at init getAttr='_getAttributes' would be
what I use assuming getAttr is the method parameter for init
altis: i added
def _getAttributeNames(self):
names = []
for name in self.data.keys():
names.append(name)
return names
altis: to WidgetDict, so as soon as you check in a change so we can pass in
the method name i'll change the init in debug.py, check in my changes and we
can try it
altis: of course that's a list, do you need a dictionary? and if so, what is
the value supposed to be?
pat_orbtech: I don't think we are quite on the same page.
altis: i just implemented what Neil described. what i want to do is pass in
the '_getAttributeNames' method name as part of my shell initialization and
then for every object, your code is going to check whether that method
exists and if so, get the extra list of attributes
pat_orbtech: That's not quite what I was thinking.
altis: you already have all the stuff from __dict__ ..., you just need the
hidden stuff
pat_orbtech: I know. The part I'm struggling with is getting passed the
method name.
altis: the method name is no longer hard-coded, i made up my own which I
pass to your initialization
altis: i could call mine _cheezyPoofs
pat_orbtech: I'm not saying it can't be done. I was just thinking of
something slightly different.
pat_orbtech: Are you going to send me a sting? I guess you would have to,
right?
altis: such as? i can't pass you a method object
pat_orbtech: sting = string
altis: then you do a recursive search for that method name and if found
execute it to get back a list of additional names
pat_orbtech: You could pass me a function that took an object as a
parameter. Then I would call that function passing it the object. Inside
that function you would do object._cheezyPoofs.
altis: nope, doesn't work
pat_orbtech: I want you to control how this works, not PyCrust.
altis: the extra names would have to be the same for every class which it
won't be
pat_orbtech: Why wouldn't that work? I'm giving you the object?
altis: WidgetDict defines the extra attributes as keys in a dictionary, the
Widgets themselves define the extra attributes as items with get/set, and
yet another class will define it differently still
altis: you're also requiring that the method being passed in at
initialization will then have to be around the life of the program, that is
lame
altis: perhaps we should move this to the list
pat_orbtech: no more lame than any function defined in a module.
pat_orbtech: it shouldn't be a method, just a function.
pat_orbtech: Look at Neil's original example:
def attrList(d):
try:
print d.getAttributeNames()
except AttributeError, x:
print "Empty"
pat_orbtech: I'm saying pass me attrList and I will call it with the object
under inspection and it can find the magic attributes. That way the
functionality stays inside PythonCard where it belongs. PyCrust just gives
you a hook.
pat_orbtech: Of course, attrList needs to be changed to return a list, not
print stuff out.
altis: well, i guess we should copy this discussion to the list. that just
seems broken to me with every code piece that wants to use the shell having
to define their own method to do the searching when the functionality
belongs in the shell
altis: and i think that is what neil is describing
pat_orbtech: If we were talking standard Python I would agree it belongs in
the shell. But we aren't. We're talking about a PythonCard specific
technique. So I think a hook is appropriate. But I'm more than willing to
debate this on the list.
altis: no, it isn't a pythoncard thing neil was talking about a general
solution that all classes could implement if they want enhanced support in
PyCrust
pat_orbtech: I know that's what what suggested, but until everyone adopts it
it is a PythonCard thing. And I'm not as unhappy with my solution as you
are.
altis: copying to the list now....
|
|
From: Patrick K. O'B. <po...@or...> - 2001-08-12 18:22:26
|
Relative works as well. So shell.runfile('.pycrustrc.py') should pick up the
one in the current directory.
---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."
-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Kevin Altis
Sent: Sunday, August 12, 2001 1:19 PM
To: pyc...@li...
Subject: RE: [PyCrust] .pycrustrc files
I forgot shell.runfile() existed. I just pass it a full path name?
ka
> -----Original Message-----
> From: pyc...@li...
> [mailto:pyc...@li...]On Behalf Of Patrick
> K. O'Brien
> Sent: Sunday, August 12, 2001 11:17 AM
> To: pyc...@li...
> Subject: RE: [PyCrust] .pycrustrc files
>
>
> shell.runfile() would be better short-term, than iterating shell.run().
>
> I haven't given enough thought to the long-term plan.
>
> ---
> Patrick K. O'Brien
> Orbtech
> "I am, therefore I think."
>
> -----Original Message-----
> From: pyc...@li...
> [mailto:pyc...@li...]On Behalf Of Kevin Altis
> Sent: Sunday, August 12, 2001 12:38 PM
> To: Pycrust-Users
> Subject: [PyCrust] .pycrustrc files
>
> Patrick,
> have you settled on a name for files to be automatically executed when
> PyCrust starts up? .pycrustrc sounds like what we were talking
> about a week
> ago. I'm going to change how the shell starts up in PythonCard.
> If there is
> a .pycrustrc file (or whatever the name is going to be) in the package
> directory, then it will load that file first, then it will load any
> .pycrustrc file it finds in the current working directory.
>
> So, my generic .pycrustrc will probably have:
> bg = pcapp.getCurrentBackground()
> comp = bg.components
>
> The .pycrustrc for the turtle sample will have:
> from wxTurtle import *
> dc = TurtleDC(pcapp.getCurrentBackground().panel)
> t = Pen(dc)
>
> The turtle sample .pycrustrc won't rely on the main .pycrustrc , because
> users could define their own .pycrustrc that wouldn't define 'bg'
> and 'comp'
>
> I'm just going to use readlines and pass each line to
> shell.run()
>
> Does this sound reasonable? Maybe PyCrust should have its own method that
> looks for a .pycrustrc in the directory passed in as a parameter,
> and if one
> exists, it reads it in and does the shell.run() commands? The
> return result
> would indicate success (1) or failure (0). That would increase the chance
> that all apps using PyCrust follow the same rules.
>
> 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
|
|
From: Kevin A. <al...@se...> - 2001-08-12 18:18:23
|
I forgot shell.runfile() existed. I just pass it a full path name? ka > -----Original Message----- > From: pyc...@li... > [mailto:pyc...@li...]On Behalf Of Patrick > K. O'Brien > Sent: Sunday, August 12, 2001 11:17 AM > To: pyc...@li... > Subject: RE: [PyCrust] .pycrustrc files > > > shell.runfile() would be better short-term, than iterating shell.run(). > > I haven't given enough thought to the long-term plan. > > --- > Patrick K. O'Brien > Orbtech > "I am, therefore I think." > > -----Original Message----- > From: pyc...@li... > [mailto:pyc...@li...]On Behalf Of Kevin Altis > Sent: Sunday, August 12, 2001 12:38 PM > To: Pycrust-Users > Subject: [PyCrust] .pycrustrc files > > Patrick, > have you settled on a name for files to be automatically executed when > PyCrust starts up? .pycrustrc sounds like what we were talking > about a week > ago. I'm going to change how the shell starts up in PythonCard. > If there is > a .pycrustrc file (or whatever the name is going to be) in the package > directory, then it will load that file first, then it will load any > .pycrustrc file it finds in the current working directory. > > So, my generic .pycrustrc will probably have: > bg = pcapp.getCurrentBackground() > comp = bg.components > > The .pycrustrc for the turtle sample will have: > from wxTurtle import * > dc = TurtleDC(pcapp.getCurrentBackground().panel) > t = Pen(dc) > > The turtle sample .pycrustrc won't rely on the main .pycrustrc , because > users could define their own .pycrustrc that wouldn't define 'bg' > and 'comp' > > I'm just going to use readlines and pass each line to > shell.run() > > Does this sound reasonable? Maybe PyCrust should have its own method that > looks for a .pycrustrc in the directory passed in as a parameter, > and if one > exists, it reads it in and does the shell.run() commands? The > return result > would indicate success (1) or failure (0). That would increase the chance > that all apps using PyCrust follow the same rules. > > 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 > |
|
From: Patrick K. O'B. <po...@or...> - 2001-08-12 18:14:43
|
shell.runfile() would be better short-term, than iterating shell.run(). I haven't given enough thought to the long-term plan. --- Patrick K. O'Brien Orbtech "I am, therefore I think." -----Original Message----- From: pyc...@li... [mailto:pyc...@li...]On Behalf Of Kevin Altis Sent: Sunday, August 12, 2001 12:38 PM To: Pycrust-Users Subject: [PyCrust] .pycrustrc files Patrick, have you settled on a name for files to be automatically executed when PyCrust starts up? .pycrustrc sounds like what we were talking about a week ago. I'm going to change how the shell starts up in PythonCard. If there is a .pycrustrc file (or whatever the name is going to be) in the package directory, then it will load that file first, then it will load any .pycrustrc file it finds in the current working directory. So, my generic .pycrustrc will probably have: bg = pcapp.getCurrentBackground() comp = bg.components The .pycrustrc for the turtle sample will have: from wxTurtle import * dc = TurtleDC(pcapp.getCurrentBackground().panel) t = Pen(dc) The turtle sample .pycrustrc won't rely on the main .pycrustrc , because users could define their own .pycrustrc that wouldn't define 'bg' and 'comp' I'm just going to use readlines and pass each line to shell.run() Does this sound reasonable? Maybe PyCrust should have its own method that looks for a .pycrustrc in the directory passed in as a parameter, and if one exists, it reads it in and does the shell.run() commands? The return result would indicate success (1) or failure (0). That would increase the chance that all apps using PyCrust follow the same rules. ka _______________________________________________ PyCrust-users mailing list PyC...@li... http://lists.sourceforge.net/lists/listinfo/pycrust-users |
|
From: Kevin A. <al...@se...> - 2001-08-12 17:37:47
|
Patrick, have you settled on a name for files to be automatically executed when PyCrust starts up? .pycrustrc sounds like what we were talking about a week ago. I'm going to change how the shell starts up in PythonCard. If there is a .pycrustrc file (or whatever the name is going to be) in the package directory, then it will load that file first, then it will load any .pycrustrc file it finds in the current working directory. So, my generic .pycrustrc will probably have: bg = pcapp.getCurrentBackground() comp = bg.components The .pycrustrc for the turtle sample will have: from wxTurtle import * dc = TurtleDC(pcapp.getCurrentBackground().panel) t = Pen(dc) The turtle sample .pycrustrc won't rely on the main .pycrustrc , because users could define their own .pycrustrc that wouldn't define 'bg' and 'comp' I'm just going to use readlines and pass each line to shell.run() Does this sound reasonable? Maybe PyCrust should have its own method that looks for a .pycrustrc in the directory passed in as a parameter, and if one exists, it reads it in and does the shell.run() commands? The return result would indicate success (1) or failure (0). That would increase the chance that all apps using PyCrust follow the same rules. ka |
|
From: Kevin A. <al...@se...> - 2001-08-12 17:07:31
|
If the window height is too small, you should probably change the size of the drop down menu, which currently can go off the bottom of the window. On my default shell window size 'shellPosition':(50, 600), 'shellSize':(700, 200), The 6 line menu probably needs to be 4 instead and I could see wanting it to be a bit bigger if I had a taller shell window. ka |
|
From: Patrick K. O'B. <po...@or...> - 2001-08-12 16:24:44
|
This has been checked in to CVS. Here is an example with the new parameter:
locals = {'__app__': 'PyCrust Application'}
self.shell = Shell(editorParent=self, introText=intro, locals=locals)
The implementation inside the Shell class looks like this:
self.locals = {'__name__': 'PyCrust',
'__doc__': 'PyCrust, The Python Shell.',
'__version__': version,
}
# Add the dictionary that was passed in.
if locals:
self.locals.update(locals)
As you can see, there is the potential for the passed in locals to replace
the dictionary values that I am setting in self.locals. Whenever I am faced
with the opportunity to allow a caller to override something, I almost
always allow it. I'm assuming that users of PyCrust want more control, not
less, even if it allows them to shoot themselves in the foot.
I should probably add a check to make sure that locals is a dictionary. I'm
still coming to terms with the right level of type checking in Python.
Anyone feel strongly about this? Is it necessary? Not necessary? Depends?
---
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: Sunday, August 12, 2001 8:43 AM
To: pyc...@li...
Subject: RE: [PyCrust] Thoughts...
That makes sense. I'll add it to the TODO list.
---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."
-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Robin Dunn
Sent: Friday, August 10, 2001 6:55 PM
To: pyc...@li...
Subject: [PyCrust] Thoughts...
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.
_______________________________________________
PyCrust-users mailing list
PyC...@li...
http://lists.sourceforge.net/lists/listinfo/pycrust-users
|
|
From: Patrick K. O'B. <po...@or...> - 2001-08-12 13:48:18
|
Rather than adopt a naming convention inside of PythonWin or PyCrust, how
about adding a function as a parameter to our "getAttributes" functions? So
PyCrust would look something like:
def getAttributes(self, object, getMore=None):
# 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 += getMore(object)
except:
pass
if hasattr(object, '__bases__'):
...
That way the function passed in as getMore has the opportunity to be named
anything and to do anything.
P.S. These methods got recast as functions and now reside in the introspect
module in CVS. They were also rewritten a bit. Just FYI.
---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."
-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Neil Hodgson
Sent: Saturday, August 11, 2001 7:37 PM
To: pyc...@li...
Subject: Re: [PyCrust] Attribute list hook
Mark Hammond:
> 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.
OK. I wasn't sure about the conventions behind "_" and "__" and which is
correct here. I think of "_" as a simple "private" and "__" as "deep
implementation mystery".
Neil
_______________________________________________
PyCrust-users mailing list
PyC...@li...
http://lists.sourceforge.net/lists/listinfo/pycrust-users
|
|
From: Patrick K. O'B. <po...@or...> - 2001-08-12 13:40:44
|
That makes sense. I'll add it to the TODO list. --- Patrick K. O'Brien Orbtech "I am, therefore I think." -----Original Message----- From: pyc...@li... [mailto:pyc...@li...]On Behalf Of Robin Dunn Sent: Friday, August 10, 2001 6:55 PM To: pyc...@li... Subject: [PyCrust] Thoughts... 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. |
|
From: Patrick K. O'B. <po...@or...> - 2001-08-12 13:17:40
|
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. --- Patrick K. O'Brien Orbtech "I am, therefore I think." -----Original Message----- From: pyc...@li... [mailto:pyc...@li...]On Behalf Of Robin Dunn Sent: Friday, August 10, 2001 8:08 PM To: pyc...@li... Subject: Re: [PyCrust] Thoughts... > > 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! _______________________________________________ PyCrust-users mailing list PyC...@li... http://lists.sourceforge.net/lists/listinfo/pycrust-users |
|
From: Patrick K. O'B. <po...@or...> - 2001-08-12 13:12:14
|
I made the names verbose in order to avoid name clashes when PythonCard was talking about including the PyCrust files in their directory. I'm not opposed to shortening the names now. I'd rather not make assumptions about which classes to import through the packages' __init__.py file, because of the number of ways PyCrust components can be used. Some users will use it for just its interpreter, others for the editor, others will use all the shell defaults but will provide their own editor, etc. I'll work on more sample apps that illustrate this, but for now there is PyCrustAlaCarte.py. --- Patrick K. O'Brien Orbtech "I am, therefore I think." -----Original Message----- From: pyc...@li... [mailto:pyc...@li...]On Behalf Of Robin Dunn Sent: Friday, August 10, 2001 6:55 PM To: pyc...@li... Subject: [PyCrust] Thoughts... 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" |
|
From: Neil H. <ne...@sc...> - 2001-08-12 00:37:42
|
Mark Hammond: > 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. OK. I wasn't sure about the conventions behind "_" and "__" and which is correct here. I think of "_" as a simple "private" and "__" as "deep implementation mystery". Neil |
|
From: Neil H. <ne...@sc...> - 2001-08-12 00:34:45
|
> PyCrust can be changed to use this with the getAttributes method in
> PyCrustInterp.py changed to:
PythonWin can have this as well by changing
Pythonwin\pywin\scintilla\view.py in the CScintillaView _AutoComplete
method:
if hasattr(ob, "__class__"):
items = items + _get_class_attributes(ob.__class__)
try:
items = items + ob.getAttributeNames()
except AttributeError:
pass
One useful thing that PythonWin does is to filter out the attributes that
start with "_" with
items = filter(lambda word: word[0]!='_', items)
as these are private. Could be an option.
Neil
|
1 message has been excluded from this view by a project administrator.
