pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] NibClassBuilder change

[<bb...@ma...>]

On Thursday, November 21, 2002, at 08:35 AM, Just van Rossum wrote:
> My commit rights are finally working! Breakage ahead! (Just kidding.)
>
> I just removed the actionstub stuff from NibClassBuilder.py. I left 
> part of the
> code in there as _if_ we want to issue a warning ourselves if an 
> action is not
> defined, this is the place to do it.

Ok.

> Btw. I see we have no checkin messages mailing list :-(. I know how to 
> set it up
> CVS-wise, but I think you need to be a project admin to create a new 
> list.

I would be happy to set up the list and will do so this morning [EST].

Assuming python is available on the cvs server [I believe it is], I 
have commit scripts that coalesces any single checkin such that it only 
sends one email as opposed to the 55 billion emails that most checkins 
send;  one for each directory.   (Christian Pekeler and I wrote/refined 
it over the last few years.)  You are welcome to it, if it'd help...

> I could update various examples to use NibClassBuilder instead of the 
> nibwrapper
> stuff. Objections?

Makes sense... I'll be updating the Cocoa project template [and the new 
Multi-Document App template] shortly.

b.bum

Re: [Pyobjc-dev] nitpicking: lookUpClass vs. lookupClass

[Just v. R. <ju...@le...>]

> Juust

(Interesting that I mis-spell my own name in a mail about spelling ;-)

Jst

[Pyobjc-dev] nitpicking: lookUpClass vs. lookupClass

[Just v. R. <ju...@le...>]

I see Ronald has renamed lookup_class to lookUpClass. I would have expected
lookupClass (with a lowercase u) as I tend to think of "lookup" as one word.
Since english isn't my native tongue I can't really judge whether that is
correct, or whether it really matters...

Juust

[Pyobjc-dev] pyobjc/Tools vs. pyobjc/Scripts

[Just v. R. <ju...@le...>]

IMO Tools/mknibwrapper is obsolete now, but if we remove it the Tools dir is
empty apart from a README. It says:

  Reserved for PyObjC related tools"

However, Scripts/README says:

  Reserved for PyObjC related scripts (for 'end-users')

yet contains meta tools nevertheless. Shall I just clear out the Tools/ dir and
remove the "for end users" comment from Scripts/README?

Just

[Pyobjc-dev] NibClassBuilder change

[Just v. R. <ju...@le...>]

My commit rights are finally working! Breakage ahead! (Just kidding.)

I just removed the actionstub stuff from NibClassBuilder.py. I left part of the
code in there as _if_ we want to issue a warning ourselves if an action is not
defined, this is the place to do it.

Btw. I see we have no checkin messages mailing list :-(. I know how to set it up
CVS-wise, but I think you need to be a project admin to create a new list.

I could update various examples to use NibClassBuilder instead of the nibwrapper
stuff. Objections?

Just

Re: [Pyobjc-dev] buildapplication strawman

[Just v. R. <ju...@le...>]

Jack Jansen wrote:

> > I think that Python embedders should think twice about embedding
> > based on an install not included with the system: the above is
> > definitely not the only reason things may break. If you embed, ship
> > Python as well and be done with it.
> 
> I fail to see this... In the case of MacCVS it's simple: if there's no 
> framework Python installation you get no scripting capabilities.

Sure, it's sortof an addon.

I really don't see the point in worrying too much about embedders: X
applications embedding Python will depend on Y versions/installtypes of Python,
and I very much doubt that Y will ever be closer to 1 than to X. Might as well
ship your own Python and get a _lot_ less support request from your users.

> In the case of the Python OSA component I'm not sure what happens,
> but it doesn't really matter: the Python OSA component should be
> considered an integral part of the Python distribution (and we also
> don't really care what the IDE does if Python isn't installed).

I don't really see this as an app embedding Python: it's an environment which
can work with Python if it's installed. If Python is optional, you're not really
embedding...

I'm thinking more of apps that _depend_ on Python, and for such apps a separate
Python install is simply a common source of errors. I _know_, I've been there
with Robofog. Later we shipped two versions: one depending on a separate
MacPython install and one with a truly embedded Python. We got countless
(install) error reports from (experienced!) end users using the former and none
from people using the latter.

Just

Re: [Pyobjc-dev] buildapplication strawman

[Just v. R. <ju...@le...>]

Jack Jansen wrote:

> Let's go all the way and put the Mac/Lib stuff where it belongs,

Ok, but then surely a symlink in the repository would be better than a copy?

Just

Re: [Pyobjc-dev] buildapplication strawman

[Jack J. <Jac...@cw...>]

On Wednesday, Nov 20, 2002, at 16:35 Europe/Amsterdam, Just van Rossum 
wrote:

> Jack Jansen wrote:
>
>> [ ... ] With a shared library approach your python installation
>> cannot be moved around anymore (Python itself can handle this, by
>> using its own argv[0] to locate the Lib folder, but embedding
>> applications will always use the fixed fallback path). [ ... ]
>
> I think that Python embedders should think twice about embedding based 
> on an
> install not included with the system: the above is definitely not the 
> only
> reason things may break. If you embed, ship Python as well and be done 
> with it.


I fail to see this... In the case of MacCVS it's simple: if there's no 
framework Python installation you get no scripting capabilities. In the 
case of the Python OSA component I'm not sure what happens, but it 
doesn't really matter: the Python OSA component should be considered an 
integral part of the Python distribution (and we also don't really care 
what the IDE does if Python isn't installed).
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

Re: [Pyobjc-dev] buildapplication strawman

[Jack J. <Jac...@cw...>]

On Wednesday, Nov 20, 2002, at 16:30 Europe/Amsterdam, Just van Rossum 
wrote:

> Jack Jansen wrote:
>
>> How about bringing this up on python-dev, and then (if people agree)
>> submitting the sourceforge support request? Please have the Mac/Lib
>> subtree *copied* to plat-mac, not moved. We still need it in the
>> original location if we want to do a 2.2.3 release.
>
> Ugh, can't we just leave the source tree as it is and just change the 
> install
> location(s)? This is all done by the top level setup.py script, right? 
> If so,
> this suggests we should be able to fully control this.

No, I'm against that. This would make python not find the Mac modules 
when run from the
development directory (as the modules are in a different place then). 
Moreover, the
copying is done from the Makefile, not setup.py, and this would give a 
special case
for Mac/Lib, while there really is no reason for the special case.

Let's go all the way and put the Mac/Lib stuff where it belongs,
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

Re: [Pyobjc-dev] buildapplication strawman

[<bb...@ma...>]

On Wednesday, November 20, 2002, at 08:32 AM, Jack Jansen wrote:
> On Wednesday, Nov 20, 2002, at 12:21 Europe/Amsterdam, tmk wrote:
>> That said, I trust the fact that Jack may have very good reasons to 
>> favor the framework install option instead. When you can spare the 
>> time Jack inquiring minds want to know :-)
> As I explained on the pythonmac-sig last month I'm not so sure 
> anymore, I would like to keep both options open for python 2.3, and 
> then we'll see which build catches on.

That's a dangerous game to play in the Mac and NeXT community that we 
have today... there are a lot of people that'll hang on to whatever 
they know for no good reason at all (myself included, at times :-).

> But when people thought I suggested doing away with framework builds 
> completely (which I didn't) there was quite a bit of protest. MacCVS 
> needs it, for using Python as its scripting language, and the Python 
> OSA component needs it.

Why do MacCVS and the OSA component need the framework build?  i.e. 
what is the specific dependency?  (I lurked throughout that 
conversation, but didn't catch specifics -- if you have URLs into the 
archive, that'd be great)

There is a middle ground -- don't build all of the python distribution 
as a framework build.  Simply stuff any resources that are mac specific 
into a bundle or framework that is installed into site-packages/ or 
<prefix>/lib/python<version>/plat-darwin/ and load 'em from that (thus 
also leveraging localization and other Bundle features).   The Mac 
specific modules could be built into the framework/bundle, as well, and 
could be dynamically loaded.   It could be done quite a number of 
ways...

> Note that a non-framework Python with a shared library seems like a 
> solution for this it's really only a poor substitute. With a shared 
> library approach your python installation cannot be moved around 
> anymore (Python itself can handle this, by using its own argv[0] to 
> locate the Lib folder, but embedding applications will always use the 
> fixed fallback path). Especially if we want binary installers things 
> shouldn't depend on a compile-time builtin pathname.

I'm not sure I understand.  Both frameworks and dylibs share the trait 
that they have the path to the library embedded in the dynamically 
loaded code...

[bumbox:~] bbum% otool -L /Library/Frameworks/PGPui.framework/PGPui
/Library/Frameworks/PGPui.framework/PGPui:
         /Library/Frameworks/PGPui.framework/Versions/A/PGPui 
(compatibility version 1.0.0, current version 1.0.0)
         /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 
(compatibility version 1.0.0, current version 8.0.0)
         /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 
(compatibility version 2.0.0, current version 122.0.0)
         /Library/Frameworks/PGP.framework/Versions/A/PGP (compatibility 
version 1.0.0, current version 1.0.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, 
current version 60.2.0)

... and, as such, anything built against that framework will require 
that framework to always be in the spot as specified by the embedded 
path unless you play games with the DYLIB environment variables prior 
to launching the executable that requires the framework [as does 
python-bin-main to allow embedding of frameworks in the app wrapper].

b.bum

Re: [Pyobjc-dev] buildapplication strawman

[<bb...@ma...>]

On Wednesday, November 20, 2002, at 08:45 AM, Jack Jansen wrote:
> No, not an arbitrary one, it picks the first one you specified. But 
> never mind:
> let's do this your way (i.e. specify the nib by name, separate from 
> the .plist
> files).

I'm confused;  will this work with the localization features built into 
the system?

[Pyobjc-dev] Automatically wrapping frameworks

[<bb...@ma...>]

On Wednesday, November 20, 2002, at 02:19 AM, Ronald Oussoren wrote:
> That said, I'd like to build a module or script to build a template 
> from wrapping yet another Objective-C class library. I don't think it 
> would be usefull to use 'AddressBook = 
> Foundation.Python.GenerateModuleForBundle("AddressBook")' as a 
> replacement for 'import AddressBook'

There are two kinds of 'automatic wrapping' possible and thing there is 
some confusion as to who is referring to which type.

First, 'automatic wrapping' can be something that replaces 'import 
AddressBook'.   For Objective-C APIs, we already have this -- simply 
load the framework as a bundle via load_bundle (soon loadBundle) and 
use the APIs directly.   This is effectively how the AddressBook 
wrapper is currently working outside of it being included as a module 
within the objc project.   Easy to do, but doesn't include support the 
various enumerated types and global variables found in the framework.

The second kind of 'automatic wrapping' would effectively generate a 
distutils based project that included the automatically generated 
source that, when compiled, would produce a module that contained the 
various exported references that can only be accessed via a compiled 
module [the various globals and C functions, etc... though, also 
containing a wrapping of the enumerated types is useful in that a 
simple recompile will pick up any changes to the types].

The first can be done on the fly on any machine.... the second requires 
the dev tools and is really more appropriate for developers looking to 
wrap existing frameworks.

Both very useful but, in general, only the second will be able to fully 
wrap an existing framework automatically.

b.bum

Re: [Pyobjc-dev] buildapplication strawman

[Just v. R. <ju...@le...>]

Jack Jansen wrote:

> [ ... ] With a shared library approach your python installation
> cannot be moved around anymore (Python itself can handle this, by
> using its own argv[0] to locate the Lib folder, but embedding
> applications will always use the fixed fallback path). [ ... ]

I think that Python embedders should think twice about embedding based on an
install not included with the system: the above is definitely not the only
reason things may break. If you embed, ship Python as well and be done with it.

Just

Re: [Pyobjc-dev] buildapplication strawman

[Just v. R. <ju...@le...>]

Jack Jansen wrote:

> How about bringing this up on python-dev, and then (if people agree)
> submitting the sourceforge support request? Please have the Mac/Lib
> subtree *copied* to plat-mac, not moved. We still need it in the
> original location if we want to do a 2.2.3 release.

Ugh, can't we just leave the source tree as it is and just change the install
location(s)? This is all done by the top level setup.py script, right? If so,
this suggests we should be able to fully control this.

Just

Re: [Pyobjc-dev] buildapplication strawman

[Just v. R. <ju...@le...>]

Jack Jansen wrote:

> > I read your code, and it just picks an arbitrary nib if there are
> > more than one, I don't quite understand how you can defend that...
> 
> No, not an arbitrary one, it picks the first one you specified. But
> never mind: let's do this your way (i.e. specify the nib by name,
> separate from the ..plist files).

Ah, whoops, sorry for the misunderstanding!

> >> But unfortunately the __rawmain__ trick is needed for one of the most
> >> useful applications of an applet: taking a standard unix Python
> >> script and turning it into a droplet.
> >
> > Don't you want to move the argv emulation to Python as well? It's
> > hairy stuff and I think we could win a great deal to have it in
> > Python. I really think we should strive to use a vanilla main, and
> > the execve wrapper makes it all possible.
> 
> Let me borrow Guido's time machine .... [POOF] Done!
> 
> PythonW uses the normal unix main program (as of 2.3a0, not in
> 2.2.X). And the __rawmain__ is all about doing the OSA stuff for
> argument emulation.
> 
> Look at Mac/Lib/appletrawmain.py (which is copied to __rawmain__ in
> an applets that wants argv emulation) and argvemulator.py (which does
> the actual work).

Ah, perfect, I hadn't realized that! Very cool. But then I don't  understand
what you meant with your comment about the "__rawmain__ trick" being needed: the
question was whether it is needed in the _actual_ compiled main program, but I
don't see how that could be the case with the execve wrapper.

Just

Re: [Pyobjc-dev] buildapplication strawman

[Jack J. <Jac...@cw...>]

On Tuesday, Nov 19, 2002, at 18:06 Europe/Amsterdam, Just van Rossum 
wrote:
>> Yes, it's added to the resources. Ah, I now see your "The .lproj or
>> individual nibs should then be listed as a resource" sentence. So you
>> want the user to pass the main nib twice, once as a file and once as
>> a name. Hmm, yes, with nibs in ..lprojs I can see the point. Ok, fine
>> with me, but you should probably add a check that the main nib
>> actually exists.
>
> I read your code, and it just picks an arbitrary nib if there are more 
> than one,
> I don't quite understand how you can defend that...

No, not an arbitrary one, it picks the first one you specified. But 
never mind:
let's do this your way (i.e. specify the nib by name, separate from the 
.plist
files).

>> But unfortunately the __rawmain__ trick is needed for one of the most
>> useful applications of an applet: taking a standard unix Python
>> script and turning it into a droplet.
>
> Don't you want to move the argv emulation to Python as well? It's 
> hairy stuff
> and I think we could win a great deal to have it in Python. I really 
> think we
> should strive to use a vanilla main, and the execve wrapper makes it 
> all
> possible.

Let me borrow Guido's time machine .... [POOF] Done!

PythonW uses the normal unix main program (as of 2.3a0, not in 2.2.X). 
And the __rawmain__
is all about doing the OSA stuff for argument emulation.

Look at Mac/Lib/appletrawmain.py (which is copied to __rawmain__ in an 
applets that wants
argv emulation) and argvemulator.py (which does the actual work).
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

Re: [Pyobjc-dev] buildapplication strawman

[Jack J. <Jac...@cw...>]

On Wednesday, Nov 20, 2002, at 00:27 Europe/Amsterdam, Just van Rossum 
wrote:
> I'd suggest to install all Mac stuff in 
> <prefix>/lib/python<version>/plat-darwin
> (or /plat-mac if the install procedure allows that).

plat-mac for the stuff that works both on OSX and OS9, which is 
probably most.
plat-mac isn't currently on sys.path for darwin, but we would fix that 
too.

How about bringing this up on python-dev, and then (if people agree) 
submitting the
sourceforge support request? Please have the Mac/Lib subtree *copied* 
to plat-mac,
not moved. We still need it in the original location if we want to do a 
2.2.3 release.
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

Re: [Pyobjc-dev] buildapplication strawman

[Jack J. <Jac...@cw...>]

On Wednesday, Nov 20, 2002, at 12:21 Europe/Amsterdam, tmk wrote:
> That said, I trust the fact that Jack may have very good reasons to 
> favor the framework install option instead. When you can spare the 
> time Jack inquiring minds want to know :-)

As I explained on the pythonmac-sig last month I'm not so sure anymore, 
I would like to keep both options open for python 2.3, and then we'll 
see which build catches on.

But when people thought I suggested doing away with framework builds 
completely (which I didn't) there was quite a bit of protest. MacCVS 
needs it, for using Python as its scripting language, and the Python 
OSA component needs it.

Note that a non-framework Python with a shared library seems like a 
solution for this it's really only a poor substitute. With a shared 
library approach your python installation cannot be moved around 
anymore (Python itself can handle this, by using its own argv[0] to 
locate the Lib folder, but embedding applications will always use the 
fixed fallback path). Especially if we want binary installers things 
shouldn't depend on a compile-time builtin pathname.
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

Re: [Pyobjc-dev] Separating functionality into modules

[Peter M. <zig...@po...>]

On Thursday, November 21, 2002, at 12:11 AM, Jack Jansen wrote:
> On Wednesday, Nov 20, 2002, at 06:13 Europe/Amsterdam, Peter Montagner 
> wrote:
>>>> Another example of a python-specific functionality is a mixin class 
>>>> for a dialog that would automatically keep the dialog items synced 
>>>> with another object (using Pythons introspection to obtain the 
>>>> names of the dialog items, looking them up in the other object. 
>>>> Combined with slots this could even happen completely automatic).
>>>
>>> Not sure I get this one...
>>
>> I think he's talking about doing the standard "Controller" bit of the 
>> MVC paradigm automagically. There is a lot of stuff that a Controller 
>> class does that is done almost every time and is quite tedious to 
>> program. You're not going to be able to eliminate this repetitive 
>> application logic completely but this could help in making PyObjC a 
>> really easy RAD environment. Of course I probably misread his idea.
>
> That's indeed what I was thinking about.

Well, care to elaborate in that case? It sounds very interesting. Have 
you put much thought into it or were you just throwing it out there as 
a possibility. How do you keep everything synced?

Peter

Re: [Pyobjc-dev] Separating functionality into modules

[Jack J. <Jac...@cw...>]

On Wednesday, Nov 20, 2002, at 08:19 Europe/Amsterdam, Ronald Oussoren 
wrote:
> That said, I'd like to build a module or script to build a template 
> from wrapping yet another Objective-C class library. I don't think it 
> would be usefull to use 'AddressBook = 
> Foundation.Python.GenerateModuleForBundle("AddressBook")' as a 
> replacement for 'import AddressBook'

For this specific case you're right. But if we have the mechanism to 
dynamically create modules (and that's a big "if", considering Bills 
remarks) I think we should go down the dynamic path in stead of the 
static path.

To give you an example: MacPython builds AppleScript modules by parsing 
the AETE resources and generating Python code to handle the objects and 
verbs and such. The fact that this isn't done dynamically means that 
you cannot interface to a new scriptable application without first 
going through the motions of creating the interface modules, while it 
would be much nicer if this was done on the fly. But by now the parsing 
and generation code has become so big and complex that changing it to 
something more dynamic is going to be too much hassle.

> It is already there:
> >>> import objc
> >>> print objc.__version__
> 0.7.1
> >>>

Great!

(BTW: the Official Python Way to say that something is already there is 
to use Guido's time machine. As in
"Version numbers? Good idea. One moment, let me borrow Guido's time 
machine.... [poof]. It's implemented" :-)
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

Re: [Pyobjc-dev] Separating functionality into modules

[Jack J. <Jac...@cw...>]

On Wednesday, Nov 20, 2002, at 06:13 Europe/Amsterdam, Peter Montagner 
wrote:
>>> Another example of a python-specific functionality is a mixin class 
>>> for a dialog that would automatically keep the dialog items synced 
>>> with another object (using Pythons introspection to obtain the names 
>>> of the dialog items, looking them up in the other object. Combined 
>>> with slots this could even happen completely automatic).
>>
>> Not sure I get this one...
>
> I think he's talking about doing the standard "Controller" bit of the 
> MVC paradigm automagically. There is a lot of stuff that a Controller 
> class does that is done almost every time and is quite tedious to 
> program. You're not going to be able to eliminate this repetitive 
> application logic completely but this could help in making PyObjC a 
> really easy RAD environment. Of course I probably misread his idea.

That's indeed what I was thinking about.
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

Re: [Pyobjc-dev] buildapplication strawman

[tmk <li...@ne...>]

On Wednesday, Nov 20, 2002, at 00:27 Europe/Brussels, Just van Rossum 
wrote:

> bb...@ma... wrote:
>
>> I don't understand the benefits of the framework build.   It requires
>> additional maintenance within the Python source trees and doesn't seem
>> to add any capabilities that couldn't be done with a 'regular' build 
>> of
>> Python?   I would think there is a tremendous amount of value in
>> eliminating the number of differences between the build of Python on
>> one platform vs. others.  Certainly, the Mac platform warrants the 
>> slew
>> of Mac specific modules that are in their, but modules build 
>> relatively
>> cleanly without requiring changes to and ongoing maintenance of
>> configure.in....
>
> Hear, hear and hear.
>
> I'd suggest to install all Mac stuff in 
> <prefix>/lib/python<version>/plat-darwin
> (or /plat-mac if the install procedure allows that).

Same here. I was originally a supporter of the framework install. But 
after bbum's excellent arguments in favor of a standard  I can't see 
any advantages in having the official (Apple or not) python install 
being a framework install.

Plus, it seems that even Apple is moving away from framework install 
for OSS type software (Perl, tcl used to be packaged (at least 
partially) as frameworks in Rhapsody and later on).

And last, the many scars I got from trying to build (MachoPython) 
python from source on Mac OS X "non-standard" unix (starting way back 
on Rhapsody and Mac OS X Developper and Preview Releases have made me a 
strong supporter of standards when available ;-). That and the time it 
took to have Python build from source on Mac OS X without one having to 
hack on it.

That said, I trust the fact that Jack may have very good reasons to 
favor the framework install option instead. When you can spare the time 
Jack inquiring minds want to know :-)

Just my .02 euros

= tmk =


>
> Just
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: To learn the basics of securing
> your web site with SSL, click here to get a FREE TRIAL of a Thawte
> Server Certificate: http://www.gothawte.com/rd524.html
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] objc & sys.path munging

[Just v. R. <ju...@le...>]

Ronald Oussoren wrote:

> This code should be removed and we should add the correct path to 
> sys.path in another way (either through PYTHONPATH (non-embedded 
> python) or by changing sys.path directly (embedded python)).

Ok, once my buildappbundle tool works I'll follow up on that.

> (*) Sorry Jack, I don't rembember what went wrong. I may well be that I 
> misunderstood some issues.

I think the MacPython main didn't (doesn't?) set the CWD to the scripts folder,
the CWD was (is?) always / at startup.

Just

Re: [Pyobjc-dev] Separating functionality into modules

[Ronald O. <ous...@ci...>]

On Tuesday, Nov 19, 2002, at 13:48 Europe/Amsterdam, Jack Jansen wrote:

>
> On Monday, Nov 18, 2002, at 16:45 Europe/Amsterdam, bb...@ma... wrote:
>>> 4. Why AddressBook is included completely eludes me. Is this 
>>> framework somehow
>>>    more important than the other ones, or is this really only an 
>>> example?
>>
>> At the moment, it is the only first-class, high level, OO API 
>> included with the system that is not highly application specific 
>> [PreferencesPane, ScreenSaver, Project Builder] and includes a public 
>> API.   It is generically useful and represents functionality that 
>> quite a number of developers will want to use.
>
> Ok, fair enough.

I added it because (a) it was easy to do and (b) because it is an Apple 
provided Objective-C framework/class library.

BTW. AddressBook.framework can also be used with plain C code. That may 
cause problems later on if you decide to also wrap this framework :-)

>>
>>> If for (4) I'm correct and AddressBook is just an example, shouldn't 
>>> we provide a general solution in the form of a factory function so 
>>> the user can do
>>> AddressBook = 
>>> Foundation.Python.GenerateModuleForBundle("AddressBook")
>>
>> It requires a compiled component to wrap a framework such that 
>> enumerated types, #defines, and functions can be exported.  Ronald 
>> has done an amazing job of automating the generating of the wrappers, 
>> but it needs some work before it could automatically generate a 
>> module project to wrap a specific framework.  That would be very, 
>> very > cool...
>
> Oops, I missed that bit, I didn't realise there was an extension 
> module too, I thought it was pure python.
> [search.... search....]
> No, I can't find it. Are you sure that this module isn't pure Python? 
> Because if it is then my factory function idea should work (create a 
> module, populate it with the classes returned by 
> Foundation.load_bundle, return the module).
> And, if there is C code for AddressBook: where is it?

This module is pure Python code. I think Bill is refering to the 
general case.

That said, I'd like to build a module or script to build a template 
from wrapping yet another Objective-C class library. I don't think it 
would be usefull to use 'AddressBook = 
Foundation.Python.GenerateModuleForBundle("AddressBook")' as a 
replacement for 'import AddressBook'

>
>>> We need a new place to put Python-specific modules, at the moment 
>>> only for
>>> AppKit but later we may want this for the other packages too. I can 
>>> see two simple solutions:
>>> A. Put them in a sub-package. Foundation.Python comes to mind, but 
>>> there may
>>>    be better names.
>>> B. Prefix them with "Py". Again, another prefix is also possible.
>>
>> Before we go here, how much functionality are we actually talking 
>> about?
>
> At the moment there isn't much, indeed, but I can imagine it growing.
[nifty examples removed]

I agree with Jack. We should split of all user-visible extentions to 
seperate modules. There are few of these now but the number will grow.

As for a naming convention... Currently my favorite is a Python 
subpackage (Foundation.Python.Foo, AppKit.Python.Foo, ...).

>>> Oh yes: I want a version number somewhere, probably in objc. I don't 
>>> really care whether there's a static version number or a function 
>>> that returns a version number, but I need a version number for my 
>>> Python Installation Manager (which will help keep the size of 
>>> MacPython distributions down, but still allow pretty easy access to 
>>> any package for end users; see the pythonmac-sig discussions for 
>>> more details).

It is already there:
 >>> import objc
 >>> print objc.__version__
0.7.1
 >>>

Ronald

Re: [Pyobjc-dev] objc & sys.path munging

[Ronald O. <ous...@ci...>]

On Tuesday, Nov 19, 2002, at 10:17 Europe/Amsterdam, Just van Rossum 
wrote:

> Here's a snippet from objc.__init__.py:
>
>   # This is a hack, should probably patch python:
>   # - We want the resources directory to be on the python search-path
>   # - It must be at the start of the path
>   # - The CWD must not be on the path
>   if 1 :
>       b = lookup_class('NSBundle').mainBundle()
>       if b:
>           sys.path.insert(0, 
> '%s/Contents/Resources'%str(b.bundlePath()))
>       del b
>   del sys, __builtin__
>
> Questions:
> - "...should probably patch python", how?
> - why must it be at the start of the path?
> - why must the CWD not be on the path?

These were notes to myself, but I never followed up on it... The last 
item is actually wrong.

When you run a python script the interpreter will add the directory 
containing the script at the start of sys.path. I noticed that this 
doesn't work out correctly with the python from buildtools.py (*) and 
added this as a workaround.

This code should be removed and we should add the correct path to 
sys.path in another way (either through PYTHONPATH (non-embedded 
python) or by changing sys.path directly (embedded python)).

Ronald

(*) Sorry Jack, I don't rembember what went wrong. I may well be that I 
misunderstood some issues.