pythoncard-users — PythonCard Users and Developers

[Pythoncard-users] PythonCard cvs tree cleanup

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

from SF admins: "The contents of the PythonCard module of the pythoncard CVS
repository have been removed."

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pythoncard/

The proto and PythonCardPrototype modules are still there and I have a
backup of the proof and proto files that were in the PythonCard branch if
anyone needs them. I figured that we would be moving beyond 'prototype'
pretty soon and would want to reuse the PythonCard branch without the old
files/dirs in there.

ka

[Pythoncard-users] "Why I Use HyperCard..." posts

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

Some of the info below has been covered on the list before, but I thought as
we approach the end of the year, it would be good to get some inspiration
from the "spirit of HyperCard".

Early in 2001, a plea went out to HyperCard users to tell Apple why
HyperCard should be brought back to life. Many of the online responses are
at the two URLs below.

  http://homepage.mac.com/iHUG/WhyWeUseHC.html
  http://homepage.mac.com/iHUG/WhyWeUseHCd2.html

What struck me as I read through these responses is the diversity of both
the people that use or used HyperCard and the types of applications they
created. We may never reach the ease-of-use and level of integration of the
HyperCard environment that allowed so many people, even non-programmers to
create such a wide variety of applications, but it is a nice goal.


A little more about the demise...
HyperCard, while still available, is a dead product and there is no plan to
revive it for OS X. The closest thing users are going to get from Apple
appears to be AppleScript Studio
  http://www.apple.com/applescript/macosx/ascript_studio/

There were a few articles about the demise of HyperCard, including this one:
  http://www.oreillynet.com/pub/a/mac/2001/03/29/mac_dev.html
(some of the comments at the bottom are interesting)

While Apple won't be reviving HyperCard, another company has a product
called Revolution
  http://www.runrev.com/
and you can even download a free trial that runs on the Mac classic, Mac OS
X, Windows, and Linux
  http://www.runrev.com/revolution/downloads/downloads.html

It is worth checking out for environment ideas to see what you do and don't
like. Please post any comments you have to the list.


In case this email just seems confusing...
The main goal of PythonCard (at least for me) continues to be the creation
of an open source, cross-platform GUI framework and environment for building
desktop applications. The framework is written in Python and the apps
produced use Python for the scripting language. I don't want to use
HyperTalk, some other xTalk variant, TCL, Perl, or JavaScript, I want to
leverage the Python language and the large number of quality libraries for
Python. Even if PythonCard ends up not having much in common with HyperCard
when we're done, I'll continue to draw inspiration from HyperCard. I'll get
back to work now :)

ka

[Pythoncard-users] from resourceEditor to layout editor

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

I'm going to start working on the resourceEditor again. First I want to make
sure that it is still working correctly after all the changes I've been
making in the last month. I'm pretty sure I didn't break anything and nobody
has reported a problem, but you never know.

I plan to add dialogs to edit the 'stack' and 'background' items and at
least a rudimentary menu editor. That should allow anyone to edit the
current resource format just using the resourceEditor and not have to resort
to editing the .rsrc.py files manually.


Possible enhancement list
  menu item to run the "current" app with toggle options for the runtime
tools
    this would basically be like the samples launcher app but integrated
into
    the resourceEditor
  a file history list in the File menu
  edit dialog resources
    support dialog resources in the main resource file
  select multiple widgets
  constrained move and resize of widgets
  snap to grid
  separate floating window with icons for selection of the standard widgets?


Please add your own suggestions to the enhancement list. If you like
particular GUI layout elements of HyperCard, Delphi, VB, Boa, wxDesigner,
etc. just list them here. I still have no idea how to provide a decent UI
for doing sizers, but maybe someone else can help figure that out or we can
figure out how to leverage wxDesigner for sizer layout? Hopefully, some
people besides myself will be interested in working on a revised
resourceEditor/layout editor.

As we start to move to a component model I want to promote the
resourceEditor from a sample app to a full blown layout editor that is a
standard part of PythonCard. Back in October we talked about a "possible
project idea" that would really show off PythonCard, require some
rudimentary document model and stress all parts of the framework. A layout
editor meets those criteria. If we support multiple windows and deal with
events correctly, then the layout editor can be written in PythonCard rather
than raw wxPython, so it should be simpler to write and maintain as the
framework is updated.

ka

[Pythoncard-users] FW: singletons and logging

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

Below is a slightly edited version of an email I received from Alex
Martelli; I didn't change any of his comments, I just deleted the ones not
relevant to the singleton and logging discussion.

Also, Patrick sent me this link to an article by Alex that you may want to
read.
http://www.aleax.it/5ep.html

As Patrick says: "More than you could ever possibly want to know about
singletons and borgs in
Python."

ka

-----Original Message-----
From: Alex Martelli [mailto:al...@al...]
Sent: Thursday, December 13, 2001 11:26 PM
To: Kevin Altis; al...@al...
Cc: ma...@he...
Subject: Re: FW: singletons and logging


On Friday 14 December 2001 07:12, Kevin Altis wrote:

> "singleton" log and config by just using module level variables and
> functions as you'll see in the list posts or cvs, but I left open the
> issue of whether to use a Borg or whether my module solution is good or
> not. Seems very pythonic to me, use of convention rather than
> enforcement.

I entirely agree that a module is a better solution than a class for many
needs that people are meeting with Singleton (as well as Borg being better
than Singleton for most of the rest).  Remember, however, that the main
Force being resolved by the Singleton DP (and the Borg non-pattern) is
*inheritability*: you want client-code to be able to customize the
functionality you're providing by subclassing and overriding, or at least
don't want to rule it out.  Singleton and Borg give you that, modules don't
(client-code may customize but only by a more involved process of copying
module pieces into another module and substituting others -0- often yecchy).

> -----Original Message-----
> From: Kevin Altis [mailto:al...@se...]
> Sent: Thursday, December 13, 2001 12:22 PM
> To: ma...@he...
> Cc: Alex Martelli [al...@ya...]
> Subject: singletons and logging
>
>
> I started two discussions yesterday on singletons and logging, both of
> which you are probably going to deal with in anygui land. The singleton
> is a Python language issue and it was actually Alex's cookbook entry that
> got me to post yesterday.
>
> http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/PythonCard
>
> Are you using singletons in anygui? Are you using debug or info logging

Inheritance is often an interesting potential and you may well not want to
rule it out.  Don't know about the specific case at hand.  Apart from
inheritance, modules and pseudo-modules (instances installed into
sys.modules) are fine.

Alex

RE: [Pythoncard-users] updated log and config modules, added util.py

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

> From: Andy Todd
>
> Whilst I'm thinking about this, do we want to restrict ourselves to just
> one log file per application? I'm trying to think of occasions when I've
> needed more than one, and haven't come up with any - yet. Just in case
> though, and if it isn't going to be too hard to support, perhaps we
> could allow for multiple concurrent log files.

Simplicity is probably the main reason for a single file. There is nothing
preventing you from having other application-specific files that you manage
yourself. Remember that the log file is mostly a programming and debug tool
and when an app is run normally log output won't be produced. We can add
different categories or change the parameter list a bit to make it more
flexible for the programmer. Supporting n number of files is probably just
adding needless complexity.

ka

Re: [Pythoncard-users] updated log and config modules, added util.py

[Andy T. <an...@ha...>]

Kevin Altis wrote:

 >> From: Andy Todd [mailto:an...@ha...]
 >>
 >>> I also changed the path returned by getLogFileName to always use
 >>>  the application directory (sys.argv[0]) to avoid log files
 >>> being
 >>>
 >> created in many
 >>
 >>> different directories while the app is running.
 >>>
 >>
 >> Err, could we make that a default which can be overrided? I would 
suggest
 >>  that if the specified log file name is a simple file name 'xxx.yyy'
 >>  you prepend the application directory, otherwise use whatever is
 >>  supplied (be it an absolute or relative path). I try and avoid writing
 >>  log files to my application directories.
 >>
 >
 > How about this?
 >
 > def getLogFileName( self ) : # KEA 2001-12-13 # return the
 > application path for the log file directory # unless the user
 > supplied filename contains a directory path =
 > os.path.split(self.getOption('logfile'))[0] if path == '': return
 > os.path.abspath( \ os.path.join( \ os.path.dirname(sys.argv[0]), \ 
self.getOption('logfile')))
 >

 > else: return os.path.abspath(self.getOption('logfile'))
 >
 > That's checked into cvs and appears to work. I tried these settings
 > in my pythoncard_user_config.py file:
 >
 > 'logfile':'c:\\temp\\pythoncard.log', 'logToStdout':0,
 >
 > ka
 >
 >


Looks good to me. Works on both *nix and Win32 when I tested it, with
absolute and relative paths too. I love os.path ;-)

Whilst I'm thinking about this, do we want to restrict ourselves to just 
one log file per application? I'm trying to think of occasions when I've 
needed more than one, and haven't come up with any - yet. Just in case 
though, and if it isn't going to be too hard to support, perhaps we 
could allow for multiple concurrent log files.

Just-thinking-out-loud-ly y'rs,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Another year older, still no wiser." - Me, on my birthday

RE: [Pythoncard-users] updated log and config modules, added util.py

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

> From: Andy Todd [mailto:an...@ha...]
> >
> > I also changed the path returned by getLogFileName to always use the
> > application directory (sys.argv[0]) to avoid log files being
> created in many
> > different directories while the app is running.
>
>
> Err, could we make that a default which can be overrided? I would
> suggest that if the specified log file name is a simple file name
> 'xxx.yyy' you prepend the application directory, otherwise use whatever
> is supplied (be it an absolute or relative path). I try and avoid
> writing log files to my application directories.

How about this?

        def getLogFileName( self ) :
            # KEA 2001-12-13
            # return the application path for the log file directory
            # unless the user supplied filename contains a directory
            path = os.path.split(self.getOption('logfile'))[0]
            if path == '':
                return os.path.abspath( \
                    os.path.join( \
                    os.path.dirname(sys.argv[0]), \
                    self.getOption('logfile')))
            else:
                return os.path.abspath(self.getOption('logfile'))

That's checked into cvs and appears to work. I tried these settings in my
pythoncard_user_config.py file:

'logfile':'c:\\temp\\pythoncard.log',
'logToStdout':0,

ka

Re: [Pythoncard-users] updated log and config modules, added util.py

[Andy T. <an...@ha...>]

Kevin Altis wrote:

> I moved readAndEvalFile() to util.py. Future generic functions and methods
> can go in that module.
> 
> I went ahead and changed log and config modules to use "global" module
> functions for
> the Log() and Configuration() classes. Now to use the logging functionality
> you just import log and then use one of the function below like
> 
>   log.info('hello log world')
> 
[snip definition of changes]

> 
> I also changed the path returned by getLogFileName to always use the
> application directory (sys.argv[0]) to avoid log files being created in many
> different directories while the app is running.


Err, could we make that a default which can be overrided? I would 
suggest that if the specified log file name is a simple file name 
'xxx.yyy' you prepend the application directory, otherwise use whatever 
is supplied (be it an absolute or relative path). I try and avoid 
writing log files to my application directories.

> 
> The cvs checkin is below so you can see which files were impacted. If any of
> these changes seem inherently wrong, we can always go back to the old method
> or try something else, but I like how this works.
> 
> ka
> ---
> 
[snip cvs check in messages]

> 

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Another year older, still no wiser." - Me, on my birthday

RE: [Pythoncard-users] logging to the console

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

Until we decide on something else, I went ahead and added a 'logToStdout'
config option. If logToStdout is 1 (true), then log messages (if enabled)
will go to stdout instead of a file. The default is 0 in
pythoncard_config.py, but you can update your pythoncard_user_config.py
file. I didn't add any methods to change the state once the app is started,
but if it is true and you use another debug window such as the shell, then
you can use the 'Redirect stdout to Shell' so that all log messages go to
the Shell window instead of the console. One of the reasons you might want
to do this is when testing a script with the .pyw extension where there is
no console window. For example

textEditor.pyw -s -l

I'll start using log now instead of print statements and see what issues I
run into.

My "hasty" solutions today are not how we have to do this stuff, so any and
all feedback or alternative solutions are welcome.

I didn't actually change the singleton implementation for Configuration or
Log today since the module references made the actual implementation
irrelevant.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Thursday, December 13, 2001 4:34 PM
> To: pythoncard-Users
> Subject: [Pythoncard-users] logging to the console
>
>
> Most of the time, I want to be able to have the log output just go to the
> console (sys.stdout). This should also take care of having
> logging output go
> to the shell if the "Redirect stdout to Shell" option is enabled.
> Yes I know
> Unix folks would probably just to a tail on the log file, but that isn't
> available for most Windows users.
>
> We could have "stdout" or "stderr" treated as a special filename
> for the log
> in which case output is sent to sys.stdout instead of some other
> file. Seems
> a bit unclean.
>
> Another possibility is to add an explicit flag to route log messages to
> stdout or stderr... This option would need to be added to the config
> options.
>
> Other suggestions?
>
> Remember that one of the goals is that I want to avoid peppering
> the source
> (especially samples) with print statements, but just use log instead and
> then the log statements can be left in the code without causing much
> overhead or outputting unwanted messages to a file or console if logging
> isn't enabled.

[Pythoncard-users] logging to the console

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

Most of the time, I want to be able to have the log output just go to the
console (sys.stdout). This should also take care of having logging output go
to the shell if the "Redirect stdout to Shell" option is enabled. Yes I know
Unix folks would probably just to a tail on the log file, but that isn't
available for most Windows users.

We could have "stdout" or "stderr" treated as a special filename for the log
in which case output is sent to sys.stdout instead of some other file. Seems
a bit unclean.

Another possibility is to add an explicit flag to route log messages to
stdout or stderr... This option would need to be added to the config
options.

Other suggestions?

Remember that one of the goals is that I want to avoid peppering the source
(especially samples) with print statements, but just use log instead and
then the log statements can be left in the code without causing much
overhead or outputting unwanted messages to a file or console if logging
isn't enabled.

ka

[Pythoncard-users] updated log and config modules, added util.py

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

I moved readAndEvalFile() to util.py. Future generic functions and methods
can go in that module.

I went ahead and changed log and config modules to use "global" module
functions for
the Log() and Configuration() classes. Now to use the logging functionality
you just import log and then use one of the function below like

  log.info('hello log world')

log.py looks like:

log = Log()
def enable(): log.enable()
def disable(): log.disable()
def enablelevels(levels): log.enablelevels(levels)
def disablelevels(levels): log.disablelevels(levels)
def error(*args): log.error(*args)
def warning(*args): log.warning(*args)
def debug(*args): log.debug(*args)
def info(*args): log.info(*args)

config.py looks like:

config = Configuration()
def getOption(name): return config.getOption(name)
def setOption(name, value): config.setOption(name, value)
def getLogFileName(): return config.getLogFileName()
def saveConfig(): config.saveConfig()

I also changed the path returned by getLogFileName to always use the
application directory (sys.argv[0]) to avoid log files being created in many
different directories while the app is running.

The cvs checkin is below so you can see which files were impacted. If any of
these changes seem inherently wrong, we can always go back to the old method
or try something else, but I like how this works.

ka
---

changed filename for configuration so that the log file is always
  placed in the application directory
added util.py which contains readAndEvalFile
updated the other modules and samples to use this new form
CVS: ----------------------------------------------------------------------
CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS: 	binding.py config.py debug.py event.py log.py model.py res.py
CVS: 	samples/addresses/addresses.py
CVS: 	samples/resourceEditor/resourceEditor.py
CVS: 	samples/searchexplorer/searchexplorer.py
CVS: 	samples/textRouter/textRouter.py samples/turtle/turtle.py
CVS: 	samples/worldclock/worldclock.py
CVS: Added Files:
CVS: 	util.py
CVS: ----------------------------------------------------------------------

RE: [Pythoncard-users] logging revisited

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

Looks good to me, for what it's worth.

---
Patrick K. O'Brien
Orbtech.com - Your Source For Python Development Services
Phone: 314-963-3206


> As a simple test, I added the following code to log.py below the class
> definitions, but before the unit tests.
>
> log = Log().getInstance()
> def info(*args): log.info(*args)
>
> Then in the worldclock.py sample, I added
> import log
> and commented out the other Log code to make sure there was no
> interference.
> The worldclock code changed from
>
>   self.log.info("updating image ", url)
> to
>   log.info("updating image ", url)
>
> This seems to work just fine. The module defines the single
> instance of the
> Log class and global functions (global to the module) are defined for each
> class method. The rest of the framework and any samples that want to use
> logging don't care about the implementation, the syntax is simple, and no
> capabilities are lost as far as I can tell except subclassing Log.
>
> I'm no Python language expert, so if I'm missing something, please clue me
> in.
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

RE: [Pythoncard-users] logging revisited

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

> From: Magnus Lie Hetland
> >
> > I still like the idea of just referencing functions in the log
> module and
> I
> > think I'll go ahead and try that out. Then you could just do:
> >
> > import log
> >
> > log.info(" interval is up...")
>
> +1
>
> > since info would be setup to do the right thing.

As a simple test, I added the following code to log.py below the class
definitions, but before the unit tests.

log = Log().getInstance()
def info(*args): log.info(*args)

Then in the worldclock.py sample, I added
import log
and commented out the other Log code to make sure there was no interference.
The worldclock code changed from

  self.log.info("updating image ", url)
to
  log.info("updating image ", url)

This seems to work just fine. The module defines the single instance of the
Log class and global functions (global to the module) are defined for each
class method. The rest of the framework and any samples that want to use
logging don't care about the implementation, the syntax is simple, and no
capabilities are lost as far as I can tell except subclassing Log.

I'm no Python language expert, so if I'm missing something, please clue me
in.

ka

RE: [Pythoncard-users] logging revisited

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

In a way, a module makes a nice class-like singleton object. So unless you
really have a need for subclassing, I don't have a problem with your
suggestion.

---
Patrick K. O'Brien
Orbtech.com - Your Source For Python Development Services
Phone: 314-963-3206


ka said:

> I still like the idea of just referencing functions in the log
> module and I
> think I'll go ahead and try that out. Then you could just do:
>
> import log
>
> log.info(" interval is up...")
>
> since info would be setup to do the right thing.

Re: [Pythoncard-users] logging revisited

[Magnus L. H. <ml...@id...>]

From: "Kevin Altis" <al...@se...>
[snip]

> If we use this code, then we definitely need to include it with the
> distribution. It is probably overkill for our needs, but I'll try and take
a
> look at it in the next few days.
>
> I still like the idea of just referencing functions in the log module and
I
> think I'll go ahead and try that out. Then you could just do:
>
> import log
>
> log.info(" interval is up...")

+1

> since info would be setup to do the right thing.
>
> ka

--
Magnus Lie Hetland                           The Anygui Project
http://hetland.org                           http://www.anygui.org

RE: [Pythoncard-users] standardizing our use of singletons

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

> Standardizing the way we implement Singletons sounds like a good idea.
> I prefer to stay with traditional implementations of the GOF Singleton
> pattern.  The idea is not about sharing state, i.e. Borg, but providing
> a global access point to a single instance of a class.  The class is
> responsible for creation of instances, and is responsible for managing
> some resource ( log file, etc. ) .  For example, there should be one
> "log" in the system.  That log may write to one or many log files, or
> sockets, etc., and that can all be configured at runtime.  The user only
> needs to know about a single "log" instance.

But the effect of the Borg pattern is the same since all the instances share
the same state there is only one effective log, or at least that is how it
is described.

> Singleton is less brittle than say, defining module level functions in
> log.py , like log.info, log.warning, etc., even if those functions just
> call a single instance of the Log class.

I guess the question is whether we are likely to subclass any of the
singleton classes? That seems unlikely with config or log.

> > On a related note, the time has probably come for a generic util.py or
> > misc.py module where we place our generic helper classes and
> functions used
> > by other modules. I've already run into one or two import
> problems because
> > of the readAndEvalFile function in res.py which is a generic
> helper function
> > which needs to be taken out of res.py.
>
> That sounds good.

Okay, so do we use the dreaded generic util.py? My requirement for this
module is that it is standalone and won't import other modules in the
framework, causing a loop like res importing util, util importing res.

ka

RE: [Pythoncard-users] logging revisited

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

> > The worldclock.py sample syntax is cleaner, but that is because
> it keeps a
> > reference to the instance:
> >
> >         # Enable logging
> >         self.log = Log.getInstance()
> >         # self.log.enable()
> >         # Normally we enable only ERROR and WARNING messages
> >         self.log.enableLevels( [ Log.ERROR, Log.WARNING, Log.DEBUG,
> > Log.INFO ] )
> >         ...
> >         self.log.info( " interval is up..." )
>
>
> This is a pretty clean way of using log.  If we move to a logging
> framework that allows categories, like log4py, then you could do this:
>
>      self.log = Log.createCategory( "WorldClock" )
>
> Then use it:
>
>      self.log.info( "interval is up..." )
>
> And get output something like this:
>
>      WorldClock | INFO | interval is

I like the idea of being more specific, and it could probably be done by
passing in some more information such as the __file__ and self and other
variables if we wanted to be able to identify the class and instance where
the error occurred, etc.

> > That won't work for log statements we want to scatter throughout the
> > framework. Remember that the logging level and whether a log file is
> > generated can be set, so the log statements shouldn't burden normal
> > execution of an application or produce any output unless requested.
>
>
> I'm missing the point about why this won't work for log statements
> scattered throughout the framework.  The log statements won't do
> anything if logging is disabled.

Sorry, I'm referring to just the self.log as a way of hiding the longer
  log.Log.getInstance().info( " interval is up..." )

The shorthand self.log won't work because that assumes you have a reference
already.

> Using log4py would give us the added advantage of being able to create
> categories at the module ( "Resource" ) and object ( "Widget",
> "EventQueue" ) level, so the output could be much more informative.

Okay, we need to experiment and get the right trade-off between informative
and too verbose. I'm mostly interested in this for debugging and unit test
purposes. If I can start using a simple log statement in place of a print
statement and not have to worry about slowing down the code too much that
will be very helpful. I've gotten out of the habit of redirecting the output
to the shell, but I want to start doing that as well while I'm debugging.

> > Does anyone have suggestions or feature requests for our
> logging classes?
> > Are there any "standard" Python logging solutions I'm
> overlooking? I found
> > log4p (based on log4j at SF
> > http://sourceforge.net/projects/log4p/
> > http://log4p.sourceforge.net/
> > but no files have been released yet.
>
>
> Check out http://www.its4you.at/log4py.php
>
> The code is hosted on sourceforge.

If we use this code, then we definitely need to include it with the
distribution. It is probably overkill for our needs, but I'll try and take a
look at it in the next few days.

I still like the idea of just referencing functions in the log module and I
think I'll go ahead and try that out. Then you could just do:

import log

log.info(" interval is up...")

since info would be setup to do the right thing.

ka

Re: [Pythoncard-users] logging revisited

[Rowland S. <ro...@we...>]

Kevin Altis wrote:

> I brought up the singleton issue because I decided I wanted to start using
> logging on a more regular basis rather than adding and then
> removing/commenting print statements all over the place, which is my typical
> messy solution. I started to look at the Log class which I hadn't used in a
> while and decided the log.Log.getInstance() syntax was a bit awkward. Here's
> an example from some of Jeff's code:
> 
>         log.Log.getInstance().warning("WidgetLoader.installEventBindings: "
> +
>                                       "no event bindings at all: " +
>                                       moduleName)


> The worldclock.py sample syntax is cleaner, but that is because it keeps a
> reference to the instance:
> 
>         # Enable logging
>         self.log = Log.getInstance()
>         # self.log.enable()
>         # Normally we enable only ERROR and WARNING messages
>         self.log.enableLevels( [ Log.ERROR, Log.WARNING, Log.DEBUG,
> Log.INFO ] )
>         ...
>         self.log.info( " interval is up..." )


This is a pretty clean way of using log.  If we move to a logging 
framework that allows categories, like log4py, then you could do this:

     self.log = Log.createCategory( "WorldClock" )

Then use it:

     self.log.info( "interval is up..." )

And get output something like this:

     WorldClock | INFO | interval is


> 
> That won't work for log statements we want to scatter throughout the
> framework. Remember that the logging level and whether a log file is
> generated can be set, so the log statements shouldn't burden normal
> execution of an application or produce any output unless requested.


I'm missing the point about why this won't work for log statements 
scattered throughout the framework.  The log statements won't do 
anything if logging is disabled.

Using log4py would give us the added advantage of being able to create 
categories at the module ( "Resource" ) and object ( "Widget", 
"EventQueue" ) level, so the output could be much more informative.


> This seems like a good time to revisit the logging issue as we standardize
> our singleton class. There should be much more diagnostic output in the
> framework, but I would like to pick a longer-term solution before starting
> to add log statements throughout the code.
> 
> Could we just have a variable in the module file such as:
> 
> log = Log.getInstance()
> and then use
> from PythonCardPrototype.log import log
> That seems like it should work.
> 
> Does anyone have suggestions or feature requests for our logging classes?
> Are there any "standard" Python logging solutions I'm overlooking? I found
> log4p (based on log4j at SF
> http://sourceforge.net/projects/log4p/
> http://log4p.sourceforge.net/
> but no files have been released yet.


Check out http://www.its4you.at/log4py.php

The code is hosted on sourceforge.


> 
> ka
> 
> 
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 
> 
> 



-- 
Talk to ya,
Rowland

"The whole problem with the world is
that fools and fanatics are always so
certain of themselves, and wiser people
so full of doubts."

-- Bertrand Russell,
    quoted in the book
    A Word a Day

Re: [Pythoncard-users] standardizing our use of singletons

[Rowland S. <ro...@we...>]

Kevin Altis wrote:

> There are a number of classes in the framework implemented as singletons and
> they are done in a variety of different ways. If you don't already know what
> a singleton is and you follow the links below, you'll find out what they
> are.
> 
> Configuration (config.py), ObjectLookup and EventQueue (event.py), and Log
> (log.py) are all supposed to be singletons. There are probably other single
> classes in the framework, but a quick search of the yielded the ones above.
> 
> There is a Python Cookbook section dealing with singletons here:
> 
> http://aspn.activestate.com/ASPN/search?query=singleton&section=PYTHONCKBK&type=Subsection
> 
> I have to admit that the Borg recipe is appealing
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66531
> 
> I think it would be beneficial to standardize on one pattern for
> "singletons" and update the framework. Any preferences or suggestions?


Standardizing the way we implement Singletons sounds like a good idea.
I prefer to stay with traditional implementations of the GOF Singleton 
pattern.  The idea is not about sharing state, i.e. Borg, but providing 
a global access point to a single instance of a class.  The class is 
responsible for creation of instances, and is responsible for managing 
some resource ( log file, etc. ) .  For example, there should be one 
"log" in the system.  That log may write to one or many log files, or 
sockets, etc., and that can all be configured at runtime.  The user only 
needs to know about a single "log" instance.

Singleton is less brittle than say, defining module level functions in 
log.py , like log.info, log.warning, etc., even if those functions just 
call a single instance of the Log class.


> On a related note, the time has probably come for a generic util.py or
> misc.py module where we place our generic helper classes and functions used
> by other modules. I've already run into one or two import problems because
> of the readAndEvalFile function in res.py which is a generic helper function
> which needs to be taken out of res.py.

That sounds good.


> ka
> 
> 
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 
> 
> 



-- 
Talk to ya,
Rowland

"The whole problem with the world is
that fools and fanatics are always so
certain of themselves, and wiser people
so full of doubts."

-- Bertrand Russell,
    quoted in the book
    A Word a Day

[Pythoncard-users] logging revisited

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

I brought up the singleton issue because I decided I wanted to start using
logging on a more regular basis rather than adding and then
removing/commenting print statements all over the place, which is my typical
messy solution. I started to look at the Log class which I hadn't used in a
while and decided the log.Log.getInstance() syntax was a bit awkward. Here's
an example from some of Jeff's code:

        log.Log.getInstance().warning("WidgetLoader.installEventBindings: "
+
                                      "no event bindings at all: " +
                                      moduleName)

The worldclock.py sample syntax is cleaner, but that is because it keeps a
reference to the instance:

        # Enable logging
        self.log = Log.getInstance()
        # self.log.enable()
        # Normally we enable only ERROR and WARNING messages
        self.log.enableLevels( [ Log.ERROR, Log.WARNING, Log.DEBUG,
Log.INFO ] )
        ...
        self.log.info( " interval is up..." )


That won't work for log statements we want to scatter throughout the
framework. Remember that the logging level and whether a log file is
generated can be set, so the log statements shouldn't burden normal
execution of an application or produce any output unless requested.

This seems like a good time to revisit the logging issue as we standardize
our singleton class. There should be much more diagnostic output in the
framework, but I would like to pick a longer-term solution before starting
to add log statements throughout the code.

Could we just have a variable in the module file such as:

log = Log.getInstance()
and then use
from PythonCardPrototype.log import log
That seems like it should work.

Does anyone have suggestions or feature requests for our logging classes?
Are there any "standard" Python logging solutions I'm overlooking? I found
log4p (based on log4j at SF
http://sourceforge.net/projects/log4p/
http://log4p.sourceforge.net/
but no files have been released yet.

ka

[Pythoncard-users] standardizing our use of singletons

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

There are a number of classes in the framework implemented as singletons and
they are done in a variety of different ways. If you don't already know what
a singleton is and you follow the links below, you'll find out what they
are.

Configuration (config.py), ObjectLookup and EventQueue (event.py), and Log
(log.py) are all supposed to be singletons. There are probably other single
classes in the framework, but a quick search of the yielded the ones above.

There is a Python Cookbook section dealing with singletons here:

http://aspn.activestate.com/ASPN/search?query=singleton&section=PYTHONCKBK&t
ype=Subsection

I have to admit that the Borg recipe is appealing
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66531

I think it would be beneficial to standardize on one pattern for
"singletons" and update the framework. Any preferences or suggestions?

On a related note, the time has probably come for a generic util.py or
misc.py module where we place our generic helper classes and functions used
by other modules. I've already run into one or two import problems because
of the readAndEvalFile function in res.py which is a generic helper function
which needs to be taken out of res.py.

ka

[Pythoncard-users] updated findfiles sample

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

I changed the load and save file methods in findfiles to use binary reads
and writes to avoid any cross-platform issues when sharing .grep files. I
removed the trailing tab when saving a .grep file (that was a bug). I
updated the code so that it automatically saves the last search parameters
used in a findfiles.grep file. If 'findfiles.grep' is available when the app
starts, then it is automatically loaded, so you can quickly change a
parameter and do another search without having to go through a File->Open
operation.

ka

RE: [Pythoncard-users] major cvs update - modular widgets

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

Just to clarify, these changes don't give us self-describing components
(widgets), those will come later, but this is a start. The resource
descriptions for each widget class are the same as the ones that used to be
in spec.py, but now they are done with classes defined in each widget
module. It is simpler to modify an individual component, as well as subclass
existing components and create new ones that are app-specific or available
to all PythonCard apps. Once a new widget/component is defined, it can be
used in a resource file just like the standard ones: Button, TextField, etc.

It should also be possible to create some composite components, but I
haven't done any experiments in this area yet.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Tuesday, December 11, 2001 4:03 PM
> To: pythoncard-Users
> Subject: [Pythoncard-users] major cvs update - modular widgets
>
>
> I finally got everything working correctly after some major modifications.
> Of course, there are probably still bugs, but I think I managed the first
> step of modularizing widgets.py without breaking all the samples. This
> version doesn't support a widgets/components path, it always
> expects to find
> components in the new components directory, but it should be
> relatively easy
> to add support for additional directories. I expect to refactor
> the code to
> be cleaner, since this version still uses spec.py for all the non-widget
> classes like Stack and Background.
>
> Basically, I needed to check what I have right now into cvs, so Rowland,
> Jeff, and anyone else that wants to help with the modularization and
> components transition can start providing input. Adding a new
> widget should
> be as simple as creating a new module with the spec, class, and event
> bindings and dropping it into the components directory.
>
> I also took this opportunity to bump up the requirements to wxPython 2.3.2
> and I cleaned up all the
>   from wxPython.wx import *
> import statements, which impacted almost every framework file and many of
> the samples. Now it is easy to know whether something comes from wxPython,
> because it will always have a "wx." in front of a class, method, or
> constant.
>
> The list of changes is below.
>
> ka
> ---
> *** wxPython 2.3.2 or later is now required to use PythonCard ***
> added assert wxc.__version__ >= "2.3.2" to model.py
> changed wxPython imports from
>   from wxPython.wx import *
>   to the more explicit
>   from wxPython import wx
>   added missing imports such as 'import types' where needed
> replaced occurances of wx.true and wx.false with 1 and 0
> added a components directory
> merged wxPython_binding.py into binding.py and moved widget-specific
>   bindings to individual module files
> moved spec.py descriptions for each widget to its respective widget
>   module
> split widget.py so each widget is in its own file in the components
>   directory
>   all widgets (components) are now self-contained modules in the
>   components directory. each module includes the spec, event bindings,
>   and attribute descriptions (formerly in spec.py) in addition to the
>   widget class. when the module is imported it "registers" itself, so
>   that the class is available for applications.
> added drawPointList and drawLineList (2.3.2 feature) to the
>   BitmapCanvas widget, switched to drawPointList in hopalong sample
>   for a roughly 4x speed improvement
> updated the setup.py script for minimal.py and provided some basic
>   instructions in the readme.txt. It is necessary to uncomment the
>   import in minimal.py prior to using py2exe due to how the dynamic
>   imports are done for components
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

[Pythoncard-users] major cvs update - modular widgets

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

I finally got everything working correctly after some major modifications.
Of course, there are probably still bugs, but I think I managed the first
step of modularizing widgets.py without breaking all the samples. This
version doesn't support a widgets/components path, it always expects to find
components in the new components directory, but it should be relatively easy
to add support for additional directories. I expect to refactor the code to
be cleaner, since this version still uses spec.py for all the non-widget
classes like Stack and Background.

Basically, I needed to check what I have right now into cvs, so Rowland,
Jeff, and anyone else that wants to help with the modularization and
components transition can start providing input. Adding a new widget should
be as simple as creating a new module with the spec, class, and event
bindings and dropping it into the components directory.

I also took this opportunity to bump up the requirements to wxPython 2.3.2
and I cleaned up all the
  from wxPython.wx import *
import statements, which impacted almost every framework file and many of
the samples. Now it is easy to know whether something comes from wxPython,
because it will always have a "wx." in front of a class, method, or
constant.

The list of changes is below.

ka
---
*** wxPython 2.3.2 or later is now required to use PythonCard ***
added assert wxc.__version__ >= "2.3.2" to model.py
changed wxPython imports from
  from wxPython.wx import *
  to the more explicit
  from wxPython import wx
  added missing imports such as 'import types' where needed
replaced occurances of wx.true and wx.false with 1 and 0
added a components directory
merged wxPython_binding.py into binding.py and moved widget-specific
  bindings to individual module files
moved spec.py descriptions for each widget to its respective widget
  module
split widget.py so each widget is in its own file in the components
  directory
  all widgets (components) are now self-contained modules in the
  components directory. each module includes the spec, event bindings,
  and attribute descriptions (formerly in spec.py) in addition to the
  widget class. when the module is imported it "registers" itself, so
  that the class is available for applications.
added drawPointList and drawLineList (2.3.2 feature) to the
  BitmapCanvas widget, switched to drawPointList in hopalong sample
  for a roughly 4x speed improvement
updated the setup.py script for minimal.py and provided some basic
  instructions in the readme.txt. It is necessary to uncomment the
  import in minimal.py prior to using py2exe due to how the dynamic
  imports are done for components

[Pythoncard-users] FW: [wxPython] ANN: wxPython 2.3.2

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

Robin released wxPython 2.3.2 today, so I'm forwarding the announcement for
those of you that might not see it on another forum. The next release of
PythonCard will require wxPython 2.3.2.

ka
---

> wxPython 2.3.2 has been released as is available for download from
> http://wxPython.org/download.org or the wxPython project pages at

Sorry, that should be http://wxPython.org/download.php.

BTW, there are also Win32 and RPM binaries available for Python 2.2!

-----Original Message-----
From: wxp...@li...
[mailto:wxp...@li...]On Behalf Of Robin Dunn
Sent: Tuesday, December 11, 2001 12:59 PM
To: wxPython-users; wx-...@li...;
pyt...@py...; pyt...@py...
Subject: [wxPython] ANN: wxPython 2.3.2


wxPython 2.3.2 has been released as is available for download from
http://wxPython.org/download.org or the wxPython project pages at
SourceForge.  wxPython is a popular GUI toolkit for the Python language that
is usable on Windows and Linux/Unix systems with the GTK+ toolkit, and a Mac
OS X version is in progress.

Some of the changes for the 2.3.2 release are:

Added EVT_HELP, EVT_HELP_RANGE, EVT_DETAILED_HELP, EVT_DETAILED_HELP_RANGE,
EVT_CONTEXT_MENU, wxHelpEvent, wxContextMenuEvent, wxContextHelp,
wxContextHelpButton, wxTipWindow, and a demo to show them in action.

Deprecated PyShell and PyShellWindow, added a snapshot of PyCrust (see
http://sourceforge.net/projects/pycrust/. )

Added the new virtual list capabilities to wxListCtrl.

Added a wxSTC style editor from Riaan Booysen to the sample apps.

Added XRCed to the wxPython Tools directory, contributed by Roman Rolinsky.

Added a new "constructor" to most of the window classes that calls the
default C++ contructor, (the one with no parameters) and also added the
coresponding Create(...) method.  This allows you to do a 2-step creation of
windows which is sometimes required for doing things such as setting
extended style flags before the window is created, or for passing the object
to the XRC resource system to be created from the resource.  The name of the
new "constructor" is the original name of the class with a "Pre" in it.  For
example, wxPreWindow, wxPreFrame, etc.

Updated to version 1.40 of Scintilla and updated wxStyledTextCtrl
accordingly.  While doing this update I dropped the wxLB_SORT style from the
wxListBox created for the AutoComplete functionality.  This means that you
will have to sort the keyword lists yourself, but you are free to do case
sensitive or case insensitive sorts and set the wxSTC flag accordingly.

Updated wxColumnSorterMixin to also be able to place sort icons on the
column headers, and updated the wxListCtrl demo to show it off by using
wxColumnSorterMixin.
Added wxGenBitmapTextButton, TablePrint, etc. contribs from Lorne White.

Added wxNativeFontInfo and wxFontMapper.

Added pySketch to the samples.

Significantly changed how the Python interpreter lock and thread state are
managed, which should fix the problem of running on a multi-processor
machine.

Added wxPyLog so log targets can be created in Python to handle log messages
however is wished.  See demo/Main.py for an example.

Added wxFindReplaceDialog.

The second phase of OOR is implemented (for wxEvtHandler and derived classes
at least.)  This means that functions and methods that return an object
derived from wxEvtHandler that was originally created in Python, will return
the original Python object (if it still exists) instead of letting SWIG wrap
a new shadow object around the original C++ pointer.

Added some optimization methods to wxDC: GetBoundingBox, DrawLineList,
DrawPointList.

Added a set of sophisticated Error Dialogs from Chris Fama.

Added wxRightTextCtrl from Josu Oyanguren to wxPython.lib for aligning text
in a wxTextCtrl to the right side.

Added wxURLDataObject and and example showing drag and drop of URLs to and
from web browsers.  It's still not 100% bullet-proof for all types of
browsers, but it works for the majority of cases with the popular browsers
on Windows.  On wxGTK it seems that only Netscape 4.x works, if anybody has
any suggestions about this please bring it up on the wx-dev list.

Added wxStopWatch.

Added wxMimeTypesManager and wxFileType.

Passing None for the handler parameter to one of the EVT_** functions will
now Disconnect the event.

Added wxPopupWindow and wxPopupTransientWindow.

Added wxFileHistory.

Added wxDynamicSashWindow, which allows you to endlessly split widnows by
dragging a little tab next to the scrollbars.  Added a demo to show this and
also the ability of multiple wxStyledStectCtrls to share the same document.

Added wxEditableListBox gizmo.

Updated wxEditor with lots of enhancements from Steve Howell and Adam Feuer.

Added the "SplitTree gizmos" which are a collection of classes that were
designed to operate together and provide a tree control with additional
columns for each item.  The classes are wxRemotelyScrolledTreeCtrl,
wxTreeCompanionWindow, wxThinSplitterWindow, and wxSplitterScrolledWindow,
some of which may also be useful by themselves.

Added wxDllWidget from Vaclav Slavik which allows wx widgets derived from
wxWindow to be loaded from a C++ .dll (or .so) and be used in a wxPython
program, without the widget having to be SWIGged first.  The visible API of
the widget is limited to wxWindow methods plus a SendCommand method, but it
is still quite powerful.  See wxPython/contrib/dllwidget and
wxPython/demo/dllwidget for more details.


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