Re: Expanding Python as a macro language

[has]

Alex Martelli wrote:

> Don't neglect MacOSX -- it's quite secure, there are many open and free
> applications, AND it has a decent architecture for the kind of tasks you
> want to do (mostly intended for Apple's own Applescript language, but
> all the interfaces are open and easily available to Python, which is
> quite well supported on the Mac).

FWIW, there's a nice overview of the Open Scripting Architecture at:

http://www.cs.utexas.edu/users/wcook/papers/AppleScript/AppleScript95.pdf

It's not a perfect system and the quantity and quality of support
varies from application to application and language to language, but I
reckon the other *nixes could still learn a thing or two from it.

HTH

has
-- 
http://freespace.virgin.net/hamish.sanderson/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: HTML generation vs PSP vs Templating Engines

[has]

[EMAIL PROTECTED] wrote:

> Could someone that has used all the different ways mentioned above for
> dynamic HTML
> content, suggest what the pros and cons of the different methods are?

Not used them all - as you say, there's a plethora of options - but to
give you a general idea of the territory...

First choice you have is between HTML generators vs. HTML templating
systems:

- HTML generators create all markup from scratch. Useful when producing
arbitrary markup/layout whose entire structure must be determined
programmatically, e.g. applying paragraph and character styling to a
big chunk of text, creating arbitrary HTML form layouts based on other
input. Examples: htmlgen (crusty, HTML 3.1-era), Nevow's Stan engine.

- HTML templates insert individual items of data into a mostly static
block of HTML markup written in advance by e.g. a graphic designer.
Useful when creating documents that are fairly regular in structure -
most fall into this category - as it's much easier to create the
repetitious parts using standard HTML editing tools than write code to
produce it all programmatically.

Sometimes you might combine the two methods, using an HTML generator to
create sections of markup from arbitrary input which is then inserted
into a full-page template to produce the finished HTML document.


Assuming a templating-based solution is the appropriate choice for you
(which it most likely is), there are three general approaches to choose
from:

1. Systems that embed markup in code. This is a fairly small category.
It's fairly programmer-friendly since you've direct access to all
language features, but hostile to web designers as you have to pull
your HTML markup apart and insert it into program code to produce the
final template, making it a pain to modify that markup later. Examples:
ad-hoc solutions using Python's string interpolation, the Quixote
framework's built-in templating support, Karrigell (though it supports
some aspects of approach 2 as well).

2. Systems that embed code in markup. This is the most common category
with a fair amount of variety and capabilities to choose from. Lots of
obviously PHP/ASP-inspired designs. Two sub-categories: systems that
embed standard Python code, e.g. PSP, and systems that embed a custom
language, e.g. Cheetah. Some provide no restrictions on what you can
get up to within embedded code, others restrict functionality to
enforce a strict separation between presentation logic and model logic.
Embedding styles also vary: some mix code statements and markup
directly (e.g. Cheetah), some embed code statements in special <%...%>
style tags (e.g. PSP), some hide all code within HTML tag attributes
(e.g. TAL, Kid), providing varying degrees of designer-friendliness as
a result.

3. DOM-style systems. This is a more recent arrival and a smaller
category. These systems completely separate markup from presentation
logic. Selected HTML elements are flagged using specific named tag
attributes (e.g. id="somename") or simple compiler directives, e.g.
(nevow:render="somename"); the template is then compiled into a simple
templating-oriented (i.e. not w3c) DOM, allowing these elements to be
manipulated programmatically by standard Python scripts. Very designer
and developer friendly, although less experienced programmers may find
the higher level of abstraction involved a bit offputting. Examples:
PyMeld, HTMLTemplate [1], Nevow.Render.


For a fairly extensive list of available systems, see
<http://wiki.python.org/moin/WebProgramming>. Unfortunately they're not
well categorised there, but I can't think of a better, up-to-date list
off the top of my head and most will provide decent overviews so it
shouldn't take too long to take a quick look at each.

Note that some templating engines are embedded into larger web
programming frameworks and may or may not be usable independently.
Conversely, some web frameworks may be coupled to a specific templating
system, while others allow you to choose your own.

HTH

has

--
[1] Disclaimer: I wrote HTMLTemplate. Also, shameless plug:
<http://freespace.virgin.net/hamish.sanderson/htmltemplate.html>

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: HTML generation vs PSP vs Templating Engines

[has]

[EMAIL PROTECTED] wrote:
> I dislike embedding code or html in each other, apart from the
> 'impurity' of mixing code and user interface it makes them inseparable.
>
> Using templates means that the code can work with different templates,
> and this should be seamless, it also means that different code can be
> used with the templates, for example if different languages are used.

This seems to contradict your statement that you dislike 'embedding
code or html in each other', since the scenarios you describe still
involve embedding presentation logic in markup. (The only templating
systems that *completely* separate logic from markup are the DOM-style
ones.)

I assume what you really meant is that you don't like embedding *model*
logic in markup, which is generally good design practice. However,
templating systems that use Python for presentation logic (Karrigell,
PSP, Nevow, HTMLTemplate, etc) certainly don't force you to put model
logic into the template; you are quite entitled to keep that separate
as per MVC. They just don't *enforce* the model logic/presentation
logic separation as some authoritarian custom language-based systems
do.

HTH

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: HAVE YOU HEARD THE GOOD NEWS!

[has]

[EMAIL PROTECTED] wrote:

> Good News!

What! Guido's just announced Python 3000? Woo-HoOh.

F**t.

--

TROLLS 13.12: 'And lo, did the Lord Gawd Almighty command: "Go ye forth
and Spam all the Seven Thousand and Seventy-seven Groups of Usenet. For
truly I am a Beneficent Gawd, and shall surely be picking up the Bill
for all thy blessed recipients' Freaking Bandwidth Charges - NOT!"'

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Spreadsheet with Python scripting and database interface?

[has]

Wolfgang Keller wrote:

> Excel: I know of a module that allows to script Excel in Python from
> outside (COM scripting on Windows and Applescript on MacOS are know as
> well), but I don't know of any possibility to do Python scripting with
> Excel itself?

For scripting Mac applications with Python instead of AppleScript, see:


http://freespace.virgin.net/hamish.sanderson/appscript.html

HTH

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A great Alan Kay quote

[has]

Grant Edwards wrote:
> In an interview at
http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=273
> Alan Kay said something I really liked, and I think it applies
> equally well to Python as well as the languages mentioned:
>
>I characterized one way of looking at languages in this
>way: a lot of them are either the agglutination of features
>or they're a crystallization of style

I'd say Python is somewhere in the middle, though moving slowly towards
'agglutination' in the last couple years.


> The rest of the interview is pretty interesting as well.

Excellent link, thanks.

-- 
http://mail.python.org/mailman/listinfo/python-list

[ann] Appscript Installer 1.0

[has]

Hi all,

Announcing the first release of the all-in-one Appscript Installer
package for Mac OS X 10.3.

Appscript brings AppleScript-quality application scripting support to
MacPython on Mac OS X. This package installs everything you need to
control "Applescriptable" applications using the Python 2.3 runtime
included as standard in Mac OS X 10.3.

In addition to a clean, easy-to-use, object oriented-like syntax for
scripting applications, appscript also includes powerful built-in help
facilities for exploring applications' terminology and object model -
features normally found only in high-end commercial AppleScript
editors.

To download Appscript Installer, please visit the appscript webpage:

http://freespace.virgin.net/hamish.sanderson/appscript.html

To see some examples of use:

http://freespace.virgin.net/hamish.sanderson/appscript_examples/index.html

If you have any questions or comments, please don't hesitate to get in
touch. We're still working to polish appscript and finish its
documentation, so all feedback is greatly appreciated.

Enjoy!

has

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: recommended way of generating HTML from Python

[has]

xtian wrote:
> Stan (part of nevow, which is part of twisted) is a nice python
syntax
> for building HTML
[...]
> I don't know how detachable it is from the rest of nevow. I'd assume
it
> wouldn't be too difficult to implement in a standalone fashion.

FWIW I whipped up a simple self-contained Stan clone a while back:

http://freespace.virgin.net/hamish.sanderson/stanlite.py

It's a bit quick-n-dirty - I think ideally you'd want it to parse all
the HTML element information from a DTD and perform proper validation
of input data - but if anyone want to pick it up and run with it, or
just use it as-is, they're more than welcome to.

HTH

has

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: recommended way of generating HTML from Python

[has]

Kent Johnson wrote:
> Michele Simionato wrote:
> > The problem is a problem of standardization, indeed. There plenty
of
> > recipes to
> > do the same job, I just would like to use a blessed one (I am
teaching
> > a Python
> > course and I do not know what to recommend to my students).
>
> Why not teach your students to use a template system?

Agreed. Don't use HTML generation simply for the sake of it. While it
has its niche, for most tasks templating is more appropriate. There
aren't any 'blessed' solutions, so just pick whichever third-party
system best fits your needs.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to launch pdf viewer on Mac?

[has]

Paul McNett wrote:

> On Windows, os.startfile() does what I want:
>
> os.startfile("myDocument.pdf")
>
> But on Mac, what do I do?

os.system("open myDocument.pdf")

HTH
has

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: RPC with Python - Comparison?

[has]

Wolfgang Keller wrote:

> Candidates could be:
>
> - Pyro
> - Twisted.spread
> - OSE (XML-RPC)
> - ICE
> - ...others?

MacPython also supports Apple events (high-level bridge:
)

HTH

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: RPC with Python - Comparison?

[has]

Wolfgang Keller wrote:

> > MacPython also supports Apple events
>
> I know, but I was thinking of OS-independent RPC protocols. :-)
Pity, you're missing some good stuff... :/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: RPC with Python - Comparison?

[has]

Wolfgang Keller wrote:
> Am 6 Dec 2004 16:00:35 -0800 schrieb has:
>
> > Wolfgang Keller wrote:
> >
> >>> MacPython also supports Apple events
> >>
> >> I know, but I was thinking of OS-independent RPC protocols. :-)
> > Pity, you're missing some good stuff... :/
>
> _I_ _am_ using a Mac at home.
>
> But not _everyone_ _else_ and especially not _every_ _company_ is
using
> _exclusively_ Macs.

Of course. Would it be tactless to mention you're also missing out on
DCOM and WSH? ;)

has 

(p.s. Seriously, why not just cover everything? Platform(s) support is
just another feature.)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: RPC with Python - Comparison?

[has]

Wolfgang Keller wrote:
> Am 6 Dec 2004 16:00:35 -0800 schrieb has:
>
> > Wolfgang Keller wrote:
> >
> >>> MacPython also supports Apple events
> >>
> >> I know, but I was thinking of OS-independent RPC protocols. :-)
> > Pity, you're missing some good stuff... :/
>
> _I_ _am_ using a Mac at home.
>
> But not _everyone_ _else_ and especially not _every_ _company_ is
using
> _exclusively_ Macs.

Of course. Would it be tactless to mention you're also missing out on
DCOM and WSH?



has

(p.s. Seriously, why not just cover everything? Platform(s) support is
just another feature.)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Cool object trick

[has]

Jive wrote:

> # Is that really much different from this?

Functionally, no. However it can help make code more readable when
dealing with complex data structures, e.g. compare:

obj.spam[1].eggs[3].ham

to:

obj["spam"][1]["eggs"][3]["ham"]

I've used it a couple times for this particular reason and it
definitely has its niche; though I'm not sure it's sufficiently common
or useful to justify its inclusion it in the standard library, and it's
trivial to whip up as-and-when it's needed.

BTW & FWIW, I think the usual name for this kind of structure is
'record' (or 'struct' in C).

HTH

has

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Funny story about python

[has]

[EMAIL PROTECTED] wrote:
> eScrew
> Welcome to eScrew!
>
> eScrew is eScrew and this is eScrew story.

[snip massive waste of bytes]
Not sure which is less Turing-complete: eScrew, or eScrew's author...

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Funny story about python

[has]

has wrote:

> Not sure which is less Turing-complete: eScrew, or eScrew's author...
Oops, I meant 'AI-complete'.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Funny story about python

[has]

has wrote:

> Not sure which is less Turing-complete: eScrew, or eScrew's author...
Oops, I meant 'AI-complete'.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Funny story about python

[has]

has wrote:

> Not sure which is less Turing-complete: eScrew, or eScrew's author...
Oops, I meant 'AI-complete'.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Funny story about python

[has]

has wrote:

> Not sure which is less Turing-complete: eScrew, or eScrew's author...
Oops, I meant 'AI-complete'.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Funny story about python

[has]

has wrote:

> Not sure which is less Turing-complete: eScrew, or eScrew's author...
Oops, I meant 'AI-complete'.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Funny story about python

[has]

has wrote:
>
> > Not sure which is less Turing-complete: eScrew, or eScrew's
author...
>
> Oops, I meant 'AI-complete'.
On second thoughts, 'Turing-complete' works too.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: (Mac-specific) AppScript bug

[has]

George van den Driessche wrote:
> (This is really for Hamish Sanderson, I think, but I can't find an
> e-mail address for him.)

No worries. (Email addy is buried in appscript-0.7.1 > Manual.txt >
Authors, though some releases listed a duff address which certainly
didn't help. Better documentation is on my TO-DO list.)


> On OS X 10.3.7, with XCode 1.5 and all the latest AppScript packages
> installed, writing this:
>
>   a = appscript.app( 'XCode.app' )
>
> causes a crash in terminology.py:
[...]
> code is a FourCC identifying some part of XCode's script interface.
You
> would imagine that every such part would have either a plural name or
a
> singular name, but in this case somehow the FourCC '' has ended
up
> in self._elements and it has neither. Any idea how that might arise?

Sounds like a bug in XCode's terminology resource. I'd need to see the
raw terminology to say for sure. If you want to use the
osaterminology.tools.quickdoc module to dump it to text file and send
if over I'll take a look.


>  If you change the marked line (104) to read:
>
>   name = self._pluralClassNames.get(code,
> self._singularClassNames.get(code, ''+code))
>
> then the rest of the terminology seems to run fine, and you just end
up
> with one bogus entry called '' in the app's attributes.

Appscript-0.9.0 does this. Should be ready in another few days - I'll
post when it's out. Buggy terminology resources are unfortunately a
fairly common problem, and I'm still figuring out how best to deal with
them. Welcome to the wonderful and wonky world of Mac application
scripting. :p

HTH and thanks,

has

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: BASIC vs Python

[has]

Andrew Dalke wrote:
> /F
> > import random, winsound
>
> Now if it only worked for my mac ...
This might help:

http://www.stanford.edu/~andyszy/pyper/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: THE GREATEST NEWS EVER ! °º·...·°`°º·...·°`°º·...·°`°º·...·°`°º·...·°`°º·...·°`°º·...·°`°º·...·°`°º·...·°`°º·...·°`°º·...·°`°º·...·°`°º·...·°`°º·...·°`°º·...·°`°º·...·°`°º·...·°`°º·...·°`°º·...·°`°º·...·°`°º·...·°`°º·...·°`°º·...·°`°º·...·°` (newsgroup-post 127)

[has]

No, the greatest news ever would be that Usenet spammers are being
riveted to trees.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python licence again

[has]

John J. Lee wrote:
> Yes.  ISTR that licence is a British English spelling, though my
> British brain has been thoroughly contaminated by US spellings and
> usage by now.

Oh, it only gets worse: a couple years on the illiterate intarweb and
even basics like "its" and "it's" become a major struggle. ;p

> (Or are they like practice and practise, which (can)
> mean subtly different things in British English

Yep, we aim to confuse:

licence, practice = noun
license, practise = verb

/grammar geek

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: MVC programming with python (newbie) - please help

[has]

sed with the Model's state in an MVC-based
system?

Here's the problem: many View objects are stateful, e.g. a checkbox may
be ticked or unticked, a text field may contain some editable text.
However, MVC dictates that all user data be stored in the Model layer,
so any data held by other layers for display purposes (the checkbox's
state, the text field's current text) must therefore be a subsidiary
copy of that primary Model data. But if the Model's state changes, the
View's copy of that state will no longer be accurate and needs to be
refreshed.

But how? The MVC pattern prevents the Model pushing a fresh copy of
that information into the View layer. Heck, it doesn't even allow the
Model to send the View a message to say its state has changed.

Well, almost. Okay, the Model layer isn't allowed to talk directly to
other layers, since to do so would require it knows something about
those layers, and MVC rules prevent that. However, if a tree falls in a
forest and nobody's around to hear it, does it make a sound?

The answer, you see, is to set up a notifications system, providing the
Model layer with a place it can announce to no-one in particular that
it has just done something interesting. Other layers can then post
listeners with that notification system to listen for those
announcements that they're actually interested in. The Model layer
doesn't need to know anything about who's listening (or even if anyone
is listening at all!); it just posts an announcement and then forgets
about it. And if anyone hears that announcement and feels like doing
something afterwards - like asking the Model for some new data so it
can update its on-screen display - then great. The Model just lists
what notifications it sends as part of its API definition; and what
anyone else does with that knowledge is up to them.

MVC is preserved, and everyone is happy. Your application framework may
well provide a built-in notifications system, or you can write your own
if not (see the 'observer pattern').

...

Anyway, hope that helps. Once you understand the motivations behind
MVC, the reasons why things are done the way they are starts to make
sense, even when - at first glance - they seem more complex than
necessary.

Cheers,

has

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: MVC programming with python (newbie) - please help

[has]

sed with the Model's state in an MVC-based
system?

Here's the problem: many View objects are stateful, e.g. a checkbox may
be ticked or unticked, a text field may contain some editable text.
However, MVC dictates that all user data be stored in the Model layer,
so any data held by other layers for display purposes (the checkbox's
state, the text field's current text) must therefore be a subsidiary
copy of that primary Model data. But if the Model's state changes, the
View's copy of that state will no longer be accurate and needs to be
refreshed.

But how? The MVC pattern prevents the Model pushing a fresh copy of
that information into the View layer. Heck, it doesn't even allow the
Model to send the View a message to say its state has changed.

Well, almost. Okay, the Model layer isn't allowed to talk directly to
other layers, since to do so would require it knows something about
those layers, and MVC rules prevent that. However, if a tree falls in a
forest and nobody's around to hear it, does it make a sound?

The answer, you see, is to set up a notifications system, providing the
Model layer with a place it can announce to no-one in particular that
it has just done something interesting. Other layers can then post
listeners with that notification system to listen for those
announcements that they're actually interested in. The Model layer
doesn't need to know anything about who's listening (or even if anyone
is listening at all!); it just posts an announcement and then forgets
about it. And if anyone hears that announcement and feels like doing
something afterwards - like asking the Model for some new data so it
can update its on-screen display - then great. The Model just lists
what notifications it sends as part of its API definition; and what
anyone else does with that knowledge is up to them.

MVC is preserved, and everyone is happy. Your application framework may
well provide a built-in notifications system, or you can write your own
if not (see the 'observer pattern').

...

Anyway, hope that helps. Once you understand the motivations behind
MVC, the reasons why things are done the way they are starts to make
sense, even when - at first glance - they seem more complex than
necessary.

Cheers,

has

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: MVC programming with python (newbie) - please help

[has]

sed with the Model's state in an MVC-based
system?

Here's the problem: many View objects are stateful, e.g. a checkbox may
be ticked or unticked, a text field may contain some editable text.
However, MVC dictates that all user data be stored in the Model layer,
so any data held by other layers for display purposes (the checkbox's
state, the text field's current text) must therefore be a subsidiary
copy of that primary Model data. But if the Model's state changes, the
View's copy of that state will no longer be accurate and needs to be
refreshed.

But how? The MVC pattern prevents the Model pushing a fresh copy of
that information into the View layer. Heck, it doesn't even allow the
Model to send the View a message to say its state has changed.

Well, almost. Okay, the Model layer isn't allowed to talk directly to
other layers, since to do so would require it knows something about
those layers, and MVC rules prevent that. However, if a tree falls in a
forest and nobody's around to hear it, does it make a sound?

The answer, you see, is to set up a notifications system, providing the
Model layer with a place it can announce to no-one in particular that
it has just done something interesting. Other layers can then post
listeners with that notification system to listen for those
announcements that they're actually interested in. The Model layer
doesn't need to know anything about who's listening (or even if anyone
is listening at all!); it just posts an announcement and then forgets
about it. And if anyone hears that announcement and feels like doing
something afterwards - like asking the Model for some new data so it
can update its on-screen display - then great. The Model just lists
what notifications it sends as part of its API definition; and what
anyone else does with that knowledge is up to them.

MVC is preserved, and everyone is happy. Your application framework may
well provide a built-in notifications system, or you can write your own
if not (see the 'observer pattern').

...

Anyway, hope that helps. Once you understand the motivations behind
MVC, the reasons why things are done the way they are starts to make
sense, even when - at first glance - they seem more complex than
necessary.

Cheers,

has

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: MVC in wxPython HELP!

[has]

If folk wish to post that spiel anywhere else, be my guest. Public
domain and all that.

has

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Clicking at a certain x,y position in python? (Mac OSX)

[has]

Nainto wrote:
> I have been searching and searching and cannot find a way to click at a 
> certain position in python.

What for? There's a few ways it might be done, but what's best depends
on what you're trying to achieve.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: win32com.client & OS X

[has]

> I'd like to know if it is possible to call the win32com.client
> component using Python on MAC OS X (or maybe Linux) and, if so, how?

OS X doesn't really do COM; it's mostly Apple events at the desktop
level. See  for a Python-AE bridge.
If you want more detailed advice, give some info about what you want to
do.

HTH

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: was python implemented as a object oriented langage at the beginning ?

[has]

MonkeeSage wrote:
> [...] just because a language doesn't implement OO in the
> exact same way as another doesn't mean it isn't OO -- it just means
> it's a different language.

I've a suspicion that folk who aren't familiar with the Python object
system automatically assume the phrase 'Python types' means
C++/Java-style primitives - which it doesn't. Python's type/class
distinction may be klunky and inelegant, but it's still OO.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is there a way to push data into Ical from Python ?

[has]

dwhall wrote:

> One way would be to use
> Python's tie-ins to Applescript_ and apple events (AE).  As you will
> read, this support isn't as strong as it used to be.

What gave you that impression, if you don't mind my asking?

It's true that Python's built-in application scripting support
(aetools+gensuitemodule) has become increasingly broken on OS X and
should be avoided. Third-party support has been continually improving
over the last few years, however, and these days is pretty much on-par
with AppleScript in terms of functionality. See
<http://appscript.sourceforge.net> for more information and downloads.


> Another idea that would require more effort, but earn you some hacker
> points, is to use PyObjC_ and access iCal's public programming
> interface.

The CALCore framework is private in OS X 10.4, so the usual disclaimers
apply w.r.t. using that. See <http://www.cocoadev.com/index.pl?CALCore>
for a basic example of use. Scuttlebutt says there'll be a public iCal
framework in 10.5, although that won't help the OP right now unless
they're a paid-up ADC member.

has
-- 
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: templates

[has]

Christoph Zwerschke wrote:
> thakadu schrieb:
> > I have used PyMeld (http://www.entrian.com/PyMeld/) which is one of
> > very few that gives a 100% separation of code and presentation, in fact
> > PyMeld is not strictly speaking a template system at all.
>
> Yes, it is more like XIST that I mentioned in another post.
> The reason why this is slower than native templates seems clear: You
> convert the whole page to objects in memory, and then serialize
> everything back to HTML.

PyMeld's not a good example to judge DOM-style templating by: the main
reason it's a poor performer is its implementation is very inefficient.
There's a couple of third-party redesigns kicking about the web if you
want to search for them; I've not tried them myself but I imagine
performance is one of the issues they address.

It is true that DOM-style templating engines will still tend to be a
bit slower at rendering than a macro-style templating engine even when
all else is equal, but that's a price you always pay for choosing a
dynamic over a static approach.

For example, I once did some quick-n-dirty comparisons for my own
HTMLTemplate engine [1] which is fairly well optimised pure Python
code, and reckon its performance on typical insertion and iteration
tasks is maybe 1/2 - 1/3 of Cheetah's. (IIRC, PyMeld ran up to 100x
slower in those particular tests due to its naive algorithms.)

OTOH, you have to remember that HTML rendering is only one small
component in the overall application, so you really have to consider
this against the performance of the rest of the application to know if
a 2-3x difference in rendering speed makes a significant difference or
not. Chances are the biggest bottlenecks will lie elsewhere. Besides,
if pedal-to-the-metal performance is your primary concern, you should
probably be writing everything in C++ anyway.


> If you are only filling in a few words, then
> native templates will be surely much more effective. But if you are
> messing around with the structure of your page, inserting and adding
> elements, then PyMeld will be probably a better way.

I dunno; DOM-style engines work fine even for simple jobs, while the
big macro-style engines can do a lot of fancy stuff too. I think the
major difference is that the DOM-style engines do things much more
simply. For example, HTMLTemplate's codebase, API and documentation are
maybe a tenth the size of Cheetah's. Rather than trying to provide
every possible feature users might ever want themselves (c.f.
Greenspun's Tenth Rule), they keep out of the way as much as possible
and let the original language provide for the user's needs.

HTH

--

[1] http://freespace.virgin.net/hamish.sanderson/htmltemplate.html

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: templates

[has]

thakadu wrote:
> I did not try PyMeldLite because the HTML I am using is exactlty that:
> HTML and not XHTML.

FWIW, HTMLTemplate is pretty lax and not restricted to XHTML. The only
XML-ish requirement is that elements need to be properly closed if
they're to be used as template nodes, e.g. ...
and , not ... and . Otherwise, it should cope with pretty much any old
markup as long as HTMLParser can make sense of it.

> and I get a lot of invalid HTML from the designers

You might consider throwing HTMLTidy  at
it.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Problem combining python code and html

[has]

Hansan wrote:

> And is there a nother way to combine python code and html templates?

There's a decent list of Python templating engines at:

http://www.python.org/moin/WebProgramming

Look about a third of the way down down under "Variable
Insertion-Replacement Templating Applications (Pre-processors)". The
title is ridiculous but the links are sound.

HTH

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: scripting browsers from Python

[has]

Simon Brunning wrote:
> On 31 May 2005 00:52:33 -0700, Michele Simionato
> <[EMAIL PROTECTED]> wrote:
> > I would like to know what is available for scripting browsers from
> > Python.
>
> I don't know of anything cross platform, or even cross browser, but on
> Windows, IE can be automated via COM

On OS X you can use appscript
<http://freespace.virgin.net/hamish.sanderson/appscript.html>, either
directly via the application's scripting interface if it has one or
indirectly by manipulating its GUI via GUI Scripting.

HTH

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to get name of function from within function?

[has]

Christopher J. Bottaro wrote:

> Basically I want to wrap every function in try/except automatically.

Simplest way to do that would be something like:

def wrapFunction(func):
def wrapper(*args, **kargs):
try:
return func(*args, **kargs)
except Exception, e:
raise # your error handling code here
return wrapper

HTH

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: xlrd question

[has]

On Aug 4, 1:48 am, [EMAIL PROTECTED] wrote:

> I ran your code which gave me this:
>
> >>> import sys, xlrd; print sys.version; print xlrd.__file__
>
> 2.3.5 (#1, Jan 30 2006, 13:30:29)
> [GCC 3.3 20030304 (Apple Computer, Inc. build 1819)]
> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site 
> -packages/
> xlrd/__init__.pyc

Note that:

/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/
site-packages

is actually just a symlink to:

/Library/Python/2.3/site-packages

While third-party modules do usually go in python2.x/site-packages,
Apple don't like users messing about in /System so their stock Python
installation keeps third-party modules under /Library instead.

The exact location varies depending on OS version: on 10.3 it's /
Library/Python/2.3; on 10.4 it's /Library/Python/2.3/site-packages.
Modules installed via DistUtils/EasyInstall will be placed in the
appropriate location automatically.

For more information on installing DistUtils packages, see:

http://docs.python.org/inst/inst.html


> and as far as I can tell, the runxlrd.py file is located here (where I had 
> drug this folder
> originally):
>
> Macintosh HD/xlrd-0.6.1/scripts/runxlrd.py

Nope,  DistUtils will copy all modules to site-packages as part of the
installation procedure. If you're a developer you'll probably want to
keep the original distribution around as it'll contain documentation,
examples, etc. which you'll want to refer to when writing your own
scripts. End-users of your scripts won't need it though.

([OT] Tip: dumping user files under / is poor etiquette; that's what
your home directory under /Users is for.)


> While I'm talking about Excel, is there any other program (for Python) that 
> can edit Excel files?

You can script Excel directly from Python via appscript which talks to
scriptable Mac apps via the same API as AppleScript:

http://appscript.sourceforge.net

I don't do any Excel scripting myself, but Matt Neuburg includes a
nice example in this article on the Ruby version of appscript (which
has a similar syntax):

http://www.oreillynet.com/pub/a/mac/2007/02/27/replacing-applescript-with-ruby.html

If you need more info just ask.

HTH

has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: xlrd question

[has]

On 5 Aug, 19:43, jay <[EMAIL PROTECTED]> wrote:

> So if I'm understanding this correctly, it really only  
> installs something in '/Library/Python/2.3/site-packages'

Correct.

> (as well as  
> an alias to it from '/System/Library/Frameworks/Python.framework/
> Versions/2.3/lib/python2.3/site-packages')

No, /System.../python2.3/site-packages is a symlink to /Library/Python/
2.3/site-packages set up by Apple. DistUtils makes no modification to
anything under /System.

HTH

has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Removing Python 2.4.4 on OSX

[has]

On 24 Mar, 18:55, "7stud" <[EMAIL PROTECTED]> wrote:
> I don't know if there is a framework install for 2.5.

http://www.python.org/ftp/python/2.5/python-2.5-macosx.dmg


has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
http://appscript.sourceforge.net/objc-appscript.html

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Removing Python 2.4.4 on OSX

[has]

On 25 Mar, 06:11, "7stud" <[EMAIL PROTECTED]> wrote:
> There it is.  I notice there is a directory: /Python.framework/
> Versions/2.3/Mac/Tools/IDE
> which has a bunch of files in it.  Do Macs have some kind of pre-
> installed Python IDE?  There's no read me file, so I can't tell what
> all the files are for.

That's the source for the old MacPython IDE which is now defunct. Just
ignore it.

Apple don't bundle a Python IDE in OS X. However, the Python 2.5
installer (http://www.python.org/ftp/python/2.5/python-2.5-macosx.dmg)
includes a copy of IDLE (not very Mac-like, unfortunately) and there
are various third-party editors available if you want to search
around.


has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
http://appscript.sourceforge.net/objc-appscript.html

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Removing Python 2.4.4 on OSX

[has]

On 24 Mar, 18:30, "Robert Hicks" <[EMAIL PROTECTED]> wrote:
> I want to upgrade to 2.5 but I don't see any unistall instructions
> anywhere.

To repeat what others have said: don't uninstall existing
Python.framework builds. Frameworks support multiple versions quite
happily, and removing them is more hassle than it's worth. Just
install the official framework build from python.org (http://
www.python.org/ftp/python/2.5/python-2.5-macosx.dmg), which should
also update your shell profiles as necessary.

HTH

has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
http://appscript.sourceforge.net/objc-appscript.html

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python module for making Quicktime or mpeg movies from images

[has]

On 12 Oct, 20:53, jeremito <[EMAIL PROTECTED]> wrote:

> I actually found NodeBox in my googling.  This seems to be a stand
> alone application.  I need to be able to convert my images to a movie
> from my code I wrote myself.

Some Mac-specific options:

- QuickTime Player is standard on OS X and its scripting interface
(which you can access from Python via appscript, and is fully usable
even in unpaid mode) includes an 'open image sequence' command. This
would be the simplest solution as long as you don't mind launching
another application to do the work.

- The Cocoa API's QTKit class (accessible via PyObjC) includes a -
addImage:forDuration:withAttributes: method that you could use to
build up a movie yourself.

- The Mac version of Python includes wrappers for a number of Carbon
APIs, including QuickTime. One for brave souls only; QT's C APIs are
notoriously complex, and I've no idea of the quality/reliability of
the Carbon.Qt wrapper (most of Python's Carbon wrappers haven't been
fully maintained since OS9 days).

HTH

has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python on imac

[has]

On 14 Oct, 19:19, John Velman <[EMAIL PROTECTED]> wrote:
> Thanks to all.  I'll look into wx before I get too much further.

- For prebuilt binaries of the Python framework and various third-
party packages, including wxPython, see:

http://www.pythonmac.org/packages/py25-fat/index.html

(Note that some of the packages provided there may not be the very
latest versions, so you might want to check their respective sites as
well.)


- Also check out py2app for building standalone executables:

http://cheeseshop.python.org/pypi/py2app/
http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html


- If you're going to be writing Mac-only applications, you might want
to consider using PyObjC, which provides a two-way bridge between
Python and ObjC, giving you full access to OS X's Cocoa APIs:

http://pyobjc.sourceforge.net/


- The PythonMac-SIG mailing list is the main forum for Python-on-Mac
discussions:

http://mail.python.org/mailman/listinfo/pythonmac-sig


HTH

has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: py2app help

[has]

On 15 Oct, 22:21, Massimo Di Pierro <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Two users have reported this error when used the OSX version of Gluon  
> (http://mdp.cti.depaul.edu/examples)
>
> Traceback (most recent call last):
> File "/Users/jacek/src/gluon/runme.app/Contents/Resources/
> __boot__.py", line 157, in 
>   rograms/gluon/runme.py'))
> File "/Users/jacek/src/gluon/runme.app/Contents/Resources/
> __boot__.py", line 148, in _run
>   target, wasChanged = alias.ResolveAlias(None)
> MacOS.Error: (-35, 'no such volume')
> 2007-10-15 21:29:08.896 runme[8217] runme Error
> 2007-10-15 21:29:08.898 runme[8217] runme Error
> An unexpected error has occurred during execution of the main script
> Error: (-35, 'no such volume')
>
> I made it with py2app and I am relatively new to OSX.
> Does anybody has any idea of what could be wrong?
> I would very much appreciate any help. The code is posted including  
> setup_py2app.

Most of the files in the .app bundle are actually symlinks, so I'm
guessing you built it with the --alias flag which should be used for
development purposes only. You need to rebuild it as a standalone
executable. See the py2app documentation for more info:

http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html

(You might also file a feature request with the py2app developer
asking for it to give a more helpful error message when this error
occurs.)

HTH

has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python module for making Quicktime or mpeg movies from images

[has]

On 16 Oct, 00:55, jeremito <[EMAIL PROTECTED]> wrote:
>
> > -QuickTimePlayer is standard on OS X and its scripting interface
> > (which you can access from Python via appscript, and is fully usable
> > even in unpaid mode) includes an 'open image sequence' command.
>
> I have used this, but I want to automate this so I wanted something I
> could call from my Python script.

That's the idea. e.g. Something like:

from appscript import *
from mactypes import *

mov = app ('Quicktime Player.app').open_image_sequence(Alias('/path/to/
image-1.jpg'), frames_per_second=5)
mov.export(to=File('/path/to/output.mov'), as_=k.QuickTime_movie,
timeout=0)
mov.close(saving=k.no)

The only downside of this approach is that if you're making, say, a
highly polished shrinkwrapped product, having it launch external
applications to do some of the work might not create quite the
impression you want with users.


> > - The Cocoa API's QTKit class (accessible via PyObjC) includes a -
> > addImage:forDuration:withAttributes: method that you could use to
> > build up a movie yourself.
>
> This sounds like a good option.  I have downloaded and installed
> PyObjC and am currently looking for the QTKit class but have been
> unsuccessful so far.  A cursory glance at the documentation hasn't
> produced any help, yet.  I'll keep looking unless you can point to it
> directly.

import QTKit

will import the PyObjC wrapper for the QTKit framework. See PyObjC's
documentation for general usage information Apple's Cocoa
documentation for further information on QTKit itself, e.g.:

http://developer.apple.com/quicktime/qtkit.html

HTH

has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org

-- 
http://mail.python.org/mailman/listinfo/python-list

[ann] Appscript Installer 1.5 released

[has]

Announcing the release of Appscript Installer 1.5, containing all the
latest appscript-related modules, documentation and tools:

http://appscript.sourceforge.net/download.html

Appscript enhances the Python scripting language
(http://www.python.org) with robust, easy-to-use OS X application
scripting support, making Python a serious alternative to AppleScript
for automating your Mac.

This release contains several significant API changes, along with
various bugfixes and other internal improvements, and is recommended
for all users. In addition, the bundled osadict command line tool has
been overhauled to create a powerful interactive dictionary browser and
HTML exporter with support for py-appscript, rb-appscript and
AppleScript formatting styles.

(Existing appscript users: please read the 'API CHANGES' file included
with the appscript package before upgrading from older versions.)

For Python 2.3+ on Mac OS X 10.3 and later.

Enjoy,

has
-- 
http://appscript.sourceforge.net 
http://rb-appscript.rubyforge.org

-- 
http://mail.python.org/mailman/listinfo/python-list

questions on dynamically binding the Python interpreter

[has]

Hi all, need a little bit of advice on dynamically binding an embedded
Python interpreter.

First, the code for anyone that wants a look:

http://trac.macosforge.org/projects/appscript/browser/py-osacomponent/trunk/PyOSA

It's a Python OSA component for OS X. The idea is that you wrap up a
scripting language interpreter as a Carbon Component Manager component
(similar to writing a COM component); applications can then call the
OSA API to load this component into memory whenever they need to run
scripts written in that language. The advantage of this approach over
embedding an interpreter directly in the application is that it's
language-agnostic, so application users can write their scripts in any
language they like (AppleScript, JavaScript, Python, etc.), as long as
there's an OSA component available for it (AppleScript, JavaScriptOSA,
PyOSA, etc.). Great concept - at least in theory.

Now, one of the things about the OSA is that, as one of the old MacOS
school, it was pretty much designed on the assumption that
interpreters would be hosted by the application process itself.
Whereas Python is more of the Unix school, and its own preference
would no doubt be to run as separate processes from the main
application process, with two-way IPC to hook the two together. I'll
likely attempt the latter approach later on (which'll no doubt open a
whole new can of worms), but for now I'm having a go at the former as
it's appears a bit simpler to implement (at least on paper) and will
have better runtime performance (since there's no IPC overhead).

For flexibility, and compatibility with application processes that may
already a Python framework loaded, I'm linking Python dynamically via
CoreFoundation's CFBundle API (which basically provides a nice wrapper
around dlopen &co., amongst other things). I've made some reasonable
progress so far, and the pythonloader code can now locate and bind a
Python.framework without triggering bus errors or anything (a big
achievement for me;). However, there's a couple of places I'm a bit
uncertain on how to proceed:

1. Py_IncRef() and Py_DecRef() only appear to have been added in
Python 2.4; is this right? I really need to support Python 2.3 as well
(since that's the version included as standard on OS X 10.3 & 10.4).
At the moment when 2.3 is imported I'm providing it stubs of these
functions that don't really do anything except leak like sieves;
obviously I'd like to replace these. Do I need to start copying and
pasting chunks of header/code out of Python 2.3, or is there a better
way of doing things?

2. I need to make several C functions callable from within the Python
code. Actually these are part of a larger ADT - the opaque data being
passed in separately as a CObject - but implementing them as a Python
type was going to be more work so the ADT approach seemed like a good
idea at the time. At the moment I'm using PyMethodDef +
Py_InitModule4() to wrap those C functions as an extension and inject
it into the interpreter's module namespace; the problem I've found is
that this API is version-sensitive (e.g. 1012 in older Python vs 1013
in newer). Is there some other way to expose those C function to
Python that isn't version-sensitive? If not, what's the best way to
work with the existing API so that users don't get inflicted with
warnings or worse?


Lastly, one other question not directly related to the above: I would
like to provide a degree of insulation between unrelated scripts
(separate module namespaces in particular); and while I realise they
still provide than perfect separation, sub-interpreters do seem to be
the one and only game in town as far as in-process solutions go. Just
how badly am I going to smoke things when I try to enable the sub-
interpreter support? Should I take out house insurance, move well
clear of inhabited areas, etc? Anywhere I can get more information on
the techniques and pitfalls involved? (The Python documentation is
terribly thin on this stuff.)

Many thanks, and apologies for length,

has

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python vs pythonw

[has]

On 30 Nov, 06:16, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > New to mac.  I have leopard.  What's the difference between python and
> > pythonw?  So far (which isn't very far)  I can't tell the difference.
>
> IIUC, pythonw is linked with the WindowManager library, so it can do
> GUI operations; python can't.

True for Python 2.3.x and earlier. This limitation went away in 2.4,
however, and pythonw is now kept around solely for compatibility with
older scripts that still refer to it.


HTH

has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to detect if a image file has icc profile embeded?

[has]

On 15 Dec, 02:40, hi and hello <[EMAIL PROTECTED]> wrote:
> thx.

What OS?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to detect if a image file has icc profile embeded?

[has]

On 20 Dec, 12:09, hi and hello <[EMAIL PROTECTED]> wrote:
> On Dec 15, 7:19 pm, has <[EMAIL PROTECTED]> wrote:
>
> > On 15 Dec, 02:40, hi and hello <[EMAIL PROTECTED]> wrote:
>
> > > thx.
>
> > What OS?
>
> windows xp and linux

Not my areas of expertise, unfortunately. This might be looking into
though:

http://www.cazabon.com/pyCMS/

HTH

has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Non-web-based templating system

[has]

bruno at modulix wrote:
> Else you may want to look at:
> - http://www.python.org/doc/2.4.2/whatsnew/node5.html
> - empy : http://www.alcyone.com/pyos/empy/
> - cheetah :  http://www.cheetahtemplate.org/

Also texttemplate (one of mine):
http://freespace.virgin.net/hamish.sanderson/texttemplate.html

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Getting started with OS X Leopard

[has]

On 15 Mar, 18:05, Mark Carter <[EMAIL PROTECTED]> wrote:
> The sorts of things I want to do are:
> * copy the directory of Finder to the clipboard
> * add a new file to Finder's directory.
> * find out the size of a directory
> * open a file with Aquamacs, regardless of file type,

If you want to control desktop applications directly, that generally
means using Apple event IPC. The most popular language for application
scripting is traditionally AppleScript, but Apple event bridges exist
for other languages as well. The best of these is appscript; see my
sig for links. Some Finder scripting examples:


#!/usr/bin/python

from appscript import *
from osax import *

finder = app('Finder')
standardadditions = ScriptingAddition()

folderref = finder.Finder_windows[1].target

# set clipboard to path to front window's folder
path = folderref.get(resulttype=k.alias).path
standardadditions.set_the_clipboard_to(path)

# make new empty file in front window's folder
finder.make(new=k.file, at=folderref.get())

# get size of front window's folder
# (note: this may return k.missing_value when first run
# as Finder is sluggish at calculating folder sizes)
print folderref.size.get()

# open selected items in TextEdit
selecteditems = finder.selection.get()
finder.open(selecteditems,
using=app.application_files.ID('com.apple.textedit'))



HTH

has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Calling Mac programs from Python instead of from AppleScript

[has]

On 19 Mar, 20:10, Kevin Walzer <[EMAIL PROTECTED]> wrote:

> Take a look at appscript:
>
> http://appscript.sourceforge.net/


Also, once appscript is installed, don't forget to import it before
use:

from appscript import *
app('Maya').execute('sphere')


HTH

has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: English-like Python

[has]

On 16 Jan, 05:42, Chris Rebert  wrote:
> On Thu, Jan 15, 2009 at 5:02 PM, The Music Guy  wrote:
>
>
>
> > Just out of curiousity, have there been any attempts to make a version
> > of Python that looks like actual English text?
> > [...]
> Does the name "AppleScript" mean anything to you? ;-)

[quoting myself on the subject]

The big advantage of AppleScript syntax is that it makes it easy to
get a broad idea of what an existing AppleScript does, even if you
don't know the AppleScript language in particular or programming in
general.

The big disadvantage of AppleScript syntax is that it makes it very
difficult to form an accurate understanding of how it actually does
it. For example, is 'foo bar' a property name, a constant name, a
command name, a command name followed by a property/constant/variable
name, or something else again?

With more conventional language syntaxes, you have the opposite
situation: in order to make any sense at all of an existing script,
you first have to learn to read the syntax and know some basic
programming. OTOH, once you're past that initial hurdle, it's easier
to understand exactly what makes it tick, e.g. x.foo_bar is a property
name, :foo_bar is a constant, foo_bar() is a command, foo(bar) is a
command name followed by a variable name, and so on.

The upshot of this is that AppleScript has a lower barrier to entry
but higher cost of use compared to other languages. It's a trade-off,
but one that probably fits quite well with the needs of many
AppleScripters, who write relatively small programs on an irregular
basis. A high cost of entry will be harder to justify if you don't
actually use the language very often. OTOH, if you write large
programs on a daily basis then what matters most is long-term
productivity, and you'll recoup the time taken to learn a language
fairly quickly by comparison.

...

If you really want an end-user language that has the legibility of
already-familiar natural languages while retaining all the precision
provided by traditional programming syntax and adding a lot of much-
needed interactive help and guidance, I think the best approach would
be to go with an 'intelligent' structure editor a-la Scratch or Alice,
rather than 'dumb' character-based source code as found in Python,
AppleScript, Inform-7, C, et-al. See:

http://scratch.mit.edu/
http://www.alice.org/

If you eliminate the need for syntax to describe structure, you can
present programs in whatever way suits users best - be it English
words in coloured blocks, or traditional brackets and braces. Plus it
becomes an awful lot easier to help and correct novice users as they
put together their first programs - much as the original Mac GUI
provided much better input guidance and error prevention over previous
DOS-style command lines.

HTH

has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net

--
http://mail.python.org/mailman/listinfo/python-list

[ann] Python appscript 0.19.0 (beta 1) released

[has]

Announcing the first beta release of appscript for Python 2.x, a user-
friendly Apple event bridge that allows you to control AppleScriptable
applications using ordinary Python scripts.

Py-appscript 0.19.0 adds Python 2.6 compatibility and 64-bit support,
and cleans up the codebase and documentation in preparation for the
final 1.0 release. More information, including a list of changes from
the previous 0.18.1 distribution, can be found on the appscript
website:

http://appscript.sourceforge.net/py-appscript/index.html

File releases can be downloaded from the Python Package Index:

http://pypi.python.org/pypi/appscript

A Python 3.x-compatible version is currently under development; see
the appscript website for details.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Number of Python 3.x packages at the PyPI

[has]

On 7 Dec, 09:20, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Are there any special arrangements necessary for PyPI packages which
> > have both a Python 2.x version and a Python 3.x version?
>
> So far, no such need has been identified.

I've had to fork my appscript project's codebase in order to add
support for Python 3.x. I would like to distribute both 2.x and 3.x
versions under the same package name for obvious reasons. This isn't a
problem with eggs as the Python version number is included in each
egg's name, but what about source distributions where both filenames
are exactly the same (appscript-0.19.0.tar.gz)?

Thanks,

has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net

--
http://mail.python.org/mailman/listinfo/python-list

Re: Number of Python 3.x packages at the PyPI

[has]

On 7 Dec, 19:53, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > I've had to fork my appscript project's codebase in order to add
> > support for Python 3.x. I would like to distribute both 2.x and 3.x
> > versions under the same package name for obvious reasons. This isn't a
> > problem with eggs as the Python version number is included in each
> > egg's name, but what about source distributions where both filenames
> > are exactly the same (appscript-0.19.0.tar.gz)?
>
> I see. My initial reaction was that something should be done about this;
> please do bring this up on [EMAIL PROTECTED]

OK, will do.

> On second thought: can't you just include the source of both versions
> in a single source distribution file?

The .tar.gz distributions are built by distutils/setuptools. If I
manually combine them into a single archive, I'm guessing that
'easy_install appscript' won't know how to read that custom archive
when building and installing from source. (Which also raises a further
question: if I do eventually manage to upload both 2.x and 3.x
versions under the same PyPI entry, will easy_install know which one
to download?)

Thanks,

has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net

--
http://mail.python.org/mailman/listinfo/python-list

Re: Shutdown Mac OSX computer using python

[has]

On 8 Dec, 09:26, Håkan Hagenrud <[EMAIL PROTECTED]> wrote:
> Hello, i'm a python noob!
>
> But I would like to shutdown a 10.5.x mac computer using python (2.5.1)
>
> this is my code:
> #!/usr/bin/python
> import SystemEvents
> down = SystemEvents.Power_Suite.Power_Suite_Events()
> down.shut_down()

Avoid Python 2.x's ancient gensuitemodule/aetools modules - they've
always been flaky and/or broken on OS X and are completely hosed on
Intel Macs. For something this simple, you could just shell out to
osascript, avoiding any additional dependencies:

import subprocess
subprocess.call(['osascript', '-e',
'tell app "System Events" to shut down'])

(Note that I wouldn't recommend using 'shutdown' as Wolfgang suggests
- while it will shut down your system, it doesn't know anything about
the Mac desktop and will unceremoniously kill off all your GUI
processes without going through their normal quit procedures.)

HTH

has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net

--
http://mail.python.org/mailman/listinfo/python-list

Re: push-style templating - an xml-like way to process xhtml

[has]

On 2 Nov, 14:06, Tino Wildenhain <[EMAIL PROTECTED]> wrote:

> > An opposite approach to this form of dynamic HTML production is called
> > push-style templating, as coined by Terence Parr:
>
> Hm.
>
> "$attr.title$
> $if(attr.active)$
> $attr.submenu:menuItem()$
> $endif$"
>
> This looks ugly to me.

It also looks like an embedded mini-language to me.

At any rate, I think making a 'push/pull' distinction misses the
point.

There are basically three approaches a templating system can use:

1. embed your control logic in your presentation markup,

2. embed your presentation markup in your control logic, or

3. keep the two separate and transform the presentation markup into
some sort of DOM that can then be manipulated by the control code.

What's significant here is the division of labour within the overall
program. With the first two approaches, the templating engine handles
both presentation and control (i.e. pretty much the entire View
layer). The third approach only provides the presentation part, and
does and says nothing about how the control part is implemented. So
you can't really make a direct comparison of, say, Cheetah against
PyMeld, as they don't cover the same amount of ground. Instead, you
ought to consider how the entire View layer is put together in each
case:

- A Cheetah-based View is implemented as an HTML file with all of the
required control code embedded in it.

- A PyMeld-based View is implemented as an HTML file with id
attributes that indicate which HTML elements should be converted into
object model nodes, *plus* a Python module containing the control code
that manipulates those nodes when rendering a finished document.

Once you do compare like with like, the 'push/pull' distinction
becomes somewhat irrelevant, as the control code for a PyMeld-based
View could be pushing or it could be pulling. It's up to each
program's developer to decide which way they want to do it - and in a
proper MVC design it should always be pulling.

...

A more useful distinction to make is between templating systems that
combine appearance and control, and those that keep them separate, as
this has significant implications when considering which type of
templating system to choose, e.g.:

- how complex the interface is, e.g. Cheetah's interface is larger and
more complex than PyMeld's (even though they do the same thing), which
means a longer learning curve

- how clean the division of responsibility is, e.g. PyMeld separates
HTML markup from Python code, which provides an obvious advantage if
you've got a web designer handling one task and a Python programmer
handling the other, or a likely disadvantage if both tasks are being
handled by a relatively non-technical web designer

- how abstract the program's View implementation is, e.g. a PyMeld-
based View is more abstract than a Cheetah one, as markup and code are
physically separate and are only combined in memory, which means the
logic developer has to work harder in mentally modelling their View
layer's structure and behaviour.


HTH

has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net

--
http://mail.python.org/mailman/listinfo/python-list

Re: push-style templating - an xml-like way to process xhtml

[has]

On 3 Nov 2008, at 18:18, Glenn Linderman wrote:

> On approximately 11/3/2008 12:20 AM, came the following characters
> from the keyboard of has:
>> On 2 Nov, 14:06, Tino Wildenhain <[EMAIL PROTECTED]> wrote:
>>
>>> "$attr.title$
>>> $if(attr.active)$
>>> $attr.submenu:menuItem()$
>>> $endif$"
>>>
>>> This looks ugly to me.
>>>
>>
>> It also looks like an embedded mini-language to me.
>>
>> At any rate, I think making a 'push/pull' distinction misses the
>> point.
>>
>> There are basically three approaches a templating system can use:
>>
>> 1. embed your control logic in your presentation markup,
>>
>> 2. embed your presentation markup in your control logic, or
>>
>> 3. keep the two separate and transform the presentation markup into
>> some sort of DOM that can then be manipulated by the control code.
>> [...]
>> - A Cheetah-based View is implemented as an HTML file with all of the
>> required control code embedded in it.
>>
>> - A PyMeld-based View is implemented as an HTML file with id
>> attributes that indicate which HTML elements should be converted into
>> object model nodes, *plus* a Python module containing the control
>> code
>> that manipulates those nodes when rendering a finished document.
>>
>
> It would be nicest to keep the two separate... such that the HTML
> could be directly displayed in a browser, albeit with placeholder
> data items.

That's what DOM-style templating engines (which StringTemplate
isn't)
generally do: since they leverage the existing HTML element
structure,
the only additions to the HTML that are needed are tag attributes to
indicate which elements should be represented as DOM nodes. Most
allow
you to create a 100% valid HTML/XHTML document, complete with
placeholder text for previewing the template in a browser.


> The StringTemplate approach of nested, inherited subtemplates
> probably provides more power, and less cut-n-paste redundancy in
> development, but provides nothing for the designer to preview until
> the whole application is complete and specific data generated.

Not going to argue with that, but if you read my previous post,
StringTemplate barely came into it. IMO StringTemplate is closest to
approach 1 above, since it uses a simple embedded language to pull
data from a pre-arranged data structure. Its only similarity to
approach 3 is that the embedded language isn't powerful enough to
implement all of your View logic in, so you end up having to write
at
least some of your View logic outside of the template, using the
host
language to pull data from the Model layer and massage it into a
format suitable for consumption by a StringTemplate template.


> Unfortunately, keeping the two languages separate adds significantly
> to the burden of figuring out how to mix them together.

Some embedded templating systems involve one language; others
require
two. e.g. Cheetah-based applications involve two languages: Python
for
the Model, its own HTML-embedded language for the View. OTOH, DOM-
style templating languages should only ever require one language:
there's no logic in the HTML to begin with, so all you need is a
language to manipulate the DOM API, which might as well be the same
language as the rest of your application.


> Intermingled/embedded control and presentation (either embedded
> print statements, or templating systems), have become popular (in my
> opinion) because they do solve the problem of figuring out how do
> the mix.

Disagree. Embedded templating systems have become popular for two
reasons:

1. PHP, which, for better or worse, has raised a huge number of web
developers on its logic-in-HTML approach

2. minimal abstraction - i.e. it's easier to see how sections of
HTML
are manipulated when they are directly surrounded by the logic that
manipulates them - which makes for a lower barrier of entry.


> I took a brief look at the PyMeld approach, and it seems that the
> HTML file, while providing all the HTML syntax necessary for the
> project, leaves all decisions about what items should be replicated,
> and how and when to replicate them, to the controller.

I'm guessing you're a Mac person, since Apple are the only ones to
refer to presentation logic as the 'Controller'; web folks usually
uses the Smalltalk definition, where 'View' includes control logic
as
well as the display objects (windows, buttons, etc), and the
'Controller' layer sits on the opposite side of the Model and
handles
all input.

If you are a Mac person, you shouldn't have any trouble getting your
head around the DOM-style approach, as it's pretty much the same
approach Apple use in their Carbon 

Re: How do web templates separate content and logic?

[has]

On 29 Jun, 04:18, John Salerno <[EMAIL PROTECTED]> wrote:

> No, I don't mean presentation logic at all. I mean something along the
> lines of combining HTML (which is what I refer to as "content") and
> Python (which is what I meant by "logic").

[Note: if you're not familiar with MVC, best go read up on it now
otherwise none of this thread'll makemuch  sense.]

As Bruno says, the goal of most templating engines is to separate the
business portion of your application from the user interface portion,
basically slicing along the existing Model/View divide in the commonly
used (Model-View-Controller (MVC) application design pattern.

However, if you want a finer-grained divide between HTML markup and
presentation logic within the View layer itself, there are a few
templating engines that support this: PyMeld, HTMLTemplate (mine),
Nevow. These keep the Python-based presentation logic completely
separate from the HTML-based presentation markup, relying on simple
tag attributes to identify HTML elements can be manipulated
programmatically.

The initial learning curve's a bit steeper for these engines due to
the higher level of abstraction, but once you get your head around the
overall concept they're quite simple to use since you don't have to
learn a separate mini-language, write Python code in an HTML editor,
or anything like that.

HTH

has
--
http://mail.python.org/mailman/listinfo/python-list

Re: IM status with appscript

[has]

On 2 Apr, 10:40, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
> Oolon Colluphid wrote:
> > hi,
> > i need access to application attributes of IM (like Adium, aMsn, MS
> > Messenger) on Mac platform via appscript module.
> > once instantiated the application object with: app=app("Adium")
> > i don't know how recover information like status, and i have find no
> > references.
>
> Use the appscript examples + the OS X script-editor to see what scriptable
> properties exactly the IM-application offers.

You can also use ASDictionary (http://appscript.sourceforge.net/
tools.html) to export application dictionaries in appscript format. As
an added bonus, installing ASDictionary allows you to use appscript's
built-in help method to explore application dictionaries and object
models from the interactive python interpreter.

HTH

has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to record audio from Python on Mac?

[has]

On 9 Sep, 19:55, David Thole <[EMAIL PROTECTED]> wrote:

> Another option you could use is calling Applescript from the command
> line, to open, execute, and handle audio.

For example, using QuickTime Player (which is a buggy, poorly designed
piece of junk, but might suffice if you only need something quick-n-
dirty and aren't too fussy):

#!/usr/bin/python

from time import sleep
from appscript import *

duration = 5 # seconds
outpath = '/Users/foo/test.aiff'

qtp = app('QuickTime Player')
qtp.new_audio_recording()
qtp.documents[1].start()
sleep(duration)
qtp.documents[1].stop()
qtp.documents[1].export(to=mactypes.File(outpath), as_=k.AIFF)

Or, if you're on Leopard and want something a bit more polished, you
could look into using the new QTKit framework via PyObjC. Dunno about
Python-specific examples, but I imagine you could dig up some ObjC
code if you search around a bit and then convert that over to Python
yourself.

HTH

has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net

--
http://mail.python.org/mailman/listinfo/python-list

Re: Folder Actions on Mac OSX Leopard?

[has]

On 25 Sep, 00:30, Sean DiZazzo <[EMAIL PROTECTED]> wrote:

> I always wondered about Folder Actions...  I just tested.  You can
> have applescript call python scripts via `do shell script`.  But it
> seemed a bit flakey.

Should work in theory. For which values of flakey? e.g. Is it a
technical problem with Folder Actions, AppleScript, 'do shell script,
and/or Python, or just your AppleScript code that needs some work
(e.g. there are some common gotchas with using 'do shell script' that
often trip up AppleScript newcomers).

FWIW, I would second the suggestion to look into FSEvents as a
possible alternative to Folder Actions. There's also kqueue which is
lower level but may have/have had Python bindings already written for
it.

Alternatively, if the OP really wants to use FAs, there are a couple
of other options for that:

1. I've got a simple py2app-based application shell and an AppleScript
that automatically forwards FA events to that application - just
insert your Python code into the application shell and build it,
attach the AppleScript to some folders, and you're good to go. Email
me directly if you want a copy.

2. If you're brave, you could try using the PyOSA component on the
appscript website, which allows you to write OSA scripts in Python.
FAs will work with any kind of OSA script (.scpt files), not just
AppleScript ones. PyOSA is officially discontinued due to some
intractable limitations in its/CPython's design (specifically the
inability of an in-process Python interpreter to sandbox unrelated
scripts so that they can't interfere with each others' modules, file
handles, etc). However, it's reasonably functional and should be
usable for FAs with a little care.


HTH

has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python Evangelism

[has]

Steve Holden wrote:
> I've been thinking (and blogging) about python evangelism since PyCon,
> as a result of which I created a squidoo lens:
>

> Any suggestions for improvement?

Something that seems to be ignored in general Python evangelism is its
support for major platform-specific technologies. e.g. On OS X you've
got PyObjC, py2app and appscript, which enable Python to integrate with
or compete against ObjC and AppleScript for desktop application
development and automation. I'm sure Windows and Linux folk could name
various extensions for those platforms too.

HTH

-- 
http://mail.python.org/mailman/listinfo/python-list

download for official Python logo artwork?

[has]

Anyone know where I can find source artwork, preferably vector-based,
for python.org's new 'ying-yang' snake icon? I think it's hiding.
Thanks.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: download for official Python logo artwork?

[has]

That'll do nicely. Thanks.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Kross - Start of a Unified Scripting Approach

[has]

Jerry wrote:
> Kind of like AppleScript then?

Same fundamental goal, i.e. language-independent application scripting.
They seem to have a similar sort of approach to decoupling a scripting
language from its host application (Kross::API::ScriptManager vs. the
Open Scripting Architecture API) but a very different approach to the
intercommunication part.

Kross appears to create native language wrappers for the application's
public (C++) classes; nothing fancy, but pretty straightforward. Mac
apps use serialised procedure calls containing first-class queries and
other arguments to describe the action to perform and the application
object(s) to use in that action. A query engine in the application
framework (e.g. Cocoa Scripting) locates the actual object(s) and
applies the appropriate action to them. Much higher level of
abstraction and a lot more sophisticated, though it can be a bit tricky
for application developers to implement (for the same reason).

Plus I get the impression that Kross doesn't do interprocess yet
although it's on the cards, presumably using something like proxy
objects and dbus to provide the bridge. With Macs you only need OSA for
intraprocess communication; the Apple Event Manager, which handles the
messaging part, can pass messages between processes as well.

> Sorry, just starting to learn about some of this stuff (CLI, CLR, CIL,
> etc...) and am interested in understanding better.

As far as how the Mac does it, here's an old but good paper on the
basic principles involved if you want to know more:

http://www.cs.utexas.edu/users/wcook/papers/AppleScript/AppleScript95.pdf

I couldn't find a nice, simple overview of the Kross system. You should
be able to form a rough impression from reading through the following
links, although some better examples of calling Kexi from scripts would
help:

http://wiki.kde.org/tiki-index.php?page=kross
http://www.kexi-project.org/wiki/wikiview/index.php?Scripting
http://www.kexi-project.org/docs/cvs-api/html/namespaceKross.html

HTH

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Kross - Start of a Unified Scripting Approach

[has]

Cool. I hope I got the bits about Kross right; I only just found out
about it from seeing your post so haven't been long learning about it
(I'm a sucker for this stuff). Hopefully some nice expert can correct
anything I may've got wrong. :)

BTW, if you're curious about how Python hooks into this stuff on the
Mac, check out the appscript bridge

(shameless self-link) and PythonOSA language component
.

Appscript uses a lot of syntactic sugar to put a nice easy-to-use
syntax (which looks like OO but isn't) on top of the underlying
RPC+query mechanism; the underlying aem package gives a better idea of
how things actually work. If you don't have a Mac to play with, you
might still find the appscript and aem documentation in the source
distribution

worth reading.

The PythonOSA component provides basic OSA support
(compile/load/store/execute), allowing you to edit and run Python
scripts in Script Editor and other OSA editors and trigger them from
OSA-based application script menus and so on. There is a more advanced
but unfinished MacPythonOSA component on my site that can do message
sending and receiving as well, but it needs a bit of poking to get it
built and working at all. And I've also got an unfinished osawrapper
module that allows you to load and use OSA languages in Python.

HTH

-- 
http://mail.python.org/mailman/listinfo/python-list