pythoncard-users Mailing List for PythonCard (Page 202)

The resourceEditor now saves files. I also hacked it up so that it gets
pretty aggressive about not saving default values, but it might be overly
aggressive and I still can't make it deal with 'size' correctly. So if you
need a -1 or -2 value for any size attribute you're going to have to hand
edit the .rsrc.py files. Remember when editing and saving to always work on
a copy, no telling what bugs might be lurking, but it seems to work
reasonably well. I copied the samples directory and then opened and saved
every .rsrc.py and they all ran fine afterwards.
There is a template.rsrc.py file that is loaded by default so even if you
start the resourceEditor and just start adding widgets, it will save a valid
.rsrc.py file. You can still preview the output with the View Attributes
menu item.
There is no editing of stack, menu, or background attributes, that is
probably going to have to wait until we have some generalized dialog
support. That means you still need to hand edit the .rsrc.py files to
add/change menus and other crucial attributes.
I haven't switched font formats yet, but the Property Editor now correctly
displays the current font attribute for a widget and test_widgets.py allows
you to set the font for all widgets. The font dialog now accepts a Font as
an input parameter and if that is not equal to None, then that is the
default font you start out with in the dialog.
The FileDialog now accepts a number of extra parameters for saving...
FILE_OPEN # This is an open dialog.
FILE_SAVE # This is a save dialog.
FILE_HIDE_READONLY # Hide read-only files.
# For save dialog only: prompt for a confirmation if a file will be
overwritten.
FILE_OVERWRITE_PROMPT
# For open dialog only: allows selecting multiple files.
FILE_MULTIPLE
# Change the current working directory to the directory where the file(s)
chosen by the user are.
FILE_CHANGE_DIR
All old samples work without change, but if you look at the new Save As...
in the resourceEditor you'll see the new options at work.
Due to the reliance of what is in cvs on the new PyCrust, I'm going to wait
to do a release until Patrick puts out PyCrust 0.6.
ka

I can't take it anymore. I'm dying to find a way to become involved.
This afternoon I began working on documenting all the widget attributes and
event triggers. My initial plan was to code a single widget and show in
very simple terms what the code would look like if you wanted to handle
events triggered by that widget.
While attempting this, I was still pretty unfamiliar with how to build
python cards. I spent 15 minutes feeling my way around the applications,
trying things out within PyCrust.
What happened next I didn't expect. Within those first 15 minutes I reached
that historically elusive "aha" moment. I was stunned at how intuitive
programming for pythoncard was. The Message Watcher window along with the
Resource Editor get the credit for making it so obvious how to code cards.
So now I have no desire to document every widget event and attribute. Its
just too obvious how everything is put together.
So here is my question, are there any special requests of the developers.
Can you think of anything that would be nice to have any ol' average joe do?
Documentation, run tests, make graphics, order pizza, mow your lawn? feed
the cat? Anything?!?!
-Jeff Griffith
Just to make it handy, the old link to the assigned tasks
http://groups.yahoo.com/group/pythoncard/message/276

> > Are you saying that you want the style to be a list of one or
> more values
> > 'normal', 'italic', 'oblique', 'bold', 'underline'?
>
> Mostly I'd prefer options to be separate rather than trying to mix them
> together in some sort of style attribute which doesn't correspond to any
> underlying API. Trying to produce a new font description model that is
> different but less capable than any of wxWindows, Win32, or CSS
> looks like a
> backwards step to me.
Okay, but I still need to know what you're proposing, so I can implement it.
fontFamily: CSS-like
fontWeight: normal or bold
fontStyle: normal or italic (or oblique)
fontUnderline: 1 or 0
I still don't know whether underline works on *nix or just Windows.
ka

Kevin Altis:
> So we want to do a separate 'weight': 'normal', 'bold', 'lighter'?
'lighter'
> (wxLIGHT in wxPython) doesn't ever seem to do anything. 'oblique'
(wxSLANT)
> appears to be the same as 'italic' (wxITALIC).
 Just tried to provoke both the Win32 API and Internet Explorer into doing
something with a light font using a weight of 100 which is the lightest
possible but there is no effect so its unlikely that wxWindows can do
anything with it either. If it never works then there is probably not much
point in supporting it ;) The reason I wanted to be able to choose lighter
weights is for very high resolution modes where you mostly have two pixel
wide characters but would like to choose thinner characters sometimes.
> CSS doesn't support underline as a style, underline is a a text
decoration.
>
> "The text-decoration property allows text to be decorated through one of
> five properties: underline, overline, line-through, blink, or the default,
> none."
>
> Are you saying that you want the style to be a list of one or more values
> 'normal', 'italic', 'oblique', 'bold', 'underline'?
 Mostly I'd prefer options to be separate rather than trying to mix them
together in some sort of style attribute which doesn't correspond to any
underlying API. Trying to produce a new font description model that is
different but less capable than any of wxWindows, Win32, or CSS looks like a
backwards step to me.
> Is Small Caps possible in wxPython/wxWindows? That's font-variant in CSS
> terms.
 Its not a Win32 choice so its unlikely wxWindows will try to handle it.
Sometimes small-caps fonts are available so this can be done by choosing a
family name of such a font.
 Neil

> > I chose to combine and hide some of the wxPython font settings.
> A Font is
> > described by its optional attributes:
> > family: 'serif', 'sansSerif', 'monospace', 'default'
> > faceName: an actual font name from the system (Arial, Courier New...)
>
> CSS combines these as font-family with the particular names 'serif',
> 'sans-serif', 'cursive', 'fantasy', and 'monospace' being mapped
> by the user
> agent to available real fonts.
wxWindows/wxPython
wxDEFAULT Chooses a default font.
wxDECORATIVE A decorative font.
wxROMAN A formal, serif font.
wxSCRIPT A handwriting font.
wxSWISS A sans-serif font.
wxMODERN A fixed pitch font.
'cursive' should map to wxSCRIPT and 'fantasy' should map to wxDECORATIVE
but neither of these families seems to work for me. I don't know if I'm
doing something wrong or if its a bug in wxPython or those families just
aren't supported right now?!
> > size: a number representing point size (8, 9, 10, etc.)
> > style: 'regular', 'bold', 'italic', 'boldItalic'
>
> Combining these makes no sense to me. I know the Microsoft font dialog
> does this but why have bold and italic combined and underline
> separate? (the
> reason the dialog does it is that the normal, bold, italics, and
> bolditalics
> are separate fonts often in separate files and you'll occasionally see
> demibold and oblique in that list). A richer weight parameter is more
> general and maps to CSS as does style being for italic or oblique.
So we want to do a separate 'weight': 'normal', 'bold', 'lighter'? 'lighter'
(wxLIGHT in wxPython) doesn't ever seem to do anything. 'oblique' (wxSLANT)
appears to be the same as 'italic' (wxITALIC).
CSS doesn't support underline as a style, underline is a a text decoration.
"The text-decoration property allows text to be decorated through one of
five properties: underline, overline, line-through, blink, or the default,
none."
Are you saying that you want the style to be a list of one or more values
'normal', 'italic', 'oblique', 'bold', 'underline'?
It seems like it would make the most sense to have 'family' and 'style' be
Python lists to simplify adding, doing slices, and checking for matches.
Guess I just need to ponder this some more.
Is Small Caps possible in wxPython/wxWindows? That's font-variant in CSS
terms.
ka

Fresh out of the oven...
Thanks to PyCrust 0.6 (not released yet, but in cvs), PythonCard now has a
Namespace Viewer (PyFilling). This will be part of the next release, but is
in cvs now. If you're getting PythonCardPrototype from cvs, you'll need to
get PyCrust from cvs as well in order to run.
The Namespace Viewer can be invoked by using '-n' on the command-line or it
can be enabled in 'pythoncard.config.py' or 'pythoncard.user.config.py'. The
new lines in 'pythoncard.config.py' are:
 'showNamespace':0,
 'namespacePosition':(0, 0),
 'namespaceSize':(600, 300),
 'namespaceVisible':1,
It is currently set to display the local shell namespace rather than
__main__. We can enhance the options later depending on what people want.
A big thanks to Patrick for making an excellent viewer!
I'll try and get fonts into shape and do a daily release tonight, but no
promises.
ka

I moved the Font class out of widget.py to its own module font.py. I put
Neil's CSS parser there as well. I'll start making the other changes to
merge 'faceName' and 'family' into a 'font-family' or 'fontFamily'
attribute. I think for consistency in naming I would prefer 'fontFamily' and
'sansSerif' if nobody objects.
ka

Kevin Altis:
> Are we trying to be CSS-like or have people be able to copy an existing
> CSS font-family description and use it in PythonCard?
 I don't mind too much. I just want to be able to specify a font list in
a reasonable way without writing a lot of UI.
> The original
> { font-family: "New Century Schoolbook", Times, serif }
 Damn. I wrote my code from a book that got it wrong, not mentioning the
comma delimiter. Attached is a fixed version. It looks to be compliant with
http://www.w3.org/TR/REC-CSS1 although its probably not as forgiving as real
world browsers are.
> what I tested...
>
> Test('"New Century Schoolbook", Times, serif')
>
> produces
>
> <"New Century Schoolboo", Times, serif>
> ['New Century Schoolboo', ',', 'Times,', 'serif']
 I doubt that ;) The 'k' shouldn't disappear between being an argument and
being printed the first time.
 Neil

Are we trying to be CSS-like or have people be able to copy an existing CSS
font-family description and use it in PythonCard?
The original
{ font-family: "New Century Schoolbook", Times, serif }
what I tested...
Test('"New Century Schoolbook", Times, serif')
produces
<"New Century Schoolboo", Times, serif>
['New Century Schoolboo', ',', 'Times,', 'serif']
My brain is too tired right now to grok what I need to do in the method that
sets the font facename and/or family, so I'll look at this again tomorrow. I
know I have to iterate through the list, but...
ka
> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Neil
> Hodgson
> Sent: Tuesday, August 28, 2001 10:31 PM
> To: pyt...@li...
> Subject: Re: [Pythoncard-users] cascading style sheets (CSS) guide
>
>
> Kevin:
>
> > BTW, I am not going to write the parser to handle CSS
> descriptions for the
> > prototype. Somebody else is going to have to tackle that. If that means
> that
> > we are stuck with a variation of my initial font description
> solution for
> a
> > while, then so be it.
>
> Here is a parser for family lists which is the only extra
> functionality I
> see as needed.
>
> Neil
>

Kevin:
> BTW, I am not going to write the parser to handle CSS descriptions for the
> prototype. Somebody else is going to have to tackle that. If that means
that
> we are stuck with a variation of my initial font description solution for
a
> while, then so be it.
 Here is a parser for family lists which is the only extra functionality I
see as needed.
 Neil

From: "Kevin Altis" <al...@se...>
> If you ever have to look at XML, then something is
> wrong with your solution :)
I don't agree... I find XML almost as excellent for
document authoring as LaTeX :)
> ka
--
 Magnus Lie Hetland http://www.hetland.org
 "Reality is that which, when you stop believing in
 it, doesn't go away." -- Philip K. Dick

Kevin Altis wrote:
>> Why do you think it has to be written in C? The format is quite simple
>>and speed is unlikely to be an issue. Requiring more extensions to be
>>bundled with PythonCard to make it work will make it more trouble
>>to set up
>>correctly.
>>
> 
> I suggested to Dave Cole that he should try and get his stuff bundled into
> the Python Standard Libraries. I would prefer a pure Python solution for now
> if we have to distribute it with PythonCard.
> 
> 
>> Is CSV import / export something that needs to be solved now? Is it
>>required by something else?
>>
> 
> This issue came up because of the addresses and dbBrowser samples. A CSV
> module would allow simple import/export for any PythonCard app. It isn't
> critical right now, so anyone that wants to can pursue it and just add the
> module to cvs when it is ready and notify the list. I'm not actively
> pursuing it myself except via email.
> 
> ka
> 
I'll put my hand up for this one. I am planning to put CSV support into 
dbBrowser this week. My purpose is twofold, to make it more meaningful 
to prototype users who don't have any databases installed and to force 
me to modularise the code so that plugging in more back ends is a lot 
easier.
I was going to try try the sample that Magnus provided first and then 
optionally use Dave Cole's module as a bit of a compare and contrast. 
I'll let you all know how I get on.
Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Shave my poodle!"

> > This issue came up because of the addresses and dbBrowser samples. A CSV
> > module would allow simple import/export for any PythonCard app. It isn't
> > critical right now, so anyone that wants to can pursue it and
> just add the
> > module to cvs when it is ready and notify the list. I'm not actively
> > pursuing it myself except via email.
>
> Why not use XML? It's much more powerful, and there's _lots_ of support
> for it in the standard libraries... You can even use the xmlrpclib for
> simple serialisation:
The whole point of CSV is to deal with other programs that don't support
some better format. I think the initial idea was to import Outlook Express
or Netscape contacts, which meant CSV. XML doesn't help you there.
Tab separated or some other formats are okay as are fixed field formats as
long as you don't have multiline data (typically the Notes field), it just
depends on what is on the other end. Obviously, if you have some newer
program on the other end that can talk XML that is probably the way to go.
I don't even mind switching to XML for the resource format for PythonCard,
but only after I know I'll never have to hand edit the files and that
whatever generating them always outputs valid XML, so we won't have
validation problems. If you ever have to look at XML, then something is
wrong with your solution :)
ka

From: "Kevin Altis" <al...@se...>
> > Is CSV import / export something that needs to be solved now? Is it
> > required by something else?
>
> This issue came up because of the addresses and dbBrowser samples. A CSV
> module would allow simple import/export for any PythonCard app. It isn't
> critical right now, so anyone that wants to can pursue it and just add the
> module to cvs when it is ready and notify the list. I'm not actively
> pursuing it myself except via email.
Why not use XML? It's much more powerful, and there's _lots_ of support
for it in the standard libraries... You can even use the xmlrpclib for
simple serialisation:
>>> from xmlrpclib import dumps, loads
>>> params = ['foo', 'bar', 1.0, 2, {'baz':42}],
>>> string = dumps(params)
>>> print string
<params>
<param>
<value><array><data>
<value><string>foo</string></value>
<value><string>bar</string></value>
<value><double>1.0</double></value>
<value><int>2</int></value>
<value><struct>
<member>
<name>baz</name>
<value><int>42</int></value>
</member>
</struct></value>
</data></array></value>
</param>
</params>
>>> loads(string)[0][0]
['foo', 'bar', 1.0, 2, {'baz': 42}]
As an added bonus, you can now easily transfer PythonCard stacks via
xmlrpc -- even to apps written in other languages <wink>.
And for a simpler grammar, the (X)HTML table is quite nice for this sort of
thing. CVS is cute, but if you don't have to work with Excel etc. it may
not be the best technology to use... (And you could always use tab-separated
values, which is much simpler, and which is also supported by Excel etc.)
> ka
--
 Magnus Lie Hetland http://www.hetland.org
 "Reality is that which, when you stop believing in
 it, doesn't go away." -- Philip K. Dick

> Why do you think it has to be written in C? The format is quite simple
> and speed is unlikely to be an issue. Requiring more extensions to be
> bundled with PythonCard to make it work will make it more trouble
> to set up
> correctly.
I suggested to Dave Cole that he should try and get his stuff bundled into
the Python Standard Libraries. I would prefer a pure Python solution for now
if we have to distribute it with PythonCard.
> Is CSV import / export something that needs to be solved now? Is it
> required by something else?
This issue came up because of the addresses and dbBrowser samples. A CSV
module would allow simple import/export for any PythonCard app. It isn't
critical right now, so anyone that wants to can pursue it and just add the
module to cvs when it is ready and notify the list. I'm not actively
pursuing it myself except via email.
ka

[Skip]
> I have been using a Python-based CSV reader/writer by another person, but
> will be switching over to Dave Cole's extension module as I have time. I
> think it's the way to go. CSV is a hack of a format and doesn't yield
> itself to simple, quick parsing things like using regular expressions or
> string.split. I think it needs to be written in C.
 Why do you think it has to be written in C? The format is quite simple
and speed is unlikely to be an issue. Requiring more extensions to be
bundled with PythonCard to make it work will make it more trouble to set up
correctly.
 Is CSV import / export something that needs to be solved now? Is it
required by something else?
 Neil

> From: Magnus Lie Hetland
>
> By the way, I found this Perl snippet <shudder>
>
> sub parse_csv {
> my $text = shift; # record containing comma-separated values
> my @new = ();
> push(@new, $+) while $text =~ m{
> # the first part groups the phrase inside the quotes.
> # see explanation of this pattern in MRE
> "([^\"\\]*(?:\\.[^\"\\]*)*)",?
> | ([^,]+),?
> | ,
> }gx;
> push(@new, undef) if substr($text, -1,1) eq ',';
> return @new; # list of values that were comma-separated
> }
>
> Makes me remember why I use Python <wink>
Which reminds me of a favorite Jamie Zawinski quote:
Some people, when confronted with a problem, think "I know, I'll use regular
expressions." Now they have two problems.
 --Jamie Zawinski, in comp.lang.emacs
I saw this while reading http://diveintopython.org/dialect_re.html
ka

From: "Kevin Altis" <al...@se...>
> > From: Magnus Lie Hetland
>
> > > I suspect the docstring is a killer:
> > >
> > > Generalized to be usable for any delimiter but \n.
> > >
> > > Many tools can generate CSV files with fields containing newlines.
> >
> > Really? And what do they use as record separator?
>
> The newline is still a record separator except when it occurs inside
quotes.
> Pretty much all Microsoft products support this import/export style and
many
> other apps as well. This allows multi-line data to still be handled by
CSV.
Right. I agree with that. Without checking the code, I believe the statement
is that you can't use \n as a field delimiter, but you can use anything
else.
Since you only need comma, there should be no problem, right?
> > The CSV standard is pretty clear, IIRC: Lines are separated by
> > newlines (possibly cr etc.), and fields by commas. Fields
> > _containing_ commas must be enclosed by quotes, and any literal
> > quotes must be doubled.
>
> Where is the CSV standard documented? That would be useful to have a link
> to.
I think it's an informal (yet clear <wink>) standard... I remember finding
a document at Microsoft, I think -- but I can't find it now. But you're
right
that any field containing anything strange (including newlines, quotes, or
commas) are quoted. I didn't think that was a problem with the code above,
but changing it ought to be trivial.
I have some code around which allows you to use any quote, separator, and
escape character, although I don't think I ever finished it...
By the way, I found this Perl snippet <shudder>
sub parse_csv {
 my $text = shift; # record containing comma-separated values
 my @new = ();
 push(@new, $+) while $text =~ m{
 # the first part groups the phrase inside the quotes.
 # see explanation of this pattern in MRE
 "([^\"\\]*(?:\\.[^\"\\]*)*)",?
 | ([^,]+),?
 | ,
 }gx;
 push(@new, undef) if substr($text, -1,1) eq ',';
 return @new; # list of values that were comma-separated
}
Makes me remember why I use Python <wink>
For more about the format, here is an interesting posting:
http://groups.yahoo.com/group/ourownthoughts/message/335
It's odd that there is no formal definition of this format...
> ka
--
 Magnus Lie Hetland http://www.hetland.org
 "Reality is that which, when you stop believing in
 it, doesn't go away." -- Philip K. Dick

From: "Skip Montanaro" <sk...@po...>
To: <ml...@id...>
Sent: Tuesday, August 28, 2001 6:51 PM
Subject: Re: [Pythoncard-users] CSV for PythonCard
>
> >> I suspect the docstring is a killer:
> >>
> >> Generalized to be usable for any delimiter but \n.
> >>
> >> Many tools can generate CSV files with fields containing newlines.
>
> Magnus> Really? And what do they use as record separator?
>
> Magnus,
>
> I don't know, but I suspect you process fields until you see a newline
> *between* fields. Clearly, an occurrence of a newline within a field
would
> have to be quoted.
>
> Please forward this along to pythoncard for me. Lists.sourceforge.net
> doesn't like me. :-(
>
> Skip

> From: Magnus Lie Hetland
> > I suspect the docstring is a killer:
> >
> > Generalized to be usable for any delimiter but \n.
> >
> > Many tools can generate CSV files with fields containing newlines.
>
> Really? And what do they use as record separator?
The newline is still a record separator except when it occurs inside quotes.
Pretty much all Microsoft products support this import/export style and many
other apps as well. This allows multi-line data to still be handled by CSV.
> The CSV standard is pretty clear, IIRC: Lines are separated by
> newlines (possibly cr etc.), and fields by commas. Fields
> _containing_ commas must be enclosed by quotes, and any literal
> quotes must be doubled.
Where is the CSV standard documented? That would be useful to have a link
to.
ka

I sent this to the anygui to see if the Python gurus over there had a
reasonable solution. I think that what we will probably end up having to do
if we keep dot notation is provide wrapper classes whenever an 'attribute'
is a mutable complex type such as 'font' which is a class and 'items' which
is a list. Most of the other attributes are immutable (strings, tuples) or
simple types (integer) so they aren't a problem.
Wrapping 'items' (a subclass of UserList) or enhancing the Font class is
going to be unclean and isn't going to be any fun and I don't know how it
will impact our ability to eventually support plug-ins say via XPCOM.
One scenario is that we abandon dot notation in which case we'll be back to
normal get/set methods, which is uglier and more to type, but at least it is
consistent and won't surprise anyone by not working the way they expect.
This is probably one of the biggest syntax issues we have to decide. If you
have strong opinions one way or another, you should speak up.
ka
-----Original Message-----
From: Kevin Altis [mailto:al...@se...]
Sent: Tuesday, August 28, 2001 8:47 AM
To: any...@li...
Subject: dot notation revisited
I've run into yet another dot notation issue with PythonCard. I'm bringing
it up here, because it looks like you're heading down the same road, so
maybe you already have a solution.
The problem is when the _get/_set for an attribute involves a complex
mutable type. This could be a list, a dictionary, or another class. I first
ran into it with setting the font for a widget. For example, this is what a
user might like to do:
 self.components.field1.font.size = 12
However, because 'font' is actually a virtual attribute represented in
reality by a _getFont and _setFont what you have to do is:
 f = self.components.field1.font
 f.size = 12
 self.components.field1.font = f
If there was __getattr__ and __setattr__ magic then the user would use (I
removed the leading underscore):
 f = self.components.field1.getFont()
 f.size = 12
 self.components.field1.setFont(f)
so the user in the first instance is effectively trying to do:
 self.components.field1.getFont().size = 12
or at least I think that is what is going on.
Further nastiness occurs with Choice (popup menu), List (scrolling list),
and RadioGroup (group of radio buttons) where there is an 'items' attribute
which is basically a Python list, so to get or set the entire list in one of
the controls you have something like:
 aList = self.components.chsTable.list
 self.components.chsTable.list = aList
The problem occurs when someone tries something like
 self.components.chsTable.insert(0, 'hello')
That doesn't work. The solution would appear to be providing a wrapper class
using UserList and then implementing every list method which in turn does
the right thing to the underlying GUI control. This is a lot of overhead and
a lot of work. It appears that that kind of trickery needs to be done for
any attribute that is mutable and complex, so it isn't a problem with
strings, integers, floats, etc. but lists and dictionaries and classes are a
problem.
Does this make sense? How are you dealing with this in anygui or are you not
using dot notation for attributes?
ka

> I suspect the docstring is a killer:
> 
> Generalized to be usable for any delimiter but \n.
> 
> Many tools can generate CSV files with fields containing newlines.
Really? And what do they use as record separator?
The CSV standard is pretty clear, IIRC: Lines are separated by
newlines (possibly cr etc.), and fields by commas. Fields
_containing_ commas must be enclosed by quotes, and any literal
quotes must be doubled.
I thought most tools followed this standard... Otherwise, calling
the format CSV is something of a misnomer, I should think...
But I may (certainly) be wrong.
> Skip
--
 Magnus Lie Hetland http://www.hetland.org
 "Reality is that which, when you stop believing in
 it, doesn't go away." -- Philip K. Dick

-----Original Message-----
From: Skip Montanaro [mailto:sk...@po...]
Sent: Thursday, August 23, 2001 7:06 AM
To: pyt...@li...
Subject: Re: [Pythoncard-users] CSV for PythonCard
 Magnus> This one's pretty good (the original by Christian Tismer --
 Magnus> don't know where the "official" one is):
 Magnus> http://www.druid.net/~darcy/files/delimited.txt
I suspect the docstring is a killer:
 Generalized to be usable for any delimiter but \n.
Many tools can generate CSV files with fields containing newlines.
Skip

-----Original Message-----
From: Skip Montanaro [mailto:sk...@po...]
Sent: Thursday, August 23, 2001 6:06 AM
To: pyt...@li...
Subject: Re: [Pythoncard-users] CSV for PythonCard
 Kevin> I was looking around for a comma separated values (CSV) module in
 Kevin> the Python Standard Libraries and didn't find one, so I went
 Kevin> hunting on Google. I came up with:
 Kevin> http://object-craft.com.au/projects/csv/
I have been using a Python-based CSV reader/writer by another person, but
will be switching over to Dave Cole's extension module as I have time. I
think it's the way to go. CSV is a hack of a format and doesn't yield
itself to simple, quick parsing things like using regular expressions or
string.split. I think it needs to be written in C.
Skip

Does anyone on the list have experience with either SDL or PyGame? PyGame
was mentioned very early on in the mailing list, but there wasn't any
follow-up. The reason I'm bringing them up now is the possibility of
utilizing SDL and/or PyGame for areas where wxWindows/wxPython is a bit
lacking, in particular sound and video playback.
It could very well be that SDL/PyGame is much better for drawing bitmap
graphics in a frame as well as opposed to using a wxWindows device context.
Anyway, I started an email conversation with the PyGame author, so I might
go off on a tangent to investigate this further before bringing it up on
wx-dev.
If anyone has additional info or experience to add please speak up. Also, if
someone would like to pursue this rather than me, that would also be great,
since investigations are going to take away from other tasks. It does
involve fun stuff like MPEG, MP3, 3D drawing, etc.
Simple DirectMedia Layer (SDL)
http://www.libsdl.org/
"Simple DirectMedia Layer is a cross-platform multimedia library designed to
provide fast access to the graphics framebuffer and audio device. It is used
by MPEG playback software, emulators, and many popular games, including the
award winning Linux port of "Civilization: Call To Power." Simple
DirectMedia Layer supports Linux, Win32, BeOS, MacOS, Solaris, IRIX, and
FreeBSD.
SDL is written in C, but works with C++ natively, and has bindings to
several other languages, including Ada, Eiffel, ML, Perl, PHP, Python, and
Ruby."
PyGame
http://pygame.seul.org/
"Pygame is a set of Python modules designed for writing games. This library
is written on top of the excellent SDL library. This allows you to create
fully featured games and multimedia programs in the python language. The
library is highly portable, with users running on Windows (directx), NT4,
MacOS, OSX, BeOS, FreeBSD, IRIX, and Linux."
ka