date.) Or is it
an oversight in the API/UI design, in which case I'd suggest
replacing the boolean 'semi-standalone' option with a new
'dependencies' option that takes one of three values: 'all', 'semi',
or 'none'.
Ta,
has
--
http://free
about your use case. It's rare and is very
often not what people want.
How rare?
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/pythonmac-sig
rt an option that bypasses the modulegraph
component at the point where it connects to the rest of py2app,
assuming a properly-factored, maintainable design.
As to what I want: I would like a really quick, easy way to churn out
lightweight distributable applets that don't lug around stuff t
let me know and I'll
email them over.
I'm pretty sure I know why this is, I'll fix it before next release.
Cool, ta.
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/pythonmac-sig
Bob wrote:
[py2app] still does the dependency scan for third party python code
and dependent libraries/frameworks. If you want to depend on third
party stuff in site-packages, too bad, you'll have to exclude them
all individually and use --site-packages.
Why?
has
--
http://freespace.virgi
Chris Barker wrote:
I originally came down on Has' side of this debate, but now think Bob
has made the right choices, so I thought I'd add a couple comments.
First, I'm a little unclear on what exactly Has wants. Could you clarify?
Freedom, basically. It's easier to assemble
Ronald Oussoren wrote:
First, I'm a little unclear on what exactly Has wants. Could you clarify?
Freedom, basically. I
You obviously don't want it badly enough. Adding an option that will
make the application not include stuff from site-packages is not
much work, the patch is les
Hi all,
New versions of appscript, aem, osax and osaterminology released:
http://freespace.virgin.net/hamish.sanderson/appscript.html
Questions, suggestions, brickbats, etc. to the usual address.
has
--
http://freespace.virgin.net/hamish.sanderson
ing the canary-in-the-coalmine
bit, as it were - but they seemed distinctly disinterested in
rethinking its approach. Just grown too comfortable with their
monolithic tower, I think.)
The goal for 0.2.0, which I think has already been achieved (sans
documentation), was to make it better than the
nobody to upset but
yourself. Oh well, maybe in Python 3000... ;)
Cheers,
has
p.s. FWIW, I do remember proposing a versioning system in another
such conversation - can't recall where, but could probably dig it up
if you were really interested. I think it was quite a promising
concept worth
Hi all,
Quick update to appscript package posted that fixes a couple dumb
bugs and further enhances built-in help:
http://freespace.virgin.net/hamish.sanderson/appscript.html
BTW, I'd like to start aiming for the 1.0 release, so if anyone has
some time on their hands and would like to look
thout external controller
code.
This the sort of thing you mean?
class _Base:
def __call__(self, *args, **kargs):
return self.__class__(*args, **kargs)
class Foo(_Base):
pass
class Bar(_Base):
pass
f = Foo()
b = Bar()
print f, f()
print b, b()
HTH
has
--
ht
r app for
rendering application terminologies to HTML files. Both need to be
launched by the user, though ASTS can optionally be added to Login
Items to launch automatically at startup.
Hope that clarifies,
has
--
http://freespace.virgin.net/hamish.sand
be option option, though may
be better from a marketing PoV to use a more high-profile, visible
location like /Applications/Appscript (could maybe stick the
appscript docs in there too).
HTH
has
p.s. Incidentally, if we could think of some way to make the
appscript documentation show up in Help Ce
//freespace.virgin.net/hamish.sanderson/appscript.html>).
BTW, the second option could be extended to create a general-purpose
system for forwarding Folder Actions to user-installed shell scripts
of any kind. If anyone is interested in writing such a thing, email
me and I&#x
fbartlet wrote:
I have a mess of VBA and AppleScript scripts I wrote to automate
Word & ChemDraw tasks. Now that everyone who needs this stuff has
access to OS X, I thought I might try Python to make some
improvements I've been asked for and which VBA and AppleScript don't
seem
ted an update to its plain text-oriented
sibling, texttemplate
<http://freespace.virgin.net/hamish.sanderson/texttemplate.html> (the
documentation isn't quite done yet, but the module itself should be
quite usable).
Cheers,
has
--
http://freespace.virgin.net/hamish.sanderson/
___
g?
Thanks,
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
Hey all,
Just reading up on Automator development
<http://developer.apple.com/macosx/tiger/automator.html> and
wondering if the MacPython community (or anyone in it) has any plans
to 0wnz0r it yet? Like providing a 'Python Automator Action' template
for Xcode, flogging a n
gh.
I'm sure if someone provides a nice, easy-to-use infrastructure then
other folks will be able to evangelise it.
(Python as the de-facto OS X Scripting Language... Mmmm)
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG mailli
ment that.
Would this solve the problem (and at what cost)?
Any other options open to me? I can solve the ASTS problem by having
a 10.3 build included in the 10.3 binary installer, but it does put a
bit of a damper on me other ambitions until I can rai
g that potential audience to AppleScript - a far
inferior platform in technical terms, but one which knows a thing or
two about presenting itself in a newbie-friendly form.
It's a question of marketing really: what type(s) of audience do you
wish to promote Python to, and what needs to be do
f play re. using Cocoa/ObjC to send
AEs to other applications?
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
more
attractive to them than the competition?
Hey, if nothing else p'rhaps some of them newcomers'll be Babes...
Rotten job, I know; but gotta do it for the babes, man. ;)
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
brary should feel a certain, shall we say, 'moral
obligation' to respect and uphold that position, even if it's not
something they have an ideological interest in themselves.
Cheers,
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Py
o get the creative juices woken up;
prehaps someone with a seed copy'll decide to pursue it a bit further
in private just now, or we can take it to the next stage on-list as
Apple releases more technical info into public.
Just never say never. (Hey, was a time when you and me d
stick at, it might make a nice opportunity for (Mac)Python to promote
itself if somebody with a bit of spare time and some prior webapp
experience were interested.
Cheers,
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist
for MacPython to do interesting things.
Cheers,
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
Hi all,
Updates to appscript, aem and osaterminology posted:
http://freespace.virgin.net/hamish.sanderson/appscript.html
Cheers,
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http
ew the idea into the wild here. And even if nobody here
picks it up themselves, I'm sure some folks subscribe to other OS X
dev lists as well, and might like to promote Python/PyObjC/appscript
as a solution if/when the topic arises there.
Cheers,
has
--
http://fr
e, None)[1] \
.CFURLCopyFileSystemPath(kCFURLPOSIXPathStyle).toPython()
print path
LaunchServices is due for inclusion in MacPython 2.4. Meantime, you
can find it on SourceForge CVS or just use the pre-packaged copy from
my site:
http://freespace.virgin.net/hamish.sanderson/appscript.ht
Read Roberts wrote:
Using the package pointed to by Bob Ippolito, I
find I cannot use the import statement suggested
by has hengist, although it may work with the
package that he points to.
My version exported everything from package's main namespace,
allowing one to write:
i
biter of good
taste... :p
Well, for better or worse, I'll assume now it's Just The Way Things
Are. Off to do a bunch of quick updates on all my own stuff...
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist -
appy to build a 10.2 version though if you can tell me how
(given I'm not familiar with the CVS or making installers).
has
p.s. I've submitted patches for Carbon.AE [1090958] and
OSATerminology [1113328]; don't suppose you know if/when they'll make
it into 2.4, and from th
parked fairly firmly upon his foot at the moment.
Curse these inconvenient "real lives" that some people seem to have.
However, I do have to draw the line at learning bgen myself, as we'd
be onto OS XVI by the time I've mastered it. :p
has ("It rewrites the patches or
s, 'CMYK')]
print bool2cm0k([True, False, False, True]) # --> C00K
print cm0k2bool('CM0K') # --> [True, True, False, True]
HTH
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
e not grokked
yet, but I can see several that will be needed to build a
comprehensively featured alternative to Cocoa's wimpy NSAppleScript.
- Has anyone tested or used the OSA package, written any example
scripts, etc. yet? Or am I the first?
Ta,
has
--
http://freespace.virgin.net/hamish.sand
s wart would be good.
BTW, there's already a couple patches filed on this:
http://sourceforge.net/tracker/index.php?func=detail&aid=1056561&group_id=5470&atid=305470
http://sourceforge.net/tracker/index.php?func=detail&aid=1038911&group_id=5470&atid=305470
Cheers,
e
BB too and tell folk not to use it to build new apps any more. This
should be of relatively little inconvenience to users.)
BTW, what about the sourceforge patches? Would one or both of those
solve the problem any better?
Cheers,
has
--
http://freespace.virgin.net/hamish.sand
to fix the GUI frameworks because
that would solve other people's problems too (outside the Python
world).
Obviously. Though I think even Jack might struggle at trying to fix
Apple itself. :)
has
--
http://freespace.virgin.net/hamish.sanderson/
__
Bob wrote:
I'm not sure who maintain the pythonmac wiki, but it's been
spammed. What a pain in the *&%*^!
Unfortunately I do.. but I don't really have time to deal with the
spam. It has a defense in that existing pages can't be edited with
too many URLs, but creating n
7;t be why OSA.so is missing about half the OSA API, would
it? (I've also found 2 broken functions so far.) I'd fill in the gaps
by hand and submit a full patch, only there doesn't seem much point
if it then needs rewritten again to bgenify it.
gensuitemodule has some pretty
thing
involving chainsaws might be nice) then perhaps you'll not be too
sorry to see them go... >;)
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
minute UI when
they need it - or you keep the hell out their way so you don't hack
them off. Because if you do hack them off, or they think they can get
better help by moving to another platform, then another platform is
just where they're gonna go.
And that's what the [Mac]Pyt
nd the result is systems
that only their existing long-time users want to use because the cost
of mastering one of these monsters has grown so high as to deter
newcomers. Who then turn to simpler, less powerful systems, master
those, and then complain about the lack of features until they too
rt; i.e.
a waste of time and energy.
Folk seem to acknowledge there's a constant underlying problem at
work, so why don't they spend more time trying to put that right
instead of reinventing the same old mistakes as before? It should be
a wonderfully rich and tasty problem
I think Apple were definitely onto something with these:
it's all about where you make the split, and finding the right
point makes the difference between moving Mohammed or moving the
mountain.
And we all know how well Apple has been implementing Apple Events in
its more recent application
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://freespace.virgin.net/hamish.sanderson/
Bob wrote:
Announcing the first release of the all-in-one Appscript Installer
package for Mac OS X 10.3.
Finally! :)
You can thank Nick, not me - the installer is his work. :)
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG
Hi folks,
I'm not really up on these APIs nor their Python wrappers, but I
suspect this stuff is broke:
First try:
import Carbon.CF as CF
f =
CF.CFURLCreateFromFileSystemRepresentation('file://localhost/Users/has/',
True)
print f #
print `f.CFURLGetString().toPython()` #
u
t generate some damn test
suites to prove it?;p)
use PyObjC and NSURL instead, those work.
Introduces a big fat third-party dependency though, something I'm
trying to avoid here.
Why haven't you upgraded to 2.3.5 (not that I think it would help)?
I'm sure it's
his
halfway house first while all the kinks are worked out (e.g. OSA.so).
Might be worth exploring to see what sort of infrastructure it would
require to run.
HTH
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
There are a select few Win32-specific modules in the
core, but most of the things you actually need are elsewhere.
So what would it take to get MacPython from its current state into
that position?
has
--
http://freespace.virgin.net/hamish.sanderson/
__
ts.
Even if there isn't, leaving broken stuff in the core library isn't
doing any favours. If it's recoverable, why not punt it into MacAll
where its failings can be addressed more easily? If it's terminal,
put it on the road to disposal. I don't have a problem t
xtension to the standard library
when that extension is not only untested but _already known_ to be
broken?
2. What's the point of me going to the effort of writing a brand new
fully functioning OSA.so extension if it has to play perpetual third
fiddle to some
known-to-be-broken-but-inviolabl
them in stone that's the trouble.
2. What's the point of me going to the effort of writing a brand
new fully functioning OSA.so extension if it has to play perpetual
third fiddle to some
known-to-be-broken-but-inviolable-now-as-it's-in-the-standard-library-neener-neener
versio
iled on that as well, but I can't recall hearing
anything about it.
Nevertheless, 'save' commands have always traditionally accepted a
file handle specifying an as-yet non-existent file for saving
documents to a new file, and ignoring periodic Apple incompetence I
don't believe t
why nobody wants to come round and visit any more. It does a
disservice to Python's reputation, its developers and its end-users,
and it's the sort of behaviour that'll eventually turn folk off
Python and onto something else.
My point? Doing a job badly is the _worst_ thing po
y
really bad taste in your mouth, plus a wriggling sensation you don't
even want to think about. Apple are just a bunch of classy tarts only
interested in my wallet, but I expect better from the honest and
hardworking artisans behind MacPython. And I expect the folk at the
top - the ones direc
Python and Mac-specific
extensions without changing any of the content or behaviour, because
Loose Coupling = Better. I know Jack's mulled over this idea of
repackaging MacPython (though I dunno to what extent) and I
personally believe it has serious merit, even if this thread does
seem to keep
and my C isn't good enough anyway.
I am still interested in producing a Python OSA component, hopefully
with the OSA module, but unfortunately it is a lot more work than I
have free time for at the moment. I lost my drive to work on it when it
became clear that HAS was far more energetic in th
he whole Mac file type muddle could
be reduced - at least at the end-user level - to high-level,
user-friendly FileURL and Alias classes. The only questions are: can
we get there safely, and if so, how?
Cheers,
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Hi,
Reading up on embedding the Python interpreter, and
<http://www.python.org/doc/2.4/ext/embedding.html> says to use
PyMac_Initialize() instead of Py_Initialize() to initialise it on
Mac; however it doesn't appear to be declared. Is this a typo in the
Python docs?
Remember that while appscript uses an OO-like syntax for convenience
it's not OO. It's a simple relational query builder plus RPC wrapper.
Ditto AppleScript, except it has an even thicker layer of syntactic
and semantic sugar on top. The downside of this is that it causes
quite a b
around to explain it, let alone fix it.
The 'syntax problem' I mention is common to both AppleScript and
appscript and has _nothing_ to do with individual applications' Apple
event support.
The problem is that both wrap Apple events in a very OO-like syntax
which is easy to use and
related ones before
asking them. Learning how to ask questions clearly and precisely is
something everyone has to learn. It's not like there's any shortage
of vague, confused and downright undecipherable questions already
being asked on AS lists.
(Somehow I don't see Shane Stanley
quate documentation; the only solution for that is
for individual users to petition those applications' developers to
fix these problems. File bug reports, file feature requests, have all
your fellow users get onto them too.
The one thing appscript does give you is a decent language to
ously, but hopefully over time it'll grow into an
important and valuable resource for application scripters. Please contribute!
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.
gards,
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
n the one you expected, it
>should probably prevent the component from being initialized -- since you need
>the aem extension to be present.
Good advice, though I'm not sufficiently up on C programming or OS internals to
have a clue how to do it. Any pointers?
Many thanks,
nt Manager - not Apple events - to communicate with language
components, so the MacPythonOSA component would need to handle each OSA call,
stuff its arguments into an IPC message, send the message to the script daemon
to process and wait for its response. (This is just the easy bit, btw.)
- In
nd wait for its response. (This is just the easy
>>bit, btw.)
>>
>>- In addition, the daemon also has to be able to send various messages to the
>>OSA component to be handled there concurrently: CallActiveProc,
>>CreateAppleEvent, SendAppleEvent, RedispatchAppleEven
>
>So put something in the script's namespace that's called "log" and make it do
>what log does.
Thought of that, but 'print' feels natural from the end-user's POV and 'log'
does not. Duplicating existing functionality simply to avoid doing a bit o
Hi all,
Just wondering if there's anything in MacPython for converting HFS paths to
POSIX and vice-versa, or is my memory playing tricks on me? If not, does anyone
have some code they don't mind sharing?
Ta,
has
--
http://freespace.virgin.net/hamish
r something that converts a string with colons
>to one with slashes and back; or something that converts from a slashpath
>into FSRefs or FSSpecs?
The former; e.g. 'Mac HD:Users:has:' to '/Users/has' and back.
...
Larry Meyn wrote:
>Jack helped me out awhile back in
ly. In the meantime, I believe the
alternate form works correctly:
app('System Events').click(app('System
Events').application_processes['OSXvnc'].windows[1].buttons[4])
HTH
has
http://freespace.virgin.net/hamish.sanderson/
___
ill decrease with time.
> >> (Although I think KaleidaGraph may never get upgraded scripting
> >> abilities.)
> >
> > Does it really take HFS paths as strings, and not FSSpec? Even if it
> > did, wouldn't a FSSpec be coerced to a HFS path string along the
t the top level of plat-mac/Carbon.
This means scripts written on Python 2.3 break on 2.4 and vice-versa when
importing any of these modules. What's the fix?
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - Pyt
nchServices
I figured that, but I'd rather hoped a more elegant solution might be
forthcoming at source. Is there a good reason why they couldn't both agree on a
common location, or at least provide the relevant aliases in 2.4 to preserve
Python's much-vaunted back
Py23Compat install into plat-mac/Carbon might not have been out of the
question. I don't suppose Apple would be interested in including these modules
(in the correct location) in future Tiger updates...?
Cheers,
has
--
http://freespace.virgin.net/hamish.sanderson/
___
support one major OS/Python version behind
the current release while still in development then you're doing pretty well.
HTH
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.p
situation either - two AEDesc types is really one too
many.
Is there an 'official' way to deal with this sort of problem? If not, what
other solutions are available to me, and what are the pros and cons of each?
Thanks,
has
--
http
nse as Python itself.
>
>Well the PSF license has certain issues in that it's only really meant to be
>used by the PSF for software wholly owned by the PSF.
>However, using MIT/BSD style license is equivalent to using PSF since they
>are compatib
'private' email address
solely for use with your PayPal account, and put a filter on your inbox that
automatically marks as spam any message claiming to be from PayPal that arrives
at any other address.
HTH
has
--
http://freespace.virgin.net/hamish.sanderson/
_
and have it import
the appropriate one according to OS version, or is there a better/more
elegant/official way of doing it?
Many thanks,
has
[1] This is a modified version of OSATerminology.so that's bundled in the
osaterminology package, btw; I don't use the original copy in lib
y/Frameworks/Python.framework/Versions/2.3/Resources/Python.app/Contents/MacOS/Python
can't open library: /usr/lib/libmx.A.dylib (No such file or directory, errno
= 2)
Any ideas? (Source and binary are at
<http://freespace.virgin.net/hamish.sanderson/osat.dmg.gz> if it's
errno = 2)
>
>[...] Switching to gcc 3.3 will make this problem go away.
Cool, ta. Next dumb question: how do I tell Distutils (Python 2.4.1 on OS
10.4.1) to use gcc 3.3 instead of 4.0?
Thanks,
has
--
http://freespace.virgin.net/hamish.sanderson/
___
x27;s time to give up.
Not a big problem; don't supply Jaguar binaries as it is. More interested in
Panther/Tiger portability. (I don't have a copy of Panther to test on myself.)
Will extensions built on 10.4 work on 10.3, or will I have to create separate
OS-specific bin
he easiest thing
would be to put the Tiger-only code in a separate file and build that on Tiger,
and build the remainder on an older OS as before; then have osaterminology
import or ignore the Tiger-only extension at runtime as appropriate.
Many thank
ppropriate.
>
>Yeah, the "easiest" thing is basically to do that, or to build an entirely
>separate version for users with Tiger.
Will do. Much thanks for your patient advice.
has
--
http://freespace.virgin.net/hamish.sanderson/
_
Hi all,
Apropos to last thread, what's the best way to check Mac OS version from Python
at runtime?
Thanks,
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/ma
Hi folks,
One more question: am I right in thinking that extension binaries aren't
portable between major Python versions, e.g. an .so file built under Python 2.3
won't work on Python 2.4 and vice-versa?
Thanks,
has
--
http://freespace.virgin.net/hamish
e between major Python versions on
>ANY platform.
Thought as much, just couldn't seem to find confirmation in the Python docs.
Thanks,
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
it do more?
OK, back to you guys now... :)
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
for Python 2.3.0
>
>3 can be dealt with by a single package, built on Mac OS X 10.3 with
>bdist_mpkg installed for Python 2.4.1.
I'd better point out - as much for Nick's benefit as anyone's - that bdist_mpkg
currently isn't suitable for building an appscript installer
']
itunes.playlists['library'].tracks.filter(its.database_ID ==
tracktodelete.database_ID.get()).delete()
If you're deleting multiple tracks, you'll have to iterate over a list of
database IDs and delete the tracks one at a time.
HTH
has
--
http://freespace.virgin.net/hamish.sanderson/
___
I have is an
>instance of FSRef.
As Bob says, you want to create a new Alias out of the alias file's alis
resource, e.g.:
from Carbon.File import FSRef, Alias
from Carbon.Res import *
f = FSRef("/Users/has/a 'broken' Finder alias file")
resfile = FSOpenResFile(f, 1
d hack the C
>code it spits out directly, but unless it's done with bgen, it's not going to
>end up in Python CVS.
I blame Joseph Heller myself.
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - Py
tribution could be quietly
deprecated; a lot of it's just deadweight anyway. I can't see them being thrown
out before Python 3.0, but we can discourage their use in favour of
alternatives like CarbonX and PyObjC.
has
--
http://freespace.virgin.net/hamish.sanderson/
ll, but with
>a more pythonic interface. That would require more work because you'd have to
>make up a nice interface and document it.
I'd suggest writing any new OO wrappers as Python classes. Less work than doing
it in C, and it'd make it much quicker and e
1 - 100 of 415 matches
Mail list logo
