Re: [Pythonmac-SIG] findertools.launch reports no eligible process
On 14 Jun, 2007, at 22:42, Ronald Oussoren wrote: On Jun 14, 2007, at 1:21 PM, Nicholas Riley wrote: On Thu, Jun 14, 2007 at 01:16:08PM -0700, Christopher Barker wrote: However, if was nice to have some stuff without any external dependencies -- is there a lightweight way to do just Easy Dialogs, without all of PyObjC? It shouldn't be hard to simply wrap a Cocoa EasyDialogs implementation in C to construct a traditional Python module, but it make ssense to wait and see how much of Carbon is no longer going to be supported in 64-bit on Leopard (probably the WWDC attendees find out today but it's NDA'd). Cocoa doesn't have a generic API that matches that of EasyDialogs as much as Carbon does. The WWDC attendees (me included) already know but as you say that info is under NDA ;-). But luckily the situation is explained on a mailinglist: http://lists.apple.com/archives/Carbon-dev/2007/Jun/msg00260.html The summary: no 64-bit Carbon GUI libraries. I haven't even tried to compile Python's Carbon wrapper in 64-bit mode, I'd be surprised if they compiled cleanly because Apple has done some serious spring- cleaning in 64-bit mode. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports no eligible process
Ronald Oussoren wrote: On 14 Jun, 2007, at 22:42, Ronald Oussoren wrote: On Jun 14, 2007, at 1:21 PM, Nicholas Riley wrote: On Thu, Jun 14, 2007 at 01:16:08PM -0700, Christopher Barker wrote: However, if was nice to have some stuff without any external dependencies -- is there a lightweight way to do just Easy Dialogs, without all of PyObjC? It shouldn't be hard to simply wrap a Cocoa EasyDialogs implementation in C to construct a traditional Python module, but it make ssense to wait and see how much of Carbon is no longer going to be supported in 64-bit on Leopard (probably the WWDC attendees find out today but it's NDA'd). Cocoa doesn't have a generic API that matches that of EasyDialogs as much as Carbon does. The WWDC attendees (me included) already know but as you say that info is under NDA ;-). But luckily the situation is explained on a mailinglist: http://lists.apple.com/archives/Carbon-dev/2007/Jun/msg00260.html The summary: no 64-bit Carbon GUI libraries. I haven't even tried to compile Python's Carbon wrapper in 64-bit mode, I'd be surprised if they compiled cleanly because Apple has done some serious spring-cleaning in 64-bit mode. Ronald A couple of questions: 1. Will applications that are 32 bit have any problems running under Leopard? 2. Would Python have to be specifically compiled as 64-bit to support PyObjC, or would 32-bit Python be OK? --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports no eligible process
I wrote: I agree that ED should stay, at least for now. I'll see about submitting a patch in the next few days - it won't be a big job to fix. Patch is here: http://sourceforge.net/tracker/index.php? func=detailaid=1737832group_id=5470atid=305470 has -- http://appscript.sourceforge.net http://rb-appscript.rubyforge.org http://appscript.sourceforge.net/objc-appscript.html ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports no eligible process
On 12 Jun 2007, at 16:17, Jack Jansen wrote: You missed EasyDialogs, which is also the one we may want to keep. It uses aepack for the file dialogs. Yep, didn't notice the 'import' statement buried down in the body there. I agree that ED should stay, at least for now. I'll see about submitting a patch in the next few days - it won't be a big job to fix. In the longer term, EasyDialogs definitely needs to be substantially rewritten or removed sometime within the next couple of major Python releases as it lacks things like Unicode and long string support and uses some ancient APIs that almost certainly won't exist on 64-bit. The file dialog APIs might be okay, and I think CFUserNotification could replace most of the rest with minimal effort - the only one that might need a bit more work is the progress dialog. Also, if ED does end up getting rewritten, there may be an argument for redesigning the API, which is pretty crusty, doesn't follow standard conventions, and probably doesn't take full advantage of the functionality provided by the more modern OS X APIs. Not much point doing anything until Leopard is out though. has -- http://appscript.sourceforge.net http://rb-appscript.rubyforge.org http://appscript.sourceforge.net/objc-appscript.html ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports no eligible process
has wrote: In the longer term, EasyDialogs definitely needs to be substantially rewritten shouldn't EasyDialogs be re-written to use Cocoa? Or would that require the full pyObjC package -- speaking of which is that ever going to be part of the 'standard MacPython package? I suppose it could use wxPython instead -- Apple has delivered wxPython by default in the past -- I don't know if they are committed to doing so in the future. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports no eligible process
On Thursday, June 14, 2007, at 06:57PM, Christopher Barker [EMAIL PROTECTED] wrote: has wrote: In the longer term, EasyDialogs definitely needs to be substantially rewritten shouldn't EasyDialogs be re-written to use Cocoa? Or would that require the full pyObjC package -- speaking of which is that ever going to be part of the 'standard MacPython package? That's unlikely, I have no plans for trying to get pyobjc in the stdlib. Having it outside of the stdlib has one pretty major advantage: not being restricted by the Python release cycle and hence having the possibility of closely tracking whatever Apple is doing. In a hypothetical world where pyobjc is part of the stdlib you'd have to wait until Python 2.6 before getting access to the frameworks that Apple will introduce in Leopard. It might be useful to make MacPython a kitchensink distribution of Python for Mac OSX instead of just the standard library, but that would require some people that want to invest into building this. It should also be more than an .mpkg that installs Python, PyObjC, appscript, wxPython and whatever else is deemed useful, a MacPython that's separate from the standard python.org distribution should strive for being the best possible Python environment for the Mac (including a proper IDE, software management tools, ...). Building such a beast is certainly possible, but takes a lot of developer time and is hence rather unlikely to happen unless someone has too much money and wants to fund this :-) I suppose it could use wxPython instead -- Apple has delivered wxPython by default in the past -- I don't know if they are committed to doing so in the future. I have no idea what Apple plans to do, but if you're using Apple's build of Python you should consider PyObjC as well (wink, wink). Ronald -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports no eligible process
Ronald Oussoren wrote: That's unlikely, I have no plans for trying to get pyobjc in the stdlib. Fair enough -- I don't really like platform dependent stuff in the standard lib anyway. It might be useful to make MacPython a kitchensink distribution of Python for Mac OSX instead of just the standard library, a MacPython that's separate from the standard python.org distribution should strive for being the best possible Python environment for the Mac (including a proper IDE, software management tools, ...). Well, sure, but wouldn't an uber-package be useful anyway? As you said, I don't see anyone clambering to build the full enchilada. I have no idea what Apple plans to do, but if you're using Apple's build of Python you should consider PyObjC as well (wink, wink). Ah, I didn't know if had been included -- good idea, I think. Build Easy-Dialogs with PyObjC, and people will have it out of the box, or can install PyObj to get it. However, if was nice to have some stuff without any external dependencies -- is there a lightweight way to do just Easy Dialogs, without all of PyObjC? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports no eligible process
On Thu, Jun 14, 2007 at 01:16:08PM -0700, Christopher Barker wrote: However, if was nice to have some stuff without any external dependencies -- is there a lightweight way to do just Easy Dialogs, without all of PyObjC? It shouldn't be hard to simply wrap a Cocoa EasyDialogs implementation in C to construct a traditional Python module, but it make ssense to wait and see how much of Carbon is no longer going to be supported in 64-bit on Leopard (probably the WWDC attendees find out today but it's NDA'd). Cocoa doesn't have a generic API that matches that of EasyDialogs as much as Carbon does. -- Nicholas Riley [EMAIL PROTECTED] | http://www.uiuc.edu/ph/www/njriley ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports no eligible process
On Jun 14, 2007, at 1:21 PM, Nicholas Riley wrote: On Thu, Jun 14, 2007 at 01:16:08PM -0700, Christopher Barker wrote: However, if was nice to have some stuff without any external dependencies -- is there a lightweight way to do just Easy Dialogs, without all of PyObjC? It shouldn't be hard to simply wrap a Cocoa EasyDialogs implementation in C to construct a traditional Python module, but it make ssense to wait and see how much of Carbon is no longer going to be supported in 64-bit on Leopard (probably the WWDC attendees find out today but it's NDA'd). Cocoa doesn't have a generic API that matches that of EasyDialogs as much as Carbon does. The WWDC attendees (me included) already know but as you say that info is under NDA ;-). Ronald -- Nicholas Riley [EMAIL PROTECTED] | http://www.uiuc.edu/ph/www/njriley ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports no eligible process
Ronald Oussoren wrote: IIRC at least one of the ae* modules seems to have assumptions on the byteorder engrained into its design. Fixing that may well be possible but there doesn't seem to be anyone around that both wants to have these modules fixed and has enough time (or money) to actually get this done. Not just that - there's other modernisation work required too. All of which would be a complete waste of time and effort since nobody uses these modules any more. Anyway, the items to remove from plat-mac are: aepack aetools aetypes findertools gensuitemodule lib_scriptpackages MiniAEFrame You can also remove OSATerminology from lib-dynload - it's only used by gensuitemodule and will have to go sooner or later anyway. has -- http://appscript.sourceforge.net http://rb-appscript.rubyforge.org http://appscript.sourceforge.net/objc-appscript.html ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports no eligible process
On 12-jun-2007, at 16:07, has wrote: Not just that - there's other modernisation work required too. All of which would be a complete waste of time and effort since nobody uses these modules any more. Anyway, the items to remove from plat-mac are: aepack aetools aetypes findertools gensuitemodule lib_scriptpackages MiniAEFrame You missed EasyDialogs, which is also the one we may want to keep. It uses aepack for the file dialogs. -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports no eligible process
On 10 Jun 2007, at 18:19, Ronald Oussoren wrote: I'm more tempted to remove aetools in 2.6 if it cannot be fixed with a small amount of work. Leaving code that is fundamentally broken is just lame. Fine by me - I'm all for an aggressive houseclean, as you know. I've no interest in fixing these modules, or even vetting them to see what needs done. Like I say, if users actually cared about this stuff, they'd have been complaining/doing something about it by now. has -- http://appscript.sourceforge.net http://rb-appscript.rubyforge.org http://appscript.sourceforge.net/objc-appscript.html ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports no eligible process
On 11-jun-2007, at 14:30, has wrote: On 10 Jun 2007, at 18:19, Ronald Oussoren wrote: I'm more tempted to remove aetools in 2.6 if it cannot be fixed with a small amount of work. Leaving code that is fundamentally broken is just lame. Fine by me - I'm all for an aggressive houseclean, as you know. I've no interest in fixing these modules, or even vetting them to see what needs done. Like I say, if users actually cared about this stuff, they'd have been complaining/doing something about it by now. Then please zap it now (at least in the trunk) so that problems show up sooner rather than later. I'm reasonably sure that there's various things that depend on it (possibly indirectly), these would need fixing then. At least if the module is scrapped now we should find out what breaks, -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports no eligible process
On 8 Jun, 2007, at 14:34, Jack Jansen wrote:
On 8-Jun-2007, at 13:19 , has wrote:
You might add a note that since findertools uses aetools which is
[over]due for deprecation, findertools should be deprecated as well.
[...]
Or you can do it with appscript if you prefer:
from appscript import *
from mactypes import Alias
path = '/Users/drew/Documents'
app('Finder').items[Alias(path)].open()
Problem with deprecating aetools is that there is a truckload of
modules that depend on it, findertools among them. I'd love to
rewrite them to use appscript, and it wouldn't even be all that
much work, but I simply don't have the time (and probably won't
have the time in the coming few years).
IIRC at least one of the ae* modules seems to have assumptions on the
byteorder engrained into its design. Fixing that may well be
possible but there doesn't seem to be anyone around that both wants
to have these modules fixed and has enough time (or money) to
actually get this done.
I'm pretty sure that I the current version of argvemulator no longer
depends on aetools because I looked at the ae* code and decided it
wasn't worth my time to try to fix these.
This doesn't mean ae* is crappy code, just that an important design
assumption changed.
Ronald
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma
Goldman
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
smime.p7s
Description: S/MIME cryptographic signature
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports no eligible process
On 9 Jun, 2007, at 2:55, has wrote: On 8 Jun 2007, at 22:34, Jack Jansen wrote: Problem with deprecating aetools is that there is a truckload of modules that depend on it, findertools among them. Which ones? Apart from the other OSA modules (which should also be deprecated), findertools is the only standard library module that I can see. (argvemulator used to use it, but has already been fixed.) Bear in mind that aetools is completely broken on i386. If there were really a need for it, there'd have been constant howls of complaint over the last year. Python 3.0 is coming. 64-bit support is needed. Able bodies are in limited supply. Dumping deadweight will improve the Python distribution and reduce the amount of upgrade/maintenance work that needs to be done. It is the best and easiest way forward and timing it right - i.e. deprecated in 2.6, removed in Python 3.0 - will minimise the workload for maintainers and the disruption to users. I'm more tempted to remove aetools in 2.6 if it cannot be fixed with a small amount of work. Leaving code that is fundamentally broken is just lame. Ronald has -- http://appscript.sourceforge.net http://rb-appscript.rubyforge.org http://appscript.sourceforge.net/objc-appscript.html ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports no eligible process
On 8 Jun 2007, at 22:34, Jack Jansen wrote: Problem with deprecating aetools is that there is a truckload of modules that depend on it, findertools among them. Which ones? Apart from the other OSA modules (which should also be deprecated), findertools is the only standard library module that I can see. (argvemulator used to use it, but has already been fixed.) Bear in mind that aetools is completely broken on i386. If there were really a need for it, there'd have been constant howls of complaint over the last year. Python 3.0 is coming. 64-bit support is needed. Able bodies are in limited supply. Dumping deadweight will improve the Python distribution and reduce the amount of upgrade/maintenance work that needs to be done. It is the best and easiest way forward and timing it right - i.e. deprecated in 2.6, removed in Python 3.0 - will minimise the workload for maintainers and the disruption to users. has -- http://appscript.sourceforge.net http://rb-appscript.rubyforge.org http://appscript.sourceforge.net/objc-appscript.html ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] findertools.launch reports no eligible process
hi there, i was wondering if anyone else has seen this behavior with the findertools.launch() function. the docs indicate that when given a pathname, launch(path) will launch a Finder window with that path. but when i try to launch any valid path i get this error: os.path.exists(/Users/drew/Documents) True findertools.launch(/Users/drew/Documents) Traceback (most recent call last): File stdin, line 1, in ? File /Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/plat-mac/findertools.py, line 45, in launch return finder.open(fss) File /Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/plat-mac/lib-scriptpackages/Finder/Standard_Suite.py, line 248, in open _arguments, _attributes) File /Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/plat-mac/aetools.py, line 226, in send return self.sendevent(self.newevent(code, subcode, parameters, attributes)) File /Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/plat-mac/aetools.py, line 220, in sendevent self.send_timeout) MacOS.Error: (-600, 'no eligible process with specified descriptor') i get the same error across reboots, on real hardware (x86) or a VM; from a Terminal window or IDLE; with directories or files or applications, etc. -- all this -600 error; (if i specify an invalid path i do get a file not found error.) i mostly come from windows land (and basically looking for a stand-in for ShellExecute), so if i'm doing something horribly wrong please let me know :) i'm using OS X 10.4.9 and MacPython 2.4.4 and can't think of anything unusual that might be causing it. (killing the finder and restarting it also does not help; the process is certainly running.) thanks! drew ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports no eligible process
On Friday, June 08, 2007, at 09:55AM, Drew Houston [EMAIL PROTECTED] wrote: hi there, i was wondering if anyone else has seen this behavior with the findertools.launch() function. the docs indicate that when given a pathname, launch(path) will launch a Finder window with that path. but when i try to launch any valid path i get this error: Please file a bug at http://sourceforge.net/projects/python, this seems to be yet another byteorder bug in the OSA support in the core python distribution. Findertools seem to work correcty on PPC, but fails on Intel systems. The session below forces a run of the PPC version of python on my macbook: [EMAIL PROTECTED] /usr/libexec/oah/translate /Library/Frameworks/Python.framework/Versions/Current/Resources/Python.app/Contents/MacOS/Python Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type help, copyright, credits or license for more information. import sys sys.byteorder 'big' import findertools findertools.launch(/tmp) This does indeed open the /tmp folder in the finder. BTW. appscript (http://appscript.sourceforge.net/) is in general a much more useful OSA/AppleScript interface for use in python. os.path.exists(/Users/drew/Documents) True findertools.launch(/Users/drew/Documents) Traceback (most recent call last): File stdin, line 1, in ? File /Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/plat-mac/findertools.py, line 45, in launch return finder.open(fss) File /Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/plat-mac/lib-scriptpackages/Finder/Standard_Suite.py, line 248, in open _arguments, _attributes) File /Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/plat-mac/aetools.py, line 226, in send return self.sendevent(self.newevent(code, subcode, parameters, attributes)) File /Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/plat-mac/aetools.py, line 220, in sendevent self.send_timeout) MacOS.Error: (-600, 'no eligible process with specified descriptor') i get the same error across reboots, on real hardware (x86) or a VM; from a Terminal window or IDLE; with directories or files or applications, etc. -- all this -600 error; (if i specify an invalid path i do get a file not found error.) i mostly come from windows land (and basically looking for a stand-in for ShellExecute), so if i'm doing something horribly wrong please let me know :) i'm using OS X 10.4.9 and MacPython 2.4.4 and can't think of anything unusual that might be causing it. (killing the finder and restarting it also does not help; the process is certainly running.) thanks! drew ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports no eligible process
Ronald Oussoren wrote:
i was wondering if anyone else has seen this behavior with the
findertools.launch() function. the docs indicate that when given a
pathname, launch(path) will launch a Finder window with that path.
but
when i try to launch any valid path i get this error:
Please file a bug at http://sourceforge.net/projects/python, this
seems to be yet another byteorder bug in the OSA support in the
core python distribution.
You might add a note that since findertools uses aetools which is
[over]due for deprecation, findertools should be deprecated as well.
Anyway, simplest solution here is:
import subprocess
subprocess.call(['open', '/Users/drew/Documents'])
Or you can do it with appscript if you prefer:
from appscript import *
from mactypes import Alias
path = '/Users/drew/Documents'
app('Finder').items[Alias(path)].open()
has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
http://appscript.sourceforge.net/objc-appscript.html
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports no eligible process
On Friday, June 08, 2007, at 02:57PM, Kent Johnson [EMAIL PROTECTED] wrote:
has wrote:
Anyway, simplest solution here is:
import subprocess
subprocess.call(['open', '/Users/drew/Documents'])
or
import open
import os # ;-)
os.system('open /Users/drew/Documents')
That works but is non-trivial to get entirely correct due to quoting. Using
subprocess is much better because you don't have to worry about quoting for the
shell. Os.popen and os.system should basically be deprecated, but that will
probably not happen anytime soon because they are used a lot in existing code.
Ronald
Kent
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports no eligible process
has wrote:
Anyway, simplest solution here is:
import subprocess
subprocess.call(['open', '/Users/drew/Documents'])
or
import open
os.system('open /Users/drew/Documents')
Kent
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports no eligible process
Ronald Oussoren wrote: Using subprocess is much better because you don't have to worry about quoting for the shell. Os.popen and os.system should basically be deprecated, but that will probably not happen anytime soon because they are used a lot in existing code. I use os.popen because it supports non-blocking output: subprocess does not, at least not without some additional hacks. I'm glad it will still be around for a while. -- Kevin Walzer Code by Kevin http://www.codebykevin.com ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports no eligible process
On 8-Jun-2007, at 13:19 , has wrote:
You might add a note that since findertools uses aetools which is
[over]due for deprecation, findertools should be deprecated as well.
[...]
Or you can do it with appscript if you prefer:
from appscript import *
from mactypes import Alias
path = '/Users/drew/Documents'
app('Finder').items[Alias(path)].open()
Problem with deprecating aetools is that there is a truckload of
modules that depend on it, findertools among them. I'd love to
rewrite them to use appscript, and it wouldn't even be all that much
work, but I simply don't have the time (and probably won't have the
time in the coming few years).
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma
Goldman
smime.p7s
Description: S/MIME cryptographic signature
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
