[Pythonmac-SIG] advanced newbie questions

Bob Ippolito bob at redivi.com
Tue Jan 27 14:46:42 EST 2004


On Jan 27, 2004, at 1:58 PM, steve harley wrote:

> i'm learning Python, evaluating it for replacing a workflow that is 
> now half in Visual FoxPro, half in UserLand Frontier (running in 
> Virtual PC & Classic respectively under Mac OS X 10.3.2).. given that 
> i find both of those environments very fluid and powerful, but dislike 
> having to use VPC and Classic, Python looks very promising.. it has a 
> coding feel much like Frontier, though i miss coding in an outliner; 
> has anyone found a way to do this for Python, which is so obviously 
> suited?

We don't have an outliner.  I've never used one (and I'm not willing to 
install Classic :) so if you could explain what an outliner does, how 
it works, and what you like most about it.. maybe we can incorporate 
that sort of thing into a future IDE for MacPython.

> since the Frontier part of this workflow heavily exercises the AE 
> capabilities of publishing apps, i was curious to see how Python 
> stacked up.. i read through the recent thread on abstracting the AE 
> functionality, and a few other threads, and got the impression that 
> there are multiple paths, and all are essentially in beta.. by the 
> way, coming from strong familiarity with Mac scripting, that thread 
> really helped me grasp the richness of Python, as it touched on 
> several under-the-hood aspects that intro texts ignore

They're not even beta quality, don't try anything complicated yet.  Or 
at least, if you do, don't spend too much time trying to make it work - 
because it probably won't :)

> anyhow, AppScript looked like the easiest transition from Frontier's 
> object model, so i got the latest version and installed it.. i 
> immediately found a dependency on launchservices.py, so i installed 
> the latest SourceForge version

The LaunchServices that AppScripting depends on is actually mine, not 
the newer standard one.  You can get that from 
http://undefined.org/python/#LaunchServices

Your best bet is just to wait until AppScripting is fixed, or wait for 
the new version of aeve.

> i see some people have trouble getting the dictionary from iTunes.. is
> AppScript able to do this? if not which AE package should i use? (i'm 
> using a small iTunes-related project as an evaluation tool)

AppScripting is not able to do this, due to a bug in the way it tries 
to get the OSA terminology.  aeve does not have this problem, but it 
has a different suite of bugs.  I'm working on a new version of aeve 
that encompasses all of AppScripting's features and then some, but 
don't hold your breath waiting for it, it's probably another few weeks 
out.

> i need some practical advice for persistent storage needs.. 
> unfortunately my workflow depends heavily on both relational and 
> object paradigms (SQL in Visual FoxPro, object databases in Frontier; 
> both *highly* integrated)
>
> for relational purposes, easiest for me would be SQL back end; bearing 
> in mind i'm used to completely integrated, inline SQL, with little 
> fiddling or setup required, are there any gotchas or strong positives 
> (from the Python on Mac OS X perspective) for MySQL or Postgres? is 
> there some other approach which would let me do complex joins and 
> many-to-many relations?

Don't use MySQL, use PostgreSQL.  PostgreSQL has a better license, 
supports more SQL, and the Python interface actually works properly.  
MySQL loses on all three counts there.

There are other SQL databases that run in-process and have Python 
interfaces that might be of interest (but I can't think of their 
names), ZODB is a really good transactional versioned object database, 
and Metakit is sort of a hybrid between relational and object database.

> for object storage, i get the impression there are various "object 
> serialization" approaches.. since i'd probably eventually use PyObjC 
> to build interfaces, i'd also consider a Cocoa-based approach.. from 
> either the pure Python or Cocoa sides, is there one that stands out? 
> what are the performance considerations? (most of my objects are 
> probably smaller than 10KB)

Object serialization is a problem if you're mixing PyObjC and Python 
classes.. you have to decide one way or the other as to which kind of 
objects you're going to serialize.  In the only-python route you can 
use regular 'ol pickle and possibly shelve or something more advanced 
like ZODB.. otherwise you're using plists with the Cocoa classes.  It's 
probably even possible to add pickle integration to the plist stuff, by 
having Python objects support the coding protocols -- or add __reduce__ 
functionality to Cocoa classes to allow them to be pickled.  I don't 
think either of these has been looked into, though.

> for either of these storage needs, are there good abstraction 
> libraries so that i could switch storage types later if needed?

Relational databases in Python all use the DB-API spec, so switching 
can be as simple as changing the module and connect string.  There are 
higher level things you can shim on top, such as PEAK, but you probably 
don't need them.  Learn Python first, then worry about the big 
frameworks that make it easier for large applications :)

The best way to do it is to figure out what you need to do first, 
before getting mixed up in relational vs object vs hybrid databases and 
picking a particular product to do it with.  SQL certainly feels like a 
kludge after a while with ZODB or MetaKit, because you can eschew the 
whole ORM layer (object-relational mapping) and Just Use Objects.  
Python is a terse enough language to write queries yourself, working 
with the native object structures, and can even be faster than SQL (if 
a query doesn't lend itself to a relational representation, or if 
you're smarter than the SQL database's optimizer).

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040127/c87dae9f/smime.bin


More information about the Pythonmac-SIG mailing list