pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Separating functionality into modules

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

On Wednesday, November 20, 2002, at 02:39 AM, bb...@ma... wrote:
> On Tuesday, November 19, 2002, at 07:48 AM, Jack Jansen wrote:
>> On Monday, Nov 18, 2002, at 16:45 Europe/Amsterdam, bb...@ma... 
>> wrote:
>>
>>> 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?
>
> Hey, what do you know... you're right! I thought it had a compiled 
> component, as well!  I assumed it had a compiled component because of 
> the enumerated types and the global references used throughout the 
> module.
>
> Let me amend that:  It *needs* a compiled component if it is to be a 
> complete bridge of the AddressBook framework.  Sorry about the 
> confusion.

PyObjC seems to favour automatically generated code wherever possible. 
Could we do the same thing for wrapping frameworks? A tool could take a 
list of variable types and names and automatically generate and compile 
the needed wrapping code. This would help users (and developers) who 
want to completely wrap a framework but don't know the ins and outs of 
writing a Python C module or how to interface with the PyObjC module 
(if that's needed).

You could probably do the same thing for C APIs, C functions etc. 
Anything that isn't a simple global variable, a constant or a straight 
forward C function would need a custom wrapper but most of the APIs on 
Mac OS X are pretty clean in this respect. Most of Mac OS X's 
frameworks are C APIs. It would be nice if we could wrap those as well. 
Is it possible to dynamically load non-objc frameworks though?


>> At the moment there isn't much, indeed, but I can imagine it growing. 
>> With Python's multiple inheritance and operator overloading, for 
>> instance, there's all sorts of nifty things you could do, such as
>> class TableViewList(list, PyObjC.listTableDataSourceMixin):
>> 	pass
>> x = TableViewList()
>> and then use x both as a normal Python list and as an 
>> NSTableDataSource. Note that I haven't actually worked this example 
>> out (so it may be plain impossible), but you get the idea.
>
> Totally possible and a very cool idea!   I constantly use a couple of 
> hunks of code that I have developed over the years to map an array to 
> an NSTableView and map a set of collection classes to NSOutlineView.

Totally possible but is there a better way? 
PyObjC.listTableDataSourceMixin would have to be pretty dependant on it 
also being the subclass of a list so why make the user do it? You could 
make a class called PyObjC.listTableDataSource that inherited from list 
and implemented the data source methods and just let the user use that. 
Your method would be more flexible in that it would work with any 
sequence type. Maybe you could do both: have the mixin class and have a 
couple of convenience classes with the data source already mixed in. 
Hmm, convenience classes for convenience classes...

I realise that this was just an example. There are many possibilities 
for convenience stuff. It would be funny if PyObjC became more powerful 
than the ObjC version of Cocoa and had very useful features that the 
ObjC version didn't have.


>> 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.

Peter

Re: [Pyobjc-dev] buildapplication strawman

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

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).

Just

Re: [Pyobjc-dev] buildapplication strawman

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

On Tuesday, November 19, 2002, at 12:06 PM, Just van Rossum wrote:
> [I don't quite get Bill's comment regarding this, we're assembling an 
> app, not
> _using_ nibs, so I don't see the relevance of the system API's here.]

Clarification:   Yes, I realized now it was about assembling an app.  
In any case, the NSMainNibFile (or whatever it is called) key in the 
Info.plist should be set appropriately as opposed to using a hard coded 
path.   It, in turn, uses the localization APIs to load the appropriate 
NIB file.   At least, it does in Cocoa, I have *no idea* what happens 
with NIB based Carbon apps.

b.bum

Re: [Pyobjc-dev] buildapplication strawman

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

Jack Jansen wrote:

> > But you don't do anything with the pathname but get the base name,
> > strip the extension and use it as the NSMainNibFile Info.plist key,
> > right? Why not just write "MainMenu" and be done with it?
> 
> 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...

[I don't quite get Bill's comment regarding this, we're assembling an app, not
_using_ nibs, so I don't see the relevance of the system API's here.]

> > BuildApplet is great for very simple things, and worked fine on OS9
> > where everything you needed could live in <scriptname>.rsrc. But I
> > don't think this approach is all that useful for .app bundles but
> > for the simplest of scripts. Then again: BuildApplet-like
> > functionality could easily be built on top of this.
> 
> But don't forget that there are many "very simple things". About 100%
> of the scripts ported over from unix, for instance. But as I said: if
> you're writing the code you decide how to do it.

I find it very limiting in reality: as soon as a unix script has options the
argv emulation is hardly useful.

> > My working code currently needs to munge the wrapper even more: I
> > need to specify the Python executable in case it's copied to
> > Contents/Resources/. It's a tiny amount of code and works for me
> > just fine as a triple-quoted string. [Reading this back: I need to
> > do even more if we need to set PYTHONHOME conditionally.]
> 
> Could be done dynamically:
>      bindir = os.path.split(argv[0])[0]
>      if os.path.exists(os.path.join(bindir, "python")):
>          We are a self-contained application, set PYTHONHOME and use 
> this python
>      else:
>          We are an applet. Set PYTHONPATH and use /usr/bin/python

Ok, that's an option. But I don't really like runtime checks for things that are
known at build time, and I really don't see any problem with using a tiny
triple-quoted string as template.

> > The stuff I would _especially_ like to avoid is the Mac-specific
> > main, with __main__/__rawmain__ magic. I want to use the vanilla
> > unix main, or rather the vanilla unix _executable_. Trivial with
> > the execve template.
> 
> 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.

Just

Re: [Pyobjc-dev] buildapplication strawman

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

(Cursory comments-- a lot of this is about stuff that I know little 
about [framework build, Carbon stuff, MacPython], so take it with a 
grain of salt)

On Tuesday, November 19, 2002, at 08:26 AM, Jack Jansen wrote:
>> - I would not let people specify a nib by path, but by name, 
>> defaulting to
>>   "MainMenu". The .lproj or individual nibs should then be listed as a
>>   resource.
>
> Why? If there is a good reason to disallow full pathnames: fine with 
> me, but I don't
> immediately see why this would be so.

If one uses the CFBundle/NSBundle APIs to obtain the path to the NIB 
file, then localization "just works".  Full pathnames defeat this 
feature of the OS.   Similarly, using the NSMainNIB key (whatever it is 
called) also exercises the localization features.

>> Further things I'd like to do:
>>
>> - Change it to use the os.execve() trick.
>
> Definitely, but as an option. The only thing I'm not sure about is 
> whether the execve code
> should be in-line in a string (as in your version) or external on 
> sys.path (as buildtools.py
> currently does).

If it is to work with the Apple distribution of Python, then the 
assumption must be that it won't necessarily be available in the python 
installation?  Even in a development environment, there is no need for 
the user to install pyobjc into the python distribution -- 
non-administrators can and should be able to use PyObjC and the related 
development tools without an administrative-only installation phase.

>> - I would like to add a debug or "developer" option: instead of 
>> copying the
>>   files/folders it would put symlinks inside the bundle. That way 
>> it's easy
>>   to keep on hacking on any file without having to rebuild the app 
>> all the time.
>
> Yes, good idea.

WebObjects has a feature called 'rapid turnaround mode'.  It works in a 
similar fashion, but doesn't use symlinks.  I have been looking into 
how to do the same with PyObjC based applications.  But, in reality, 
symlinks work just fine .

>> - Add modulefinder support, like we discussed by telepathy... The 
>> full version
>>   would also copy the Python executable to Contents/Resources/. Not 
>> sure what
>>   to do about a Framework python, though. Not sure I even care about 
>> that
>>   anymore: it only seems to make thing harder here. What do you think?
>
> I think the framework python is still my preferred option, and I hope 
> we can get Apple to adopt it at some point in the future. but for the 
> time being I want to keep both working.

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....

I admit a lot of ignorance on this front-- emphasis on ?

....

>> - A strip binaries option. Hm, evil? Could save a huge amount of disk 
>> space,
>>   though.
>
> Good idea. But: is "strip" available if you don't have the dev tools 
> installed?

It is in /usr/bin/strip and, I believe, is a part of the BSD layer, not 
the dev tools.  Should definitely check the BOMs in 
/Library/Receipts/....

b.bum

Re: [Pyobjc-dev] Separating functionality into modules

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

On Tuesday, November 19, 2002, at 07:48 AM, 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.

Whether or not it should be included is still up in the air.... I'm not 
attached to it in that context.

>>> 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?

Hey, what do you know... you're right! I thought it had a compiled 
component, as well!  I assumed it had a compiled component because of 
the enumerated types and the global references used throughout the 
module.

Let me amend that:  It *needs* a compiled component if it is to be a 
complete bridge of the AddressBook framework.  Sorry about the 
confusion.

Your factory function would be tremendously valuable anyway and the 
AddressBook is a good example;  for quickly wrapping a framework for 
which enough of the functionality is available via the pure ObjC API to 
be useful.

>>> 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. 
> With Python's multiple inheritance and operator overloading, for 
> instance, there's all sorts of nifty things you could do, such as
> class TableViewList(list, PyObjC.listTableDataSourceMixin):
> 	pass
> x = TableViewList()
> and then use x both as a normal Python list and as an 
> NSTableDataSource. Note that I haven't actually worked this example 
> out (so it may be plain impossible), but you get the idea.

Totally possible and a very cool idea!   I constantly use a couple of 
hunks of code that I have developed over the years to map an array to 
an NSTableView and map a set of collection classes to NSOutlineView.

> 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...

>>> 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).
>>
>> Yes;   how about something like....
>>
>> >>> sys.version_info
>> (2, 2, 0, 'final', 0)
>> >>> sys.version
>> '2.2 (#1, 07/14/02, 23:25:09) \n[GCC Apple cpp-precomp 6.14]'
>
> What I want is the version of the PyObjC package. The only thing I 
> need it for is to compare it against the most recent version (which is 
> obtain from a net-based database) and to warn the user that a new 
> version is available. So a simple
> version = '0.9'
> in objc/__init__.py should suffice. It doesn't matter what the 
> datatype of the version is, as long as it is monotonically increasing.

Yes -- what I was asking was more a 'should we advertise a version and 
version_info in the same format as the python core because that is a 
standard?' ... not that the contents of sys.version_info and 
sys.version have any bearing on what pyobjc provide.

     (0, 8, 0, 'alpha', 0)

and

     '0.8.0 alpha (#1, ....), [GCC ... OS X 10.2.2 6F21]'

Or something like it?

b.bum

Re: [Pyobjc-dev] Reason not to use the python based main

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

On Tuesday, November 19, 2002, at 07:05 AM, Jack Jansen wrote:
> Bill, you've said this a couple of times earlier, but I absolutely 
> fail to see what you mean by it. What's the use linking an executable 
> to a couple of frameworks if that executable is going to blow itself 
> away with an execve() a couple of microseconds later? How will the 
> frameworks that bin-python-main has been linked with influence the 
> python interpreter that is started later?

Let me use a production application suite that I'm developing as an 
example.  It is a Cocoa and Foundation based suite of applications that 
provides a user interface to CodeFab's product Intent.   See 
www.codefab.com for more information.   Intent provides a full featured 
XML-RPC inteface;  anything you can do via the web interface can also 
be done via XML-RPC (excluding administrative tasks).

About a month ago, I moved the project to using Python as the XML-RPC 
client because it was both a boatload easier and significantly more 
robust than using Apple's WebServices framework found in the Core 
(which can be crashed by malformed XML -- "malformed" isn't well 
defined given the state of the XML-RPC "specification").  The use of 
python also allows me to build a single client that can be used 
basically anywhere, has a clean command line interface and can act as 
the communication bridge within the Cocoa applications.

The application suite is currently comprised of two applications;  a 
user tool and an administrative tool.   A command line tool and a third 
application are already planned.   As there are multiple applications, 
there are two frameworks used across the apps -- the Core framework 
provides non-UI client services while an Application support level 
framework provides UI services.   The Core only depends on the 
Foundation.  The Application level framework depends on both Foundation 
and AppKit.

Enter Python;  the Core contains the Python XML-RPC client code and, as 
such, uses the PyObjC bridge quite heavily.   The rest of the app is 
pure Obj-C.  Not so much because it is intended to be pure ObjC, but 
because it was pure ObjC before Python and the PyObjC bridge were 
introduced [and before PyObjC was stable enough to be used in this 
context].

In other words, I have a large and relatively complex set of 
interlocking projects that mix Python and Objective-C.

To these ends, each application ships with the two frameworks installed 
in the application wrapper, one of which contains Python code using 
PyObjC.

At launch, I need to dynamically load both frameworks.   The most 
straightforward approach would be to walk through the 
Contents/Frameworks or Contents/SharedFrameworks directory and 
dynamically load each framework in turn.

However, this won't work within the development environment as the 
frameworks are not-- and should not be-- copied into this directories 
when I'm building and running the app(s) within Project Builder (i.e. 
using pbxbuild to build the apps).  This also won't work in situations 
where the developer or administrator is using the DYLD functionality 
provided by the system to either share one copy of the frameworks or to 
run a different version of a particular framework within the app.

To make everything work correctly, I build the python-bin-main based 
executable-- the main executable within each app wrapper-- such that it 
links against AppKit, Foundation, and my two private frameworks.   Upon 
execution, the python-bin-main uses NSBundle's +allFrameworks directory 
to determine all of the frameworks linked into the application, creates 
a command line argument to be passed to the python interpreter, sets a 
couple of the DYLD linker configuration environment variables 
appropriately, and passes control to the python interpreter (typically 
/usr/bin/python but can be any python interpreter -- pyobjc may or may 
not be packaged in the App wrapper, as well) by executing Main.py (now 
__main__.py, but will move to the list Jack uses very soon) entry point 
python file.

Main.py modifies sys.path to include Contents/Resources/pyobjc (in case 
pyobjc is shipped in the wrapper).  It then loads the objc module.

Once the objc module is loaded, Main.py walks the list of frameworks 
that were passed in from python-bin-main executable and dynamically 
loads each one.   Furthermore, it will execute the file Init.py in each 
framework if the framework's NSBundle finds said file via 
pathForResource_ofType_('Init', 'py'), providing the framework with a 
chance to initialize its python based features, if any.

All of this guarantees that the dynamically loaded frameworks under the 
Python environment behave as much like their directly linked 
counterparts in a "normal" application.   In particular, it guarantees 
that the frameworks will be loaded from exactly where they would 
normally be loaded-- there is no way to tell where a framework is going 
to be loaded from without both reverse engineering and recreating a 
good chunk of the dynamic loading code found via the dyld* APIs.

This style of initialization also allows the developer to create a 
command line tool-- an executable without a resources directory-- that 
can still use a mix of Python and Objective-C by using a framework and 
will also find that framework in the exact same fashion as a "normal" 
command line tool that uses a framework (namely, will find the 
framework in the development environment without having to install the 
framework).

For Cocoa apps written in pure python as non-PBX based or 'standalone' 
projects, python-bin-main doesn't offer much and sticking with a pure 
python based main is the way to go.  For developers using PBX to 
develop any kind of a Cocoa-ObjC app that used compiled ObjC classes, 
the compiled python-bin-main is a requirement if the developer wants 
the development experience to remain consistent with non-python based 
projects (a desirable feature, IMO).   If the developer wants the 
documentation indexing to work in PBX, something must be compiled as a 
part of the project -- doesn't have to be the main, but it might as 
well be.

BTW:  The Cocoa application and Python client are both open source -- 
we will be shipping the source under a BSD style (or MIT) license.

A rather long winded response, but hopefully it'll provide some 
indication as to the thinking that has gone into some of my opinions...

b.bum

Re: [Pyobjc-dev] buildapplication strawman

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

On Tuesday, Nov 19, 2002, at 15:15 Europe/Amsterdam, Just van Rossum 
wrote:
>>> - I would not let people specify a nib by path, but by name,
>>> defaulting to "MainMenu". The .lproj or individual nibs should then
>>> be listed as a resource.
>>
>> Why? If there is a good reason to disallow full pathnames: fine with
>> me, but I don't immediately see why this would be so.
>
> But you don't do anything with the pathname but get the base name, 
> strip the
> extension and use it as the NSMainNibFile Info.plist key, right? Why 
> not just
> write "MainMenu" and be done with it?

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 think it's good if it (by default) would build the app in a
>>> build/ subdir, like distutils and PB.
>>
>> I've been working to the analogy of BuildApplet, but I'm not
>> particularly married to that.
>
> BuildApplet is great for very simple things, and worked fine on OS9 
> where
> everything you needed could live in <scriptname>.rsrc. But I don't 
> think this
> approach is all that useful for .app bundles but for the simplest of 
> scripts.
> Then again: BuildApplet-like functionality could easily be built on 
> top of this.

But don't forget that there are many "very simple things". About 100% 
of the
scripts ported over from unix, for instance. But as I said: if you're 
writing the
code you decide how to do it.

>> The only thing I'm not sure about is
>> whether the execve code should be in-line in a string (as in your
>> version) or external on sys.path (as buildtools.py currently does).
>
> My working code currently needs to munge the wrapper even more: I need 
> to
> specify the Python executable in case it's copied to 
> Contents/Resources/.
> It's a tiny amount of code and works for me just fine as a 
> triple-quoted string.
> [Reading this back: I need to do even more if we need to set PYTHONHOME
> conditionally.]

Could be done dynamically:
     bindir = os.path.split(argv[0])[0]
     if os.path.exists(os.path.join(bindir, "python")):
         We are a self-contained application, set PYTHONHOME and use 
this python
     else:
         We are an applet. Set PYTHONPATH and use /usr/bin/python

>> I think the framework python is still my preferred option, and I hope
>> we can get Apple to adopt it at some point in the future. but for the
>> time being I want to keep both working.
>
> Ok, but I'll need your help then... The code will have to become a 
> _lot_ more
> complicated if I need to support Framework Python: instead of just 
> throwing the
> python executable and all needed modules (.py[c] & .so) into 
> Contents/Resources/
> I'll have to copy a _subset_ of Python.framework to the bundle. And 
> somehow we
> need to tell the main executable to look for the Framework in the 
> bundle (or has
> this become more transparent now?). Things are so fantastically simple 
> with a
> unix install that I'm not really all that sure what Python.framework 
> was
> supposed to buy us in the first place :-(.

Don't worry about this for the moment. BuildApplication doesn't work 
for framework python right now, so there's nothing you can break. I 
have some ideas on how to do this, but there's lots of time before 
2.3b1.

>> As to modulefinder support: I think we need to think architecture
>> first. We now have a number of modules and scripts that do things that
>> are vaguely similar conceptually, but very different in 
>> implementation:
>> - buildtools can build MacPython-OS9 applets.
>> - buildtools can build MacPython-OSX applets.
>> - buildtools can help with building MacPython-OS9 applications.
>> - BuildApplication uses buildtools and selected bits of freeze to 
>> build
>> applications for MacPython-OS9.
>> - buildappbundle can build general .app bundles.
>> - your tool can build .app bundles specific for Python applets.
>
> Hm, I would _love_ to just leave that old cruft alone, and start from 
> scratch
> with something maintainable. The old stuff works, I would rather not 
> let the old
> stuff be a burden to get the new stuff going.

There's definitely something to be said for this. [think.... think...]
Ok, make it so.
>
> The stuff I would _especially_ like to avoid is the Mac-specific main, 
> with
> __main__/__rawmain__ magic. I want to use the vanilla unix main, or 
> rather the
> vanilla unix _executable_. Trivial with the execve template.

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.

This is the one use of applets I can see end-users (as opposed to 
developers) making.
--
- 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

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

Oooh, lots of stuff...

Jack Jansen wrote:

[ Mac/script/buildappbundle.py ]
> It's only been there for a week or two, so I doubt anyone gets upset.
> But: do keep the commandline interface working (or, if you move the
> functionality to Lib, keep the driver main program in the scripts
> folder), as I use it when building MacPython-OSX 2.2 (the MacPython
> that will sit on /usr/bin/python).
> 
> And note that the tool has nothing python-specific, really. I use it
> with my OpenGL C and C++ applications too. I build these with
> Makefiles (they run on both Linux and OSX), and for OSX the last
> build step is buildappbundle, which stuffs the executable into a .app
> bundle (on Linux this step is skipped).

Ah, I see. This means I'll have to rework my working version as it's fairly
Python-specific now :-(

> > - I would not let people specify a nib by path, but by name,
> > defaulting to "MainMenu". The .lproj or individual nibs should then
> > be listed as a resource.
> 
> Why? If there is a good reason to disallow full pathnames: fine with
> me, but I don't immediately see why this would be so.

But you don't do anything with the pathname but get the base name, strip the
extension and use it as the NSMainNibFile Info.plist key, right? Why not just
write "MainMenu" and be done with it?

> > - I think it's good if it (by default) would build the app in a
> > build/ subdir, like distutils and PB.
> 
> I've been working to the analogy of BuildApplet, but I'm not
> particularly married to that.

BuildApplet is great for very simple things, and worked fine on OS9 where
everything you needed could live in <scriptname>.rsrc. But I don't think this
approach is all that useful for .app bundles but for the simplest of scripts.
Then again: BuildApplet-like functionality could easily be built on top of this.

> > - Change it to use the os.execve() trick.
> 
> Definitely, but as an option.

Ok, I'll have to work on that.

> The only thing I'm not sure about is
> whether the execve code should be in-line in a string (as in your
> version) or external on sys.path (as buildtools.py currently does).

My working code currently needs to munge the wrapper even more: I need to
specify the Python executable in case it's copied to Contents/Resources/. 
It's a tiny amount of code and works for me just fine as a triple-quoted string.
[Reading this back: I need to do even more if we need to set PYTHONHOME
conditionally.]

> > - Add modulefinder support, like we discussed by telepathy... The
> > full version would also copy the Python executable to
> > Contents/Resources/. Not sure what to do about a Framework python,
> > though. Not sure I even care about that anymore: it only seems to
> > make thing harder here. What do you think?
> 
> I think the framework python is still my preferred option, and I hope
> we can get Apple to adopt it at some point in the future. but for the
> time being I want to keep both working.

Ok, but I'll need your help then... The code will have to become a _lot_ more
complicated if I need to support Framework Python: instead of just throwing the
python executable and all needed modules (.py[c] & .so) into Contents/Resources/
I'll have to copy a _subset_ of Python.framework to the bundle. And somehow we
need to tell the main executable to look for the Framework in the bundle (or has
this become more transparent now?). Things are so fantastically simple with a
unix install that I'm not really all that sure what Python.framework was
supposed to buy us in the first place :-(.

> As to modulefinder support: I think we need to think architecture 
> first. We now have a number of modules and scripts that do things that 
> are vaguely similar conceptually, but very different in implementation:
> - buildtools can build MacPython-OS9 applets.
> - buildtools can build MacPython-OSX applets.
> - buildtools can help with building MacPython-OS9 applications.
> - BuildApplication uses buildtools and selected bits of freeze to build 
> applications for MacPython-OS9.
> - buildappbundle can build general .app bundles.
> - your tool can build .app bundles specific for Python applets.

Hm, I would _love_ to just leave that old cruft alone, and start from scratch
with something maintainable. The old stuff works, I would rather not let the old
stuff be a burden to get the new stuff going.

The stuff I would _especially_ like to avoid is the Mac-specific main, with
__main__/__rawmain__ magic. I want to use the vanilla unix main, or rather the
vanilla unix _executable_. Trivial with the execve template.

[ ... ]

> > - A strip binaries option. Hm, evil? Could save a huge amount of
> > disk space, though.
> 
> Good idea. But: is "strip" available if you don't have the dev tools
> installed?

Dunno, but we can skip that option then...

> > Question: is it possible to completely override sys.path for a
> > statically built Unix Python? $PYTHONPATH merely prepends sys.path.
> > Would be nice to completely control it for a standalone app bundle.
> 
> You could create lib/python2.2 and lib/python2.2/lib-dynload under
> Resources, and then set PYTHONHOME to Resources.

Ah, PYTHONHOME of course.

> Hmm, this could be an interesting way to distinguish applets and
> fully self-contained applications: if there is a lib/python2.2 and
> lib/python2.2/lib-dynload then we set PYTHONHOME. We could then copy
> /usr/bin/python to the MacOS directory too, and use that to run the 
> standalone application.

Not sure if I follow you...

> For static python this is good enough. For framework python more
> magic is needed.

Operative words: "more magic". Do we _really_ want to go there?

Just

Re: [Pyobjc-dev] buildapplication strawman

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

On Monday, Nov 18, 2002, at 00:46 Europe/Amsterdam, Just van Rossum 
wrote:

> Jack Jansen wrote:
>
>> Mac/script/buildappbundle.py
>
> Ok, I've had a closer look at it: great! Mind if I take a hack at it? 
> I would
> like to move it to Mac/Lib/ though. It it used much? Would people 
> likely get
> upset if I change the (function) interface?

It's only been there for a week or two, so I doubt anyone gets upset. 
But: do keep the commandline
interface working (or, if you move the functionality to Lib, keep the 
driver main program in the
scripts folder), as I use it when building MacPython-OSX 2.2 (the 
MacPython that will sit on /usr/bin/python).

And note that the tool has nothing python-specific, really. I use it 
with my OpenGL C and C++ applications too.
I build these with Makefiles (they run on both Linux and OSX), and for 
OSX the last build step is buildappbundle,
which stuffs the executable into a .app bundle (on Linux this step is 
skipped).

> - I would not let people specify a nib by path, but by name, 
> defaulting to
>   "MainMenu". The .lproj or individual nibs should then be listed as a
>   resource.

Why? If there is a good reason to disallow full pathnames: fine with 
me, but I don't
immediately see why this would be so.

> - I don't care much for the command line interface: I think people 
> should just
>   write a setup.py-like script. I wouldn't rip main() out, but I 
> wouldn't want
>   to spend much time on it.

As said above: I need it for building Python.app for 2.2 MacPython-OSX.

> - I think it's good if it (by default) would build the app in a build/ 
> subdir,
>   like distutils and PB.

I've been working to the analogy of BuildApplet, but I'm not 
particularly married to that.

>
> Further things I'd like to do:
>
> - Change it to use the os.execve() trick.

Definitely, but as an option. The only thing I'm not sure about is 
whether the execve code
should be in-line in a string (as in your version) or external on 
sys.path (as buildtools.py
currently does).

> - I would like to add a debug or "developer" option: instead of 
> copying the
>   files/folders it would put symlinks inside the bundle. That way it's 
> easy
>   to keep on hacking on any file without having to rebuild the app all 
> the time.

Yes, good idea.

> - Add modulefinder support, like we discussed by telepathy... The full 
> version
>   would also copy the Python executable to Contents/Resources/. Not 
> sure what
>   to do about a Framework python, though. Not sure I even care about 
> that
>   anymore: it only seems to make thing harder here. What do you think?

I think the framework python is still my preferred option, and I hope 
we can get Apple to adopt it at some point in the future. but for the 
time being I want to keep both working.

As to modulefinder support: I think we need to think architecture 
first. We now have a number of modules and scripts that do things that 
are vaguely similar conceptually, but very different in implementation:
- buildtools can build MacPython-OS9 applets.
- buildtools can build MacPython-OSX applets.
- buildtools can help with building MacPython-OS9 applications.
- BuildApplication uses buildtools and selected bits of freeze to build 
applications for MacPython-OS9.
- buildappbundle can build general .app bundles.
- your tool can build .app bundles specific for Python applets.

How about structuring this whole lot as a package? We could then make 
sure that the OS9-specific code (which would depend on MacPython 
functionality for resource-file mangling, for instance) would be in a 
separate module so it wouldn't be seen when building a PyObjC applet 
with /usr/bin/python. Also, there's heaps of data that the modules 
above rely on, and currently some of it is hardcoded in strings (your 
execve code, the plist data in your script), some of it is in modules 
on sys.path (__rawmain__ aka appletrawmain, appletrunner), some of it 
is somewhere completely different (Applet-Info.plist). If we have a 
package we also have a neat place to store all this data, in separate 
files.
>
> - A strip binaries option. Hm, evil? Could save a huge amount of disk 
> space,
>   though.

Good idea. But: is "strip" available if you don't have the dev tools 
installed?
>
> Question: is it possible to completely override sys.path for a 
> statically built
> Unix Python? $PYTHONPATH merely prepends sys.path. Would be nice to 
> completely
> control it for a standalone app bundle.

You could create lib/python2.2 and lib/python2.2/lib-dynload under 
Resources, and then set
PYTHONHOME to Resources.

Hmm, this could be an interesting way to distinguish applets and fully 
self-contained applications:
if there is a lib/python2.2 and lib/python2.2/lib-dynload then we set 
PYTHONHOME. We could then copy
/usr/bin/python to the MacOS directory too, and use that to run the 
standalone application.

For static python this is good enough. For framework python more magic 
is needed.
--
- 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 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.
>
>> 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?

>> 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. 
With Python's multiple inheritance and operator overloading, for 
instance, there's all sorts of nifty things you could do, such as
class TableViewList(list, PyObjC.listTableDataSourceMixin):
	pass
x = TableViewList()
and then use x both as a normal Python list and as an 
NSTableDataSource. Note that I haven't actually worked this example out 
(so it may be plain impossible), but you get the idea.

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).


>> 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).
>
> Yes;   how about something like....
>
> >>> sys.version_info
> (2, 2, 0, 'final', 0)
> >>> sys.version
> '2.2 (#1, 07/14/02, 23:25:09) \n[GCC Apple cpp-precomp 6.14]'

What I want is the version of the PyObjC package. The only thing I need 
it for is to compare it against the most recent version (which is 
obtain from a net-based database) and to warn the user that a new 
version is available. So a simple
version = '0.9'
in objc/__init__.py should suffice. It doesn't matter what the datatype 
of the version is, as long as it is monotonically increasing.
--
- 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] Reason not to use the python based main

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

On Monday, Nov 18, 2002, at 20:38 Europe/Amsterdam, bb...@ma... wrote:
> In any case, the ObjC version offers features that cannot be 
> implemented in Python. Notably, the automatic handling and loading of 
> frameworks cannot be done without some manual effort on the part of 
> the developer.  The current bin-python-main.m allows the developer to 
> link the frameworks into the project as they would in any normal PBX 
> based project and the __main__.py and bin-python-main.m will take care 
> of ensuring that they are also dynamically loaded once control is 
> turned over to the python interpreter.

Bill, you've said this a couple of times earlier, but I absolutely fail 
to see what you mean by it. What's the use linking an executable to a 
couple of frameworks if that executable is going to blow itself away 
with an execve() a couple of microseconds later? How will the 
frameworks that bin-python-main has been linked with influence the 
python interpreter that is started later?
--
- 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 -

[Pyobjc-dev] objc & sys.path munging

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

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?

I really think the adding of Contents/Resources to sys.path should be done
elsewhere. It would be trivial to do so in the execve wrapper.

I'd like to understand the issues...

Just

Re: [Pyobjc-dev] NIB Validation & action methods

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

[bbum]
> > Given that action method validation already exists within the AppKit 
> > framework and it works at the only time where complete/correct 
> > validation is possible, why should we bother duplicating that 
> > functionality in the PyObjC module and doing so in a fashion that is 
> > going to generate false warnings?

I would be easy to avoid these false warnings by (manually) adding a stub
action.

[Ronald Oussoren]
> It might generate false warnings if the Python code adds new methods at 
> runtime. Whenever I do things like that I prefer not to depend on 
> automatic mechanisms likes Just's AutoBaseClass.

Right.

Currently AutoBaseClass adds stub actions, basically disabling the AppKit
validation, so I think this should be removed.

Btw. is it possible to mix in action methods from another class like so:

class PyModel(AutoBaseClass, NSTableSource, SomeCommonActionsIPreparedEarlier):
    ...

? If this _is_ possible, then the stub-injecting code currently in
NibClassBuilder will only screw things up...

Ok, the stub actions need to go. Then remains the question whether (in addition
to AppKit's own warnings) it may be useful to issue a warning on missing actions
here as well.

Just

Re: [Pyobjc-dev] NIB Validation & action methods

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

On Tuesday, November 19, 2002, at 01:20 AM, Ronald Oussoren wrote:
> On Monday, Nov 18, 2002, at 16:01 Europe/Amsterdam, bb...@ma... wrote:
>
>> On Sunday, November 17, 2002, at 02:06 AM, Ronald Oussoren wrote:
>>> In Python you can also add new methods to a class. I'd not worry to 
>>> much about this, if only because it will be less efficient to call 
>>> those additional methods from Objective-C: The additional methods 
>>> are called through an NSInvocation while the normal methods are 
>>> called through more efficient method stubs.
>>
>> Efficiency of dispatch in this context is largely irrelevant as it 
>> generally happens as a part of the user clicking a button or hitting 
>> a menu item -- i.e. once to trigger the event processing.
>
> It is not entirely irrelevant, some methods in the NSTableDataSource 
> are called quite often and if those are slow this is noticable.

Yes;  Speaking of.... when are NSTableDataSource methods validated?  
... at Nib load or when the table goes to the datasource the first time?

I would consider it a performance issue that we have to go through 
NSInvocation in this situation -- a bug, really -- but I'm not at all 
sure there is anyway around it?

>> Given that action method validation already exists within the AppKit 
>> framework and it works at the only time where complete/correct 
>> validation is possible, why should we bother duplicating that 
>> functionality in the PyObjC module and doing so in a fashion that is 
>> going to generate false warnings?
>
> It might generate false warnings if the Python code adds new methods 
> at runtime. Whenever I do things like that I prefer not to depend on 
> automatic mechanisms likes Just's AutoBaseClass.

Agreed.

> The other 'false' warnings are generated when actions have been 
> defined in Interface Builder that are not yet used. I don't think 
> these are false warnings at all, either the UI does not yet use the 
> actions (e.g. this is a development version) or you're building up 
> cruft in your NIB file.

Agreed -- and they are warnings that will be covered when the NIB is 
loaded, so why reinvent the wheel?

I often use the warnings that the Cocoa NIB loading mechanism emits as 
a kind of bookmark for functionality that needs to be implemented.  
This is a big part of the reason why I don't think that the 
AutoBaseClass on-the-fly class definition should define placeholders;  
they effectively disable already working validation, move the 
validation to a location that an experienced Cocoa programmer will not 
expect, and raise the situation of potentially false validation 
warnings.

b.bum

Re: [Pyobjc-dev] NIB Validation & action methods

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

On Monday, Nov 18, 2002, at 16:01 Europe/Amsterdam, bb...@ma... wrote:

> On Sunday, November 17, 2002, at 02:06 AM, Ronald Oussoren wrote:
>> In Python you can also add new methods to a class. I'd not worry to 
>> much about this, if only because it will be less efficient to call 
>> those additional methods from Objective-C: The additional methods are 
>> called through an NSInvocation while the normal methods are called 
>> through more efficient method stubs.
>
> Efficiency of dispatch in this context is largely irrelevant as it 
> generally happens as a part of the user clicking a button or hitting a 
> menu item -- i.e. once to trigger the event processing.

It is not entirely irrelevant, some methods in the NSTableDataSource 
are called quite often and if those are slow this is noticable.

>
> Given that action method validation already exists within the AppKit 
> framework and it works at the only time where complete/correct 
> validation is possible, why should we bother duplicating that 
> functionality in the PyObjC module and doing so in a fashion that is 
> going to generate false warnings?

It might generate false warnings if the Python code adds new methods at 
runtime. Whenever I do things like that I prefer not to depend on 
automatic mechanisms likes Just's AutoBaseClass.

The other 'false' warnings are generated when actions have been defined 
in Interface Builder that are not yet used. I don't think these are 
false warnings at all, either the UI does not yet use the actions (e.g. 
this is a development version) or you're building up cruft in your NIB 
file.

Ronald

Re: [Pyobjc-dev] Separating functionality into modules

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

On Monday, Nov 18, 2002, at 16:19 Europe/Amsterdam, bb...@ma... wrote:

> On Sunday, November 17, 2002, at 08:41 AM, Ronald Oussoren wrote:
>> ...
>> It's missing documentation time again :-) :-). The glue code is where 
>> it is because you currently cannot avoid linking the PyObjC module 
>> with at least Foundation. This means that 
>> 'objc.lookup_class("NSSomeFoundationClass")' will always work and 
>> therefore the glue must be loaded in objc.__init__.
>>
>> I agree that users should avoid depending on this feature, if we at 
>> some point in time find a way to remove all dependencies on 
>> Foundation you will have to import Foundation to get access to those 
>> classes.
>
>
> You really *should* have to import the Foundation to work with the 
> Foundation classes.

I agree. You can only access Foundation (or AppKit) classes through the 
objc module if you use objc.lookup_class (soon to be objc.lookUpClass), 
or objc.class_list (soon to be objc.getClassList). These are low-level 
interfaces that are not very inviting to users, it is much more 
convenient to just import Foundation or AppKit. We should take care 
that we don't accidently export Cocoa classes/functions through the 
objc module in the future.

Ronald

Re: [Pyobjc-dev] Reason not to use the python based main

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

On Monday, November 18, 2002, at 03:23 PM, Just van Rossum wrote:
> Not sure if I follow you. I think both the main.m and the Python 
> execve wrapper
> can exist next to each other. I'll write the one, you the other ;-) 
> Peace...

I'll try to find time to respond to some of the other points in detail 
(as it is both very interesting, quite pertinent, and is making me 
think really hard about why I have the opinions that I do), but the 
above makes it all somewhat moot.

This sounds good to me-- I'm going to continue to use the compiled main 
in the context of the Project Builder project templates and I'll leave 
it to you/Jack/etc to come up with whatever works best for the 
standalone method of building apps (and I'll use it quite 
enthusiastically, when appropriate).

b.bum

Re: [Pyobjc-dev] Reason not to use the python based main

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

bb...@ma... wrote:

> On Monday, November 18, 2002, at 02:18 PM, Just van Rossum wrote:
> > Hm, basing a coding decision on one specific feature of one
> > specific IDE? Bleh...
> 
> Normally, I would agree... however, seeing that PBX is the standard and 
> free IDE included with the platform and, therefore, is accessible to 
> every single developer on the platform and that installation of the Dev 
> Tools also installs all the documentation that the developer needs for 
> effective development using PyObjC, it would seem that basic decisions 
> on the PBX IDE is in line with the desired direction for the module.

Ok. However, the tool I have in mind is not specific to pyobjc. (I personally
don't use PB yet, and I'm not sure I will anytime soon.)

> > - the current main.m doesn't work if the python executable isn't 
> > /usr/bin/python
> 
> Not true;  set PythonBinPath default to whatever you want.

Ok, I see the [NSUserDefaults standardUserDefaults] line. User defaults? How
does this work? Is it an entry in the Info.plist? If so, how come that's called
a user default? It it really _is_ a user default: it should be an app setting.

> > - it's 50 lines of dense Obj-C code instead of 5 sparse lines of Python
> 
> 50 lines that no developer ever has to look at;  plus, that 50 lines 
> packs quite a few more features into than the 5 lines of python.

I had to look at it the first time I tried to use it with a different Python
than the 10.2-shipped.

> > - the executable can't easily be created from a template
> 
> Why would it need to be created from a template?  Once the executable 
> exists-- it could/should be shipped as a part of the PyObjC module-- it 
> can be copied into any application and it will "just work".  It can be 
> renamed, if so desired.

Ok. However, the idea to just make a custom execve wrapper which (eg.) hardcodes
the real executable and/or the main Python program appleals to me. It's just so
simple.

> > - it depends on dev-tools being available, can't be built from pure 
> > Python
> 
> Why would it need to be compiled?  It "just works" as is.  Just copy it.

True. But what if you'd want to muck with argv before passing it along to the
child process?

> > - why would one _ever_ want to use Obj-C if the same can be done in
> > Python and speed is not an issue?
> 
> I was kind of expecting to see a :-) on that statement. 

Ok, just to make that 100% clear: I'm not even kidding ;-)

> Python is a wonderful language, but there is a lot of value in other
> languages...

Sure. Obj-C may kick some major butt compared to C (or even C++), but compared
to Python it's a big fat pain in the butt. Hey, a language war! ;-)

> In any case, the ObjC version offers features that cannot be 
> implemented in Python. Notably, the automatic handling and loading of 
> frameworks cannot be done without some manual effort on the part of the 
> developer. 

I don't follow this. Why would you load Frameworks in main.m if you're
execve-ing another _process_?

> The current bin-python-main.m allows the developer to link 
> the frameworks into the project as they would in any normal PBX based 
> project and the __main__.py and bin-python-main.m will take care of 
> ensuring that they are also dynamically loaded once control is turned 
> over to the python interpreter.

Ok, I guess I'll have to learn more about this. Isn't "import AppKit" all that's
needed?

> Of course, all of this is just a workaround until Apple ships an 
> embeddable interpreter [though, even once they do, it may be sometime 
> before everyone in the market has upgraded to a version of the OS with 
> the appropriate dylib in place].

I actually _like_ the flexibility of doing an execve. Bootstrapping code in
Python, what more could one want? ;-)

> The point of the PyObjC bridge is to provide a transparent bridge 
> between Python and Objective-C such that a developer can freely mix and 
> match the two at will.   The compiled executable based approach 
> preserves the full OS X development experience for those that choose it 
> while taking away nothing from those that choose to go the pure-Python, 
> non Apple Dev Tools, approach.   The same cannot be said for the pure 
> python main.

But it remains purely an IDE problem, no?

> There isn't a reason-- beyond yet-another-moving-part-to-maintain-- 
> that we can't ship both.

Not sure if I follow you. I think both the main.m and the Python execve wrapper
can exist next to each other. I'll write the one, you the other ;-) Peace...

Just

Re: [Pyobjc-dev] Reason not to use the python based main

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

On Monday, November 18, 2002, at 02:18 PM, Just van Rossum wrote:
> Hm, basing a coding decision on one specific feature of one specific 
> IDE?
> Bleh...

Normally, I would agree... however, seeing that PBX is the standard and 
free IDE included with the platform and, therefore, is accessible to 
every single developer on the platform and that installation of the Dev 
Tools also installs all the documentation that the developer needs for 
effective development using PyObjC, it would seem that basic decisions 
on the PBX IDE is in line with the desired direction for the module.

> - the current main.m doesn't work if the python executable isn't 
> /usr/bin/python

Not true;  set PythonBinPath default to whatever you want.

> - it's 50 lines of dense Obj-C code instead of 5 sparse lines of Python

50 lines that no developer ever has to look at;  plus, that 50 lines 
packs quite a few more features into than the 5 lines of python.

> - the executable can't easily be created from a template

Why would it need to be created from a template?   Once the executable 
exists-- it could/should be shipped as a part of the PyObjC module-- it 
can be copied into any application and it will "just work".  It can be 
renamed, if so desired.

> - it depends on dev-tools being available, can't be built from pure 
> Python

Why would it need to be compiled?  It "just works" as is.  Just copy it.

> - why would one _ever_ want to use Obj-C if the same can be done in 
> Python and
>   speed is not an issue?

I was kind of expecting to see a :-) on that statement.  Python is a 
wonderful language, but there is a lot of value in other languages...

In any case, the ObjC version offers features that cannot be 
implemented in Python. Notably, the automatic handling and loading of 
frameworks cannot be done without some manual effort on the part of the 
developer.  The current bin-python-main.m allows the developer to link 
the frameworks into the project as they would in any normal PBX based 
project and the __main__.py and bin-python-main.m will take care of 
ensuring that they are also dynamically loaded once control is turned 
over to the python interpreter.

Of course, all of this is just a workaround until Apple ships an 
embeddable interpreter [though, even once they do, it may be sometime 
before everyone in the market has upgraded to a version of the OS with 
the appropriate dylib in place].

The point of the PyObjC bridge is to provide a transparent bridge 
between Python and Objective-C such that a developer can freely mix and 
match the two at will.   The compiled executable based approach 
preserves the full OS X development experience for those that choose it 
while taking away nothing from those that choose to go the pure-Python, 
non Apple Dev Tools, approach.   The same cannot be said for the pure 
python main.

There isn't a reason-- beyond yet-another-moving-part-to-maintain-- 
that we can't ship both.

b.bum

Re: [Pyobjc-dev] Reason not to use the python based main

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

bb...@ma... wrote:

> I ran into the single biggest reason not to use a pure python main this 
> morning.  Project Builder's indexing relies on the use of header files 
> to determine what to index.  As such, if I link Cocoa, AppKit, and 
> Foundation into my application as I build main.m, all three framework's 
> documentation and headers will be fully indexed by PBX such that I can 
> easily and very quickly access it through cmd or opt double-clicking.
> 
> Very, very handy.

Hm, basing a coding decision on one specific feature of one specific IDE?
Bleh...

> Now, of course, this doesn't mean we couldn't use a python based main 
> and provide a different NSExecutableFile key/value in the information 
> bundle while continuing to build a binary with all the frameworks for 
> indexing purposes, but why bother when we already have a 
> bin-python-main.m that works quite well, if fully Cocoa compliant, and 
> has some additional features already implemented that are extremely 
> convenient as the size of a project grows?

- the current main.m doesn't work if the python executable isn't /usr/bin/python
- it's 50 lines of dense Obj-C code instead of 5 sparse lines of Python
- the executable can't easily be created from a template
- it depends on dev-tools being available, can't be built from pure Python
- why would one _ever_ want to use Obj-C if the same can be done in Python and
  speed is not an issue?

Questions:
- what's not Cocoa-compliant about the current Python solution?
- what are the additional features of main.m?

Just

[Pyobjc-dev] Reason not to use the python based main

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

I ran into the single biggest reason not to use a pure python main this 
morning.  Project Builder's indexing relies on the use of header files 
to determine what to index.  As such, if I link Cocoa, AppKit, and 
Foundation into my application as I build main.m, all three framework's 
documentation and headers will be fully indexed by PBX such that I can 
easily and very quickly access it through cmd or opt double-clicking.

Very, very handy.

Now, of course, this doesn't mean we couldn't use a python based main 
and provide a different NSExecutableFile key/value in the information 
bundle while continuing to build a binary with all the frameworks for 
indexing purposes, but why bother when we already have a 
bin-python-main.m that works quite well, if fully Cocoa compliant, and 
has some additional features already implemented that are extremely 
convenient as the size of a project grows?

b.bum

Re: [Pyobjc-dev] NibLoader.py: parsing nibs at runtime

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

Works for me.  I have a bunch of 2-space code I need to convert to 
4-space and I know there is a bunch of tab'd code that needs to be 
converted to 4-space.

What is the easiest way to do that?

On Sunday, November 17, 2002, at 04:52 PM, Jack Jansen wrote:
> I would be in favor of 4 space indenting, it's the Python standard. 
> The Mac subtree is the exception, and the only reason I haven't 
> switched yet is that it will make backward patches more difficult.

Re: [Pyobjc-dev] Separating functionality into modules

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

On Sunday, November 17, 2002, at 04:20 PM, Jack Jansen wrote:
> So let me see whether I understand the separation, and give some other 
> random musings.
>
> 1. objc contains the bridge: magic glue that the Python programmer 
> doesn't see,
>    plus stuff that is essential for talking to any ObjC based 
> framework. It
>    depends on Foundation, but this is also true for ObjC programmers, 
> really.
> 2. Foundation is a one-to-one mapping of the Foundation framework. 
> Some of the
>    classes may have more functionality on the Python side, some less, 
> but that
>    is minimal and should be "reasonably obvious".
> 3. AppKit idem ditto.
> 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.

With that said, no, there isn't any particular reason why it needs to 
be a part of the core PyObjC project.  Certainly, for app distribution 
services, being able to trim out chunks is attractive in that it 
reduces size.  However, we already have that ability -- just don't copy 
AddressBook or AppKit into your distribution, if you don't need them.

I could go either way on this one...

> 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?   There is the Nib loader in AppKit and a handful of utility 
functions in Foundation (convert between Python and ObjC collections -- 
need to do the other half of that someday), but a lot of the 
functionality is glue that makes the various classes behave better on 
one side of the bridge or the other.

I used pprint(dir(Foundation))...

Now, I can certainly imagine that the glue will grow over time, but-- 
likely-- not to a huge degree.

I like the idea of prefixing things with 'PyObjC' -- the extra 
characters guarantee we won't hit a conflict and make it clear where 
the functionality is coming from.  I.e. AppKit.PyObjCNibLoader -- or, 
maybe better?, AppKit.pyobjc.NibClassBuilder or 
AppKit.PyObjC.NibClassBuilder?    Actually, AppKit.Python.... isn't 
that bad either, but using 'Python' leaves us open to namespace 
conflicts (what if a developer provides a 'Python' class in their 
runtime?)

> 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...

> As to documentation: documenting the bridge (i.e. the objc package) is 
> the most important. This is the documentation that everyone will need, 
> including seasoned ObjC programmers. Second comes more user-manual 
> style documentation, such as instructions for integrating Python code 
> and ObjC in PB and using IB from Python (this sort of thing is more 
> easily learnt by studying examples than the bridge itself, hence I 
> think the objc documentation is the more important one). Third comes 
> the documentation describing the differences between our 
> Foundation/AppKit and ObjC's one.

Agreed.

> 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).

Yes;   how about something like....

 >>> sys.version_info
(2, 2, 0, 'final', 0)
 >>> sys.version
'2.2 (#1, 07/14/02, 23:25:09) \n[GCC Apple cpp-precomp 6.14]'

> Actually, why not put a version number in everything? I can imagine 
> updating AppKit (because Apple has added functionality, for instance) 
> without necessarily updating the rest.

Agreed.   Depending on which direction the GnuStep port takes, we could 
end up with two Foundation and two AppKit modules that are on 
differently development tracks.   Maybe even something that works like 
os.path that makes the fairly severe differences between different 
implementations of the AppKit relatively transparent.

And if Sun were to ever break out their implementation of the AppKit 
(which was pretty damned excellent, btw), then we would already have 
the code in place to handle yet-another-variant. :-)  (No, I don't 
believe there is a chance of that happening... but strangers things 
*have* happened.)

b.bum

Re: [Pyobjc-dev] Separating functionality into modules

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

On Sunday, November 17, 2002, at 09:00 AM, Ronald Oussoren wrote:
> I don't think we can do much about what help(Foundation) will show: 
> The pydoc
> module (where help is defined) performs introspection to generate 
> documentation
> for a module. I did notice that help(Foundation) and help(AppKit) use 
> up quite
> a lot of CPU time, but haven't checked if this is caused by 
> inefficiencies in PyObjC or by the sheer size of those modules. If you 
> use 'pydoc -w' on those modules you'll get enormous HTML files.

The documentation generated via introspection should likely be dumped.  
  Actually, it should be moved into a command line tool because it is 
useful, it just isn't what we want the developer to use to figure out 
what methods and classes are available.

Not because of the CPU time consumed, but because of the information 
presented to the developer.  The problem with help(Foundation) and 
help(AppKit) is that they both reveal every nasty little detail about 
Apple's implementation of the Foundation and AppKit.   While this is 
very interesting, it is not the API the developer should be using in 
any but the most extreme of circumstance.

The developer should use the API as advertised by the header files and 
documentation.

b.bum