Thread: [Pyobjc-dev] 0.9
Brought to you by:
ronaldoussoren
Menu
▾
▴
pyobjc-dev
|
From: Bill B. <bb...@co...> - 2003-02-01 19:16:04
|
As Just mentioned, it is about time to do a 0.9 release. If we are going to do any major changes to the namespace, now is the time. I would like to see *everything* in pyobjc move into a 'pyobjc' package... and have the other three/four packages hang below that. pyobjc.obj pyobjc.foundation pyobjc.appkit pyobjc.addressbook ... etc ... This will make for much easier packaging in app wrappers [simplifies build targets] and much less clutter in site-packages. thoughts? b.bum |
|
From: Tony L. <to...@lo...> - 2003-02-01 20:03:00
|
Hi, At 2:15 PM -0500 2/1/03, Bill Bumgarner wrote: >As Just mentioned, it is about time to do a 0.9 release. Out of curiosity, will 0.9 be FFI only? >If we are going to do any major changes to the namespace, now is the time. > >I would like to see *everything* in pyobjc move into a 'pyobjc' >package... and have the other three/four packages hang below that. > >pyobjc.obj >pyobjc.foundation >pyobjc.appkit >pyobjc.addressbook lowercase for appkit and foundation? >... etc ... > >This will make for much easier packaging in app wrappers [simplifies >build targets] and much less clutter in site-packages. > >thoughts? FWIW, I am -0 1. The current flat nesting adds weight to the idea that Foundation and AppKit are big frameworks in their own right 2. This adds some text for every import (and there tend to be a lot in pyobjc programs) 3. Its not hard to package the modules in a subdirectory, using .pth files in /usr/lib/site-packages and with minimal extra code in bin-python-main.m. Hmm, and some extra code in bundlebuilder.py too, I think. OTOH, extra code somewhere is still extra code, and putting everything in a package doesn't require any extra code. 4. If I see "Declared in: AppKit/NSMatrix.h" in Apple's docs, I write: "from AppKit import NSMatrix". One-to-one correspondence! Just my 2 cents... -Tony |
|
From: Bill B. <bb...@co...> - 2003-02-01 20:09:14
|
On Saturday, Feb 1, 2003, at 15:02 US/Eastern, Tony Lownds wrote:
> Hi,
> At 2:15 PM -0500 2/1/03, Bill Bumgarner wrote:
>> As Just mentioned, it is about time to do a 0.9 release.
> Out of curiosity, will 0.9 be FFI only?
Good question. Personally, I think it should be for two reasons:
- we have FFI only features now [classAddMethods]
- we have already had a situation where the non-FFI stuff broke because
it went untested... i.e. non-FFI support is being neglected by the dev
team.
>> If we are going to do any major changes to the namespace, now is the
>> time.
>>
>> I would like to see *everything* in pyobjc move into a 'pyobjc'
>> package... and have the other three/four packages hang below that.
>>
>> pyobjc.obj
>> pyobjc.foundation
>> pyobjc.appkit
>> pyobjc.addressbook
>
> lowercase for appkit and foundation?
Follows Python standard? Personally, I like Foundation and AppKit,
as well -- of course, AppKit really should be Cocoa for OS X even
though Cocoa is basically an empty framework...
>> ... etc ...
>>
>> This will make for much easier packaging in app wrappers [simplifies
>> build targets] and much less clutter in site-packages.
>>
>> thoughts?
>
> FWIW, I am -0
>
> 1. The current flat nesting adds weight to the idea that Foundation
> and AppKit are big frameworks in their own right
I still think they should be nested, just under a single roof....
> 2. This adds some text for every import (and there tend to be a lot in
> pyobjc programs)
True.
> 3. Its not hard to package the modules in a subdirectory, using .pth
> files in /usr/lib/site-packages and with minimal extra code in
> bin-python-main.m. Hmm, and some extra code in bundlebuilder.py too, I
> think. OTOH, extra code somewhere is still extra code, and putting
> everything in a package doesn't require any extra code.
I'm not sure what this means....
> 4. If I see "Declared in: AppKit/NSMatrix.h" in Apple's docs, I write:
> "from AppKit import NSMatrix". One-to-one correspondence!
Which would change to:
from pyobjc.AppKit import NSMatrix
Strictly speaking, this emphasizes that one is using the 'pyobjc'
gateway into the 'AppKit' framework -- a more correct nomenclature
because the pyobjc bridge changes the way the AppKit is accessed.
> Just my 2 cents...
Thanks...
All in all, I'm not hugely attached to any of this. I suppose my
motivation is largely one of having to uninstall the module
semi-regularly to ensure that standalone builds still work correctly.
Not a very good reason to modify the dev environment, certainly.
b.bum
|
|
From: Just v. R. <ju...@le...> - 2003-02-01 20:31:43
|
Bill Bumgarner wrote: > On Saturday, Feb 1, 2003, at 15:02 US/Eastern, Tony Lownds wrote: > > lowercase for appkit and foundation? > > Follows Python standard? Nah, there's StringIO, BaseHTTPServer.py, Carbon, and these are just the first three that popped up in my head... > > 3. Its not hard to package the modules in a subdirectory, using > > .pth files in /usr/lib/site-packages and with minimal extra code in > > bin-python-main.m. Hmm, and some extra code in bundlebuilder.py > > too, I think. OTOH, extra code somewhere is still extra code, and > > putting everything in a package doesn't require any extra code. > > I'm not sure what this means.... This means there will be a folder inside site-packages containing a folder (eg.) PyObjC which contains all our stuff. Right next to it in site-packages there's a file called PyObjC.pth which contains one line "PyObjC", which is the relative path to our dir which will then be added to sys.path by site.py. So this solves the cluttering of the site-packages dir. > All in all, I'm not hugely attached to any of this. Think of all the articles on line whose examples would stop working ;-) > I suppose my > motivation is largely one of having to uninstall the module > semi-regularly to ensure that standalone builds still work correctly. > Not a very good reason to modify the dev environment, certainly. Ok, this .pth thing can help here. It's a simple patch to setup.py, I'll look into it. Just |
|
From: Just v. R. <ju...@le...> - 2003-02-01 21:00:35
|
Just van Rossum wrote:
> This means there will be a folder inside site-packages containing a
> folder (eg.) PyObjC which contains all our stuff. Right next to it in
> site-packages there's a file called PyObjC.pth which contains one
> line "PyObjC", which is the relative path to our dir which will then
> be added to sys.path by site.py. So this solves the cluttering of the
> site-packages dir.
This is all there is to it:
Index: setup.py
===================================================================
RCS file: /cvsroot/pyobjc/pyobjc/setup.py,v
retrieving revision 1.32
diff -c -r1.32 setup.py
*** setup.py 31 Jan 2003 14:34:11 -0000 1.32
--- setup.py 1 Feb 2003 20:59:13 -0000
***************
*** 283,286 ****
--- 283,287 ----
packages = packages,
package_dir = package_dir,
scripts = [ 'Scripts/nibclassbuilder', ],
+ extra_path = "PyObjC",
)
Shall I go for it?
Just
|
|
From: Bill B. <bb...@co...> - 2003-02-01 22:46:14
|
On Saturday, Feb 1, 2003, at 16:00 US/Eastern, Just van Rossum wrote: > Shall I go for it? +1 |
|
From: Bill B. <bb...@co...> - 2003-02-01 22:45:28
|
On Saturday, Feb 1, 2003, at 15:31 US/Eastern, Just van Rossum wrote: > Nah, there's StringIO, BaseHTTPServer.py, Carbon, and these are just > the > first three that popped up in my head... Oh, duh! Don't know where my brain was on that one! >>> 3. Its not hard to package the modules in a subdirectory, using >>> .pth files in /usr/lib/site-packages and with minimal extra code in >>> bin-python-main.m. Hmm, and some extra code in bundlebuilder.py >>> too, I think. OTOH, extra code somewhere is still extra code, and >>> putting everything in a package doesn't require any extra code. >> >> I'm not sure what this means.... > > This means there will be a folder inside site-packages containing a > folder (eg.) PyObjC which contains all our stuff. Right next to it in > site-packages there's a file called PyObjC.pth which contains one line > "PyObjC", which is the relative path to our dir which will then be > added > to sys.path by site.py. So this solves the cluttering of the > site-packages dir. Ahhh... OK. That makes sense. It also doesn't break anything. Way superior. Didn't even know it existed. b.bum |
|
From: Ronald O. <ous...@ci...> - 2003-02-02 17:08:43
|
On Saturday, Feb 1, 2003, at 21:08 Europe/Amsterdam, Bill Bumgarner wrote: > On Saturday, Feb 1, 2003, at 15:02 US/Eastern, Tony Lownds wrote: >> Hi, >> At 2:15 PM -0500 2/1/03, Bill Bumgarner wrote: >>> As Just mentioned, it is about time to do a 0.9 release. >> Out of curiosity, will 0.9 be FFI only? > > Good question. Personally, I think it should be for two reasons: > > - we have FFI only features now [classAddMethods] > > - we have already had a situation where the non-FFI stuff broke > because it went untested... i.e. non-FFI support is being neglected by > the dev team. I'd prefer to make 0.9 a libffi-by-default release (if you really don't want libffi you can change setup.py and do without classAddMethods). The next release beyond that should probably be FFI only, this would allow for easier to comprehend code. > >>> If we are going to do any major changes to the namespace, now is the >>> time. >>> >>> I would like to see *everything* in pyobjc move into a 'pyobjc' >>> package... and have the other three/four packages hang below that. >>> >>> pyobjc.obj >>> pyobjc.foundation >>> pyobjc.appkit >>> pyobjc.addressbook >> >> lowercase for appkit and foundation? > > Follows Python standard? Personally, I like Foundation and AppKit, > as well -- of course, AppKit really should be Cocoa for OS X even > though Cocoa is basically an empty framework... There are enough modules whose name start with an uppercase letter to make this a non-issue. The MacPython Carbon/CoreFoundation modules also use names starting with an uppercase letter. And wrt. Cocoa, we could add a Cocoa.py that does 'from Foundation import *; from AppKit import *', but I don't think that would buy us much, the developer docs mention AppKit/NSFoobar.h not the Cocoa version. > >>> ... etc ... >>> >>> This will make for much easier packaging in app wrappers [simplifies >>> build targets] and much less clutter in site-packages. >>> >>> thoughts? >> >> FWIW, I am -0 >> >> 1. The current flat nesting adds weight to the idea that Foundation >> and AppKit are big frameworks in their own right > > I still think they should be nested, just under a single roof.... > >> 2. This adds some text for every import (and there tend to be a lot >> in pyobjc programs) > > True. > >> 3. Its not hard to package the modules in a subdirectory, using .pth >> files in /usr/lib/site-packages and with minimal extra code in >> bin-python-main.m. Hmm, and some extra code in bundlebuilder.py too, >> I think. OTOH, extra code somewhere is still extra code, and putting >> everything in a package doesn't require any extra code. > > I'm not sure what this means.... We could install our python files in another location than site-packages (say /opt/pyobjc) and add a pyobjc.pth to site-packages. This makes site-packages less cluttered :-) I'm not too worried about this, we currently add: - bundlebuilder and friends: Those are part of Python 2.3 and provided as a convenience for our users. - package objc: This is the core bridge, normal users should only need this in exceptional cases - packages Foundation, AppKit, AddressBook: These are wrappers around (large) Apple provided class libraries. - autoGIL: Might move to MacPython in the future. We might move this to the Foundation package One change to the toplevel namespaces might be usefull: Add a PyObjCUtils packages containing usefull addon facilities (like the Just's TelnetInspector and NibClassLoader). Foundation.Conversion could also be moved to this package. > >> 4. If I see "Declared in: AppKit/NSMatrix.h" in Apple's docs, I write: >> "from AppKit import NSMatrix". One-to-one correspondence! > > Which would change to: > > from pyobjc.AppKit import NSMatrix > > Strictly speaking, this emphasizes that one is using the 'pyobjc' > gateway into the 'AppKit' framework -- a more correct nomenclature > because the pyobjc bridge changes the way the AppKit is accessed. I don't want to know that I'm using a gateway. The beauty of PyObjC is that it the bridge is almost invisible. This also makes it pretty boring to talk about, but you can't have everything :-) BTW. On what timescale do you want to do a 0.9 release? There's one issue that IMHO should be fixed soon: Users must currently manually adjust the reference count if they allocate an object using 'SomeClass.alloc().init()'. I'd like to fix this soon. Ronald |
|
From: Just v. R. <ju...@le...> - 2003-02-01 20:26:06
|
Tony Lownds wrote: > FWIW, I am -0 Me too. > 3. Its not hard to package the modules in a subdirectory, using .pth > files in /usr/lib/site-packages and with minimal extra code in > bin-python-main.m. Yes, distutils supports this easily. I've used it myself and I know NumPy does it, too. If we choose to do this I volunteer to patch setup.py. Note that this makes upgrading harder (once), as you probably need to manually delete the modules from the "old" place. > Hmm, and some extra code in bundlebuilder.py too, I think. Hm, I can't see why. Can you elaborate? Just |
|
From: Tony L. <to...@lo...> - 2003-02-02 19:14:43
|
> > 3. Its not hard to package the modules in a subdirectory, using .pth >> files in /usr/lib/site-packages and with minimal extra code in >> bin-python-main.m. > >Yes, distutils supports this easily. I've used it myself and I know >NumPy does it, too. If we choose to do this I volunteer to patch >setup.py. Note that this makes upgrading harder (once), as you probably >need to manually delete the modules from the "old" place. > >> Hmm, and some extra code in bundlebuilder.py too, I think. > >Hm, I can't see why. Can you elaborate? When I mentioned the need for extra code, I was thinking about including PyObjC in the application bundle. As it turns out putting the PyObjC directory + the PyObjC.pth into SomeApp.app/Contents/Resources/ "just works". The reason it works feels coincidental. In both app wrappers (bundlebuilder's and bin-python-main.m) the SomeApp.app/Contents/Resources/ directory is added to the path by setting the PYTHONPATH environment variable and then exec'ing python. Python runs site.py, which scans for .pth files, and then the user code. If some other app wrapper is devised, and if that app wrapper modifies the path by sys.path, then those .pth files will no longer work. This is all academic now, but it would be nice to guarantee that any new app wrappers A) add SomeApp.app/Contents/Resources to the path B) honor .pth files in SomeApp.app/Contents/Resources -Tony |
|
From: Just v. R. <ju...@le...> - 2003-02-02 19:28:02
|
Tony Lownds wrote: > When I mentioned the need for extra code, I was thinking about > including PyObjC in the application bundle. As it turns out putting > the PyObjC directory + the PyObjC.pth into > SomeApp.app/Contents/Resources/ "just works". > > The reason it works feels coincidental. In both app wrappers > (bundlebuilder's and bin-python-main.m) the > SomeApp.app/Contents/Resources/ directory is added to the path by > setting the PYTHONPATH environment variable and then exec'ing python. > Python runs site.py, which scans for .pth files, and then the user > code. If some other app wrapper is devised, and if that app wrapper > modifies the path by sys.path, then those .pth files will no longer > work. > > This is all academic now, but it would be nice to guarantee that any > new app wrappers > A) add SomeApp.app/Contents/Resources to the path > B) honor .pth files in SomeApp.app/Contents/Resources I see no reason to not simply include the actual modules in Resources. Perhaps that's handy for PB, but then again, I don't use PB. Idea: is PB pluggable enough so we can have a Python program that calculates the actual dependencies? Just |
|
From: Tony L. <to...@lo...> - 2003-02-02 20:26:50
|
At 8:27 PM +0100 2/2/03, Just van Rossum wrote:
>
>I see no reason to not simply include the actual modules in Resources.
>Perhaps that's handy for PB, but then again, I don't use PB.
Well, I can posit a few useful scenarios for being able to use .pth
files in Resources, such as including a CVS controlled directory of
external Python source like I am doing with spambayes, but until
there's an actual problem (and there's not) I'll shut up.
Speaking of app wrappers, below is a bin-python-main.m that will load
a framework build of python. It seems to load faster than using the
execve methods...
-Tony
/*
This main file runs Contents/Resource/__main__.py using a framework
build of python
*/
#import <Foundation/Foundation.h>
#import <Python/Python.h>
#import <sys/param.h>
#import <unistd.h>
#import <stdio.h>
int pyobjc_main(int argc, char * const *argv, char * const *envp)
{
// The autorelease pool is not released on purpose, because I
don't know much
// about objc memory management
[[NSAutoreleasePool alloc] init];
// set up paths
const char *mainPyFile = [[[[NSBundle mainBundle] resourcePath]
stringByAppendingPathComponent: @"__main__.py"] UTF8String];
printf("mainPyFile=%s\n", mainPyFile);
Py_SetProgramName(mainPyFile);
Py_Initialize();
argv[0] = mainPyFile; // PySys_SetArgv wants script in argv
PySys_SetArgv(argc, argv);
FILE *fp = fopen(mainPyFile, "r");
if (fp == NULL) {
perror("Cannot open mainPyFile");
} else {
PyRun_SimpleFile(fp, mainPyFile);
fclose(fp);
}
Py_Finalize();
return 0;
}
int main(int argc, char * const *argv, char * const *envp)
{
return pyobjc_main(argc, argv, envp);
}
|
|
From: Bill B. <bb...@co...> - 2003-02-02 23:12:52
|
On Sunday, Feb 2, 2003, at 15:26 US/Eastern, Tony Lownds wrote: > Speaking of app wrappers, below is a bin-python-main.m that will load > a framework build of python. It seems to load faster than using the > execve methods... That source is already in the CVS repository -- it is just in the Attic of, I believe, Web Services Tool. Not a very useful spot. There will be project builder templates created that use an embedded python interpreter. Unfortunately, Apple's Python cannot [currently] be embedded into an application because it does not ship with a dylib or library to link against. b.bum |
|
From: Martina O. <Ma...@Oe...> - 2003-02-04 21:21:20
|
I don't know whether this is a PyObjC bug or a Cocoa bug, but
NSSearchPathForDirectoriesInDomains doesn't recognize PyObjC's YES.
According to the docs, if the third parameter (expandTilde) is YES,
tildes are expanded as described in stringByExpandingTildeInPath. But
this doesn't work. Tildes are expanded only if I pass -1:
[iBook:~] martina% python
Python 2.2 (#1, 07/14/02, 23:25:09)
[GCC Apple cpp-precomp 6.14] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from objc import NO, YES
>>> from Foundation import
NSSearchPathForDirectoriesInDomains,NSLibraryDirectory,NSUserDomainMask
>>>
NSSearchPathForDirectoriesInDomains(NSLibraryDirectory,NSUserDomainMask,
NO)
("~/Library")
>>>
NSSearchPathForDirectoriesInDomains(NSLibraryDirectory,NSUserDomainMask,
YES)
("~/Library")
>>>
NSSearchPathForDirectoriesInDomains(NSLibraryDirectory,NSUserDomainMask,
1)
("~/Library")
>>>
NSSearchPathForDirectoriesInDomains(NSLibraryDirectory,NSUserDomainMask,
-1)
("/Users/martina/Library")
should I file a bug?
ciao
Martina
|
|
From: Ronald O. <ous...@ci...> - 2003-02-05 08:52:10
|
On Tuesday, Feb 4, 2003, at 22:21 Europe/Amsterdam, Martina Oefelein
wrote:
> I don't know whether this is a PyObjC bug or a Cocoa bug, but
> NSSearchPathForDirectoriesInDomains doesn't recognize PyObjC's YES.
>
> According to the docs, if the third parameter (expandTilde) is YES,
> tildes are expanded as described in stringByExpandingTildeInPath. But
> this doesn't work. Tildes are expanded only if I pass -1:
>
> [iBook:~] martina% python
> Python 2.2 (#1, 07/14/02, 23:25:09)
> [GCC Apple cpp-precomp 6.14] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from objc import NO, YES
> >>> from Foundation import
> NSSearchPathForDirectoriesInDomains,NSLibraryDirectory,NSUserDomainMask
> >>>
> NSSearchPathForDirectoriesInDomains(NSLibraryDirectory,NSUserDomainMask
> ,NO)
> ("~/Library")
> >>>
> NSSearchPathForDirectoriesInDomains(NSLibraryDirectory,NSUserDomainMask
> ,YES)
> ("~/Library")
> >>>
> NSSearchPathForDirectoriesInDomains(NSLibraryDirectory,NSUserDomainMask
> ,1)
> ("~/Library")
> >>>
> NSSearchPathForDirectoriesInDomains(NSLibraryDirectory,NSUserDomainMask
> ,-1)
> ("/Users/martina/Library")
>
> should I file a bug?
Please do.
Ronald
|
|
From: Ronald O. <ous...@ci...> - 2003-02-05 09:30:56
|
On Wednesday, Feb 5, 2003, at 09:51 Europe/Amsterdam, Ronald Oussoren wrote: > > On Tuesday, Feb 4, 2003, at 22:21 Europe/Amsterdam, Martina Oefelein > wrote: >> >> should I file a bug? > Please do. Never mind, fixed in CVS. Ronald |
|
From: Martina O. <Ma...@Oe...> - 2003-02-06 21:21:11
|
Am Mittwoch, 05.02.03 um 10:29 Uhr schrieb Ronald Oussoren: > Never mind, fixed in CVS. YEP. >>> NSSearchPathForDirectoriesInDomains(NSLibraryDirectory,NSUserDomainMask, YES) <NSCFArray objective-c instance 0x530560> >>> _[0] '/Users/martina/Library' >>> NSSearchPathForDirectoriesInDomains(NSLibraryDirectory,NSUserDomainMask, NO) <NSCFArray objective-c instance 0x160740> >>> _[0] '~/Library' I assume the problem that NSCFArray doesn't get printed as a list is a temporary problem caused by the recent changes in the bridging? ciao Martina |
|
From: Ronald O. <ous...@ci...> - 2003-02-06 21:59:29
|
On Thursday, Feb 6, 2003, at 22:21 Europe/Amsterdam, Martina Oefelein wrote: > > I assume the problem that NSCFArray doesn't get printed as a list is a > temporary problem caused by the recent changes in the bridging? Not really. This is caused by __repr__ returning the text your seeing instead of the result of self.description(). We do that because the interpreter may crash when calling description for uninitialized objects (the result of SomeClass.alloc()). This may be changed in the future (now that we can detect uninitialized objects). Ronald |
|
From: Ronald O. <ous...@ci...> - 2003-02-02 16:41:22
|
On Saturday, Feb 1, 2003, at 20:15 Europe/Amsterdam, Bill Bumgarner wrote: > As Just mentioned, it is about time to do a 0.9 release. > > If we are going to do any major changes to the namespace, now is the > time. Speaking of namespaces, I'd like to some massive surgery on function names in the C code (to make them comply with our coding style). > > I would like to see *everything* in pyobjc move into a 'pyobjc' > package... and have the other three/four packages hang below that. > > pyobjc.obj pyobjc.objc (?) > pyobjc.foundation > pyobjc.appkit > pyobjc.addressbook -1 on this I like having AppKit and Foundation at toplevel, this neatly mirrors the <AppKit/..> and <Foundation/..> "namespaces" in Objective-C. It also introduces a fundamental difference between frameworks wrapped by the PyObjC-team and other frameworks: The latter cannot be in the pyobjc package (which would introduce compatibility issues if the wrapper is moved into the core later on)\ > > ... etc ... > > This will make for much easier packaging in app wrappers [simplifies > build targets] and much less clutter in site-packages. This may actually make it harder to build a minimal standalone application, IIRC modulefinder assumes you'll need the entire package if you use one module from a package. That may or may not be an issue. Ronald |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X