pyobjc-dev — CVS commit notices go here

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

Re: [Pyobjc-dev] Separating functionality into modules

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

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.

Right.  We are really talking about two things here;  the dependency on 
Foundation in objc's [current and likely forever] implementation and 
the presence of glue code used by the PyObjC developer when using the 
objc module.

The dependency isn't an issue -- it is purely a part of the current 
implementation and is not something that the developer need be aware of.

It is the access to the Foundation based functionality through the objc 
module that is problematic.  Specifically, it puts us in an 'all or 
none' situation and raises the question as to whether or not their is 
any value in the Foundation module at all;  should it be rolled into 
objc?

For a number of reasons, I don't think it should even if what remains 
is just a name.  In particular, you import the objc module if you want 
to use the ObjC runtime, you import Foundation to use the Foundation 
framework, etc...

It would seem to be a division that maps naturally to what is 
advertised through the rest of the system, both GnuStep and Apple's 
runtime.

You really *should* have to import the Foundation to work with the 
Foundation classes.

> And with respect to building classtrees that are not rooted at 
> NSObject/NSProxy: We need to document what part of the NSObject API 
> must be implemented if you want to use PyObjC to wrap those classes. 
> This includes the reference counting API's, but there's probably more.

We should also strive to not require more implementation than is 
required to, say, use Object/HashTable/List, etc...

The reference counting APIs aren't strictly necessary in that context, 
nor should they be in the context of the PyObjC bridge.  If they aren't 
present, it is entirely up to the developer to invoke -free as required 
-- i.e. manage the object's lifespan entirely manually.

All in all, not something worth spending much time on at this point.

b.bum

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

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

On Sunday, November 17, 2002, at 02:15 AM, Ronald Oussoren wrote:
> Is this documented somewhere. I knew that the NSNibLoader class does  
> something like this, but I didn't find information about it in the  
> documentation at the time (early this summer, when Jack surprised me  
> by using outlets when I was sure I hadn't added support for them yet)

Have a look at:

file://localhost/Developer/Documentation/Cocoa/TasksAndConcepts/ 
ProgrammingTopics/LoadingResources/index.html

Specifically, at 'Nib Connectors'.  The last paragraph:

NSNibOutletConnector class manages an outlet connection in Interface  
Builder. The label is of the form "value". If the source contains a  
method of the form setValue: , then that method is called with the  
destination as the argument. Otherwise, if the label is the name of an  
instance variable in the source, then that instance variable is set to  
the destination.

Also, this is useful to gain a quick understanding of File's Owner and  
First Responder:

file://localhost/Developer/Documentation/Cocoa/TasksAndConcepts/ 
ProgrammingTopics/LoadingResources/Concepts/SpecialElements.html

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

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

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.

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?

b.bum

Re: [Pyobjc-dev] buildapplication strawman

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

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?

A few comments.

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

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

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

Further things I'd like to do:

- Change it to use the os.execve() trick.

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

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

- A strip binaries option. Hm, evil? Could save a huge amount of disk space,
  though.

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.

Speaking of sys.path: why does the objc module muck with it? Can't we solve this
some other way? I really dislike imports with such side effects. (It has already
confused me to no end: modules that I knew were in the current directory
couldn't be found after "import objc"...) An option would be for the os.execve()
wrapper to add Contents/Resources/ to the path through $PYTHONPATH.

Just

Re: [Pyobjc-dev] buildapplication strawman

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

Jack Jansen wrote:

> Your code appears to be a modified version of 
> Mac/script/buildappbundle.py, or is the similarity a coincidence? 

Heh, I hadn't seen that one! D'oh. I only saw the bundle support in
buildtools.py which I didn't like all that much. I'll have a closer look at
yours later, and think about how to develop it further. I definitely think it
should be a module, not just a script. Any thoughts about whether to use
distutils or not?

(I remember we both once wrote a CFM module without knowing it of each other,
and at some point I couldn't tell anymore who wrote which one...)

Just

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

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

On zondag, nov 17, 2002, at 15:12 Europe/Amsterdam, Ronald Oussoren 
wrote:
> Now that we're discussing relegion: How about indendation. I currently 
> use TAB to indent, but after looking through some PEPs recently I get 
> the feeling that this is not the right way(tm) to format code. Should 
> we reformat into 4-space indents?

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.
--
- 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...@or...>]

On zondag, nov 17, 2002, at 21:44 Europe/Amsterdam, Just van Rossum 
wrote:

> I'd like to turn it into a module, refactored in a nicely extensible 
> way.

Your code appears to be a modified version of 
Mac/script/buildappbundle.py, or is the similarity a coincidence? 
Anyway, my plan was to put the buildappbundle functionality into 
Mac/Lib/buildtools.py when I find the time for it. Putting your 
buildapp functionality in there as well should be a minor task. And 
then the code should be factored into an OS9-only bit (which would have 
all the MacPython-specific stuff dealing with opening resource forks 
and such) that wouldn't be imported if we're on OSX.

>  The
> next step would be to plug in freeze's module finder and (optionally) 
> copy all
> modules the main program depends on to Contents/Resources as well. An
> interesting middle way might be to _only_ copy those modules that are 
> not
> shipped by Apple (ie. only everything in site-packages and sys.path 
> entries not
> enclosed in sys.prefix + "/lib/python<version>/").

Great minds think alike:-) I was just thinking the same thing when 
cycling home today: freeze's module finder should get an optional 
argument that would make it skip any modules in the standard python 
distribution. This is fairly simple: any sys.path entry that starts 
with sys.prefix or sys.exec_prefix except for site-packages could be 
considered the standard distribution.
--
- 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] New version of Nib* from Just

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

bb...@ma... wrote:

> > (Btw., regarding your recent mistake if subclassing from the
> > NibLoader _module_: I was surprised that that actually _works_...
> > It doesn't in 2.3a, though, although the error message is not
> > exactly clear.)
> 
> It didn't work and the error message was not at all clear.

Sorry, I meant that subclassing from a _module_ actually "worked", in that the
subclassing per se didn't raise an exception. _Using_ the class was another
issue of course... Here's what I mean:

  Python 2.2 (#1, 07/14/02, 23:25:09) 
  [GCC Apple cpp-precomp 6.14] on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import StringIO
  >>> class MyStringIO(StringIO): pass
  ... 

  Python 2.3a0 (#2, Nov 17 2002, 18:16:38) 
  [GCC 3.1 20020420 (prerelease)] on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import StringIO
  >>> class MyStringIO(StringIO): pass
  ... 
  Traceback (most recent call last):
    File "<stdin>", line 1, in ?
  TypeError: function takes at most 2 arguments (3 given)
  >>> 

Just

Re: [Pyobjc-dev] Separating functionality into modules

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

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?

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.

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

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.

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

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.
--
- 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] New version of Nib* from Just

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

On Sunday, November 17, 2002, at 12:00 PM, Just van Rossum wrote:
> I would suggest to always write it as:
>
>   from AppKit.NibClassBuilder import extractClasses, AutoBaseClass
>   extractClasses("MainMenu")
>   class DeDatAppDelegate(AutoBaseClass, NSDraggingDestination):
>        ....
>
> This is how the generated template does it, too. (I somehow dislike 
> subclassing
> from dotted names...)

I agree regarding subclassing, but I don't like polluting the local 
namespace with things like 'extractClasses' as they give no indication 
as to where they came from the in the code.  It is one thing to do 
'from types import *' -- the types are all fairly specific in their 
naming and function -- but entirely a different thing to stick in 
something like extractClasses.

So, I end up with this...

from AppKit import NibClassBuilder
from AppKit.NibClassBuilder import AutoBaseClass
...
NibClassBuilder.extractClasses( "MainMenu" )
class DeDatAppDelegate(AutoBaseClass, NSDraggingDestination):
     ....

... which I don't like either, but does eliminate the dotted 
subclassing.

> (Btw., regarding your recent mistake if subclassing from the NibLoader 
> _module_:
> I was surprised that that actually _works_... It doesn't in 2.3a, 
> though,
> although the error message is not exactly clear.)

It didn't work and the error message was not at all clear.

b.bum

[Pyobjc-dev] buildapplication strawman

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

I've attached a small and very quickly hacked up script that will build an
applet for the TableModel demo (the original, not #2). Drop it in that folder
and run it from the command line.

What it does is create a bunch of folders, copies a bunch of files, and poof,
there's an app. It basically does the same thing as Ronalds setup-app.py script,
except it doesn't depend in (MacPython's) buildtools.py, which in turn depends
on some Mac-specific modules not available in the Apple-shipped Python 2.2.

I'd like to turn it into a module, refactored in a nicely extensible way. The
next step would be to plug in freeze's module finder and (optionally) copy all
modules the main program depends on to Contents/Resources as well. An
interesting middle way might be to _only_ copy those modules that are not
shipped by Apple (ie. only everything in site-packages and sys.path entries not
enclosed in sys.prefix + "/lib/python<version>/").

It could in theory be a distutils extension, but I'm not sure that buys us much:
it only needs to copy files and compile .py files into .pyc (it doesn't do the
latter yet, though). On the other hand: py2exe is a distutils extension, and
that works wonderfully (it builds standalone Windows executables).

Comments?

Just

Re: [Pyobjc-dev] New version of Nib* from Just

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

bb...@ma... wrote:

> from AppKit import NibClassBuilder
> NibClassBuilder.extractClasses( "MainMenu" )
> class DeDatAppDelegate(ClassBuilder.AutoBaseClass, 
> NSDraggingDestination):
>      ....

I would suggest to always write it as:

  from AppKit.NibClassBuilder import extractClasses, AutoBaseClass
  extractClasses("MainMenu")
  class DeDatAppDelegate(AutoBaseClass, NSDraggingDestination):
       ....

This is how the generated template does it, too. (I somehow dislike subclassing
from dotted names...)

(Btw., regarding your recent mistake if subclassing from the NibLoader _module_:
I was surprised that that actually _works_... It doesn't in 2.3a, though,
although the error message is not exactly clear.)

Just

[Pyobjc-dev] New version of Nib* from Just

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

I proxied a commit from Just for the Nib loading mechanism.  It is now 
NibClassBuilder.

His log:

---
- renamed loadClassesEtc. to extractClasses(), has a signature
   is as discussed on the list (ie. can parse nibs by name or by
   path)
- added module doc string and variaus method doc strings
- renamed NibClassBuilder to _NibClassBuilder: AutoBaseClass is
   not the way it's done.
- allow extractClasses() to be called multiple times for one nib
   (well it was allowed, but now less double work is performed)
- normalized whitespace
---

Usage now looks like:

from AppKit import NibClassBuilder
NibClassBuilder.extractClasses( "MainMenu" )
class DeDatAppDelegate(ClassBuilder.AutoBaseClass, 
NSDraggingDestination):
     ....

I'm going to update the examples and the Cocoa-Python project this 
afternoon...

b.bum

[Pyobjc-dev] Tabs vs. Spaces

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

Please! Yes!  Move to spaces!  This causes a lot fewer problems when 
using an editor like TextEdit or Project Builder.  In the context of 
Project Builder, one can set it to only use spaces and, as such, cmd-[ 
and cmd-] dedent and indent the selection correctly (PB is actually not 
terribly painful to use as a Python editor).

When tabs are used, it is very easy to end up in a situation where the 
text is rendered such that two things look to be in the same scope, but 
one is not.

Spaces also make automatic processing and automatic generation of 
Python code a lot easier, in my experience.

b.bum

On Sunday, November 17, 2002, at 09:12 AM, Ronald Oussoren wrote:
> Now that we're discussing relegion: How about indendation. I currently 
> use TAB to indent, but after looking through some PEPs recently I get 
> the feeling that this is not the right way(tm) to format code. Should 
> we reformat into 4-space indents?

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

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

On Sunday, Nov 17, 2002, at 14:13 Europe/Amsterdam, Just van Rossum 
wrote:

> Jack Jansen wrote:
>
>> What I do wonder, though, is whether this should be in AppKit.
>> Shouldn't we try to keep AppKit clean, so the Apple documentation
>> completely describes it, and put our own PyObjC-specific stuff
>> elsewhere? There isn't a good place right now, I think, but now might
>> be a good time to add one ("PyObjC" comes to mind as a name). Or does
>> the objc package fit this bill?
>
> I agree with Jack. I also understand Bill's concern that
> NibLoader/NibClassBuilder is an AppKit only tool. That said, I think 
> it could be
> an options to _rename_ the objc package to PyObjC (or pyobjc, I don't 
> care
> much). This allows us to use that package _both_ as an interface to 
> objc as well
> as a collection of additional tools, that may or may not be specific 
> to AppKit,
> Foundation or whatever.
I'll have to put some more thought in this, but do want to add one 
point to the discussion: The module was named pyobjc before my rewrite. 
I dropped 'py' because I found it ugly and because it is not necessary.
>
> We should decide this pretty quickly, as I am with Bill that I think 
> we can
> expect a lot of interest to PyObjC in the near future, and the more 
> users are
> out there, the less we can afford such a change... And if we do rename 
> the objc
> package, that would be a great opportunity to review the names of 
> various other
> things as well. Eg. I don't think the python-style 
> all-lowercase-and-underscores
> fits particularly well with PyObjC, as all Apple's names use 
> [cC]amelCase. I
> would suggest (eg.) renaming lookup_class to lookupClass.
Good idea.


> A more religious issue (and therefore I shall not make a huge point of 
> it ;-):
Lets me get into my asbesteous suit before continuing...

>  I
> personally don't like spaces between parens in Python code. I can see 
> it works
> well for other languages, but IMO it doesn't fit Python at all. I'd 
> like to see
> foo(args) instead of foo( args ). A space _before_ an opening paren 
> _really_
> makes my stomach turn ;-)

That wasn't too bad, I feel the same. I also prefer to format my code 
in a simular way in C, with one minor variation: there whitespace 
between if/while/for and the following paren.

Now that we're discussing relegion: How about indendation. I currently 
use TAB to indent, but after looking through some PEPs recently I get 
the feeling that this is not the right way(tm) to format code. Should 
we reformat into 4-space indents?

Ronald

Re: [Pyobjc-dev] Separating functionality into modules

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

On Sunday, Nov 17, 2002, at 02:03 Europe/Amsterdam, bb...@ma... wrote:
[removed the most interesting part of this e-mail :-)]

> In any case, it would seem that help(Foundation) and help(AppKit) 
> should really only document the functionality that we provide or 
> modify.  If something works exactly like it does in ObjC-- i.e. is a 
> part of the Foundation or AppKit APIs-- then the developer should go 
> straight to the source, I would think...?

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.

Ronald

Re: [Pyobjc-dev] Separating functionality into modules

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

On Sunday, Nov 17, 2002, at 01:51 Europe/Amsterdam, Jack Jansen wrote:

>
> On zondag, nov 17, 2002, at 01:30 Europe/Amsterdam, bb...@ma... wrote:
>> None of this is to say that the extensions to the AppKit should not 
>> be separated out -- I have nothing against that, but I also am not 
>> strongly attracted to doing so.
>
> My main reason for suggesting this is support. If our AppKit is 
> Apple's AppKit except things we can't implement, and the 
> PyObjC-specific stuff (which either doesn't make sense for ObjC, or 
> which we've added because we think it's an omission on Apple's side) 
> is in a different place this should make it easier to look up stuff in 
> documentation. That should forestall questions to this group.

You have a point there. How can we provide a clear seperation between 
functionality in Apple's AppKit and our addons? The convenience stuff 
(special methods that allow you to access NSDictionary instances like 
Python dicts, etc.) can be left where they are. It's the addon APIs 
that should be clearly seperated from AppKit.

Placing the add-on functionality in submodules/packages of 
AppKit/Foundation (like we do now) should work. I'd prefer not to use 
submodules/packages of objc for this because we are the only ones that 
can do that. I'd prefer to lay down a coding style that allows 3th 
parties to wrap other frameworks (like the Omni frameworks) in a 
simular way to our wrapping of Cocoa.

> And I'm actually already slightly trembling at the thought of what 
> might happen once PyObjC gets decent exposure...

<movie src="ronald-nodding.mpg> I sure hope to find time to work on the 
documentation before the userbase gets significantly larger. We have 
been lucky so far, but if the userbase gets larger we will get users 
that (quite rightly) expect proper documentation.

Ronald

Re: [Pyobjc-dev] Separating functionality into modules

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

On Sunday, Nov 17, 2002, at 01:30 Europe/Amsterdam, bb...@ma... wrote:

> On Saturday, November 16, 2002, at 07:18 PM, Jack Jansen wrote:
>> What I do wonder, though, is whether this should be in AppKit. 
>> Shouldn't we try to keep AppKit clean, so the Apple documentation 
>> completely describes it, and put our own PyObjC-specific stuff 
>> elsewhere? There isn't a good place right now, I think, but now might 
>> be a good time to add one ("PyObjC" comes to mind as a name). Or does 
>> the objc package fit this bill?
>
> [The NibLoading mechanism] It makes more sense in AppKit than it does 
> in objc.   The PyObjC bridge can be used outside of the context of the 
> AppKit -- the AppKit is just a framework that adds a set of classes 
> for use within ObjC.   Same goes for Foundation, technically -- the 
> NSArray and NSDictionary glue should be moved into Foundation.
>
> That objc mixes in bits from Foundation and AppKit is a bug, really -- 
> though it also seems unavoidable in some cases.  The objc module 
> should provide only what is necessary to provide the Python<->ObjC 
> messaging bridge.   Anything specific to a particular framework should 
> be elsewhere.

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.

We currently use the following classes in the native code:
- NSMethodSignature, NSInvocation
   Used for calling Objective-C methods and required to fully support the
   reflection/invocation APIs for Python classes
- NSString, NSNumber
   used to automaticly convert strings and numbers from a python to an
   objective-c representation.
- NSException
   used for raising and catching Objective-C exceptions
- NSAutoreleasePool
   we allocate one when the module is loaded to avoid leaking objects 
(and
   generating tons of warnings until the user has created one)
- NSThread
   not used at the moment, but it will probably be necessary to use this
   class for fully supporting multithreading. We might get away with 
using
   the posix-threads API to store/create thread-local variables.

We also know about the existence of NSProxy because you shoudn't call a 
number of methods on it that we normally use. Given the list above I 
think it is quite unlikely that we'll ever be able to get rid of our 
dependencies on Foundation but you never know.

>
> This will greatly contribute to supporting GnuStep.   As well, it 
> makes it possible to use the bridge in contexts where one wants to use 
> just the runtime, but none of the Foundation/AppKit classes -- 
> Object/List/HashTable are still around and there are those [including 
> me] who occasionally build new sets of classes that are not rooted at 
> NSObject for research purposes.

GNUstep aims to implement the entire OpenStep API, and their Foundation 
support seems to be production-quality. The most problematic part of 
supporting GNUstep will probably not be their class library, but the 
differences between the GNU and NeXT/Apple Objective-C runtimes. PyObjC 
0.6 contained and abstraction layer to deal with most differences. This 
layer is still present, but I've probably broken it during my rewrite.

And with respect to building classtrees that are not rooted at 
NSObject/NSProxy: We need to document what part of the NSObject API 
must be implemented if you want to use PyObjC to wrap those classes. 
This includes the reference counting API's, but there's probably more.

I'm not entirely sure about the right location for NibLoader, but I 
think the current location as part of the AppKit package is a logical 
location.

Ronald

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

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

Jack Jansen wrote:

> What I do wonder, though, is whether this should be in AppKit. 
> Shouldn't we try to keep AppKit clean, so the Apple documentation 
> completely describes it, and put our own PyObjC-specific stuff 
> elsewhere? There isn't a good place right now, I think, but now might 
> be a good time to add one ("PyObjC" comes to mind as a name). Or does 
> the objc package fit this bill?

I agree with Jack. I also understand Bill's concern that
NibLoader/NibClassBuilder is an AppKit only tool. That said, I think it could be
an options to _rename_ the objc package to PyObjC (or pyobjc, I don't care
much). This allows us to use that package _both_ as an interface to objc as well
as a collection of additional tools, that may or may not be specific to AppKit,
Foundation or whatever.

We should decide this pretty quickly, as I am with Bill that I think we can
expect a lot of interest to PyObjC in the near future, and the more users are
out there, the less we can afford such a change... And if we do rename the objc
package, that would be a great opportunity to review the names of various other
things as well. Eg. I don't think the python-style all-lowercase-and-underscores
fits particularly well with PyObjC, as all Apple's names use [cC]amelCase. I
would suggest (eg.) renaming lookup_class to lookupClass.

A more religious issue (and therefore I shall not make a huge point of it ;-): I
personally don't like spaces between parens in Python code. I can see it works
well for other languages, but IMO it doesn't fit Python at all. I'd like to see
foo(args) instead of foo( args ). A space _before_ an opening paren _really_
makes my stomach turn ;-)

Just

Re: [Pyobjc-dev] Newer NibLoader.py

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

On Sunday, Nov 17, 2002, at 00:23 Europe/Amsterdam, Just van Rossum 
wrote:

> bb...@ma... wrote:
>
>> Assuming the changes are going to be relatively small from here out,
>> I'm going to change the Cocoa-Python project accordingly.
>
> I've submitted an sf support request regarding my cvs problems. In the 
> meantime,
> here is my working version, still named NibLoader.py. The command line 
> program
> prints a complete Python template, using AutoBaseClass. (I'll think a 
> bit more
> about your naming suggestions.) Currently the __metaclass__ = 
> NibClassLoader
> idiom still works, but I'm tempted to rip it out... I'd be interested 
> in
> comments from Ronald and Jack, though.

Just rip it out. AutoBaseClass documents quite nicely what's going on 
and for me __metaclass__ says 'look out! something fishy is going on'.

Ronald

Re: [Pyobjc-dev] Another naive question

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

On Sunday, Nov 17, 2002, at 00:50 Europe/Amsterdam, Just van Rossum 
wrote:

> bb...@ma... wrote:
>
>> [ ... ]   Unfortunately, from AppKit import NSApplication causes the
>> AppKit module to effectively visit every class in the runtime as a
>> part of initialization -- and this is quite expensive.
>
> Ah, so that's the bottleneck. I'd be intersted in figuring out whether 
> this can
> be done lazily, but I'll need to familiarize myself with the source 
> first...

The interesting part for this is the function load_bundle in 
Lib/Foundation/__init__.py. This loads a bundle and then loops through 
all classes in the runtime to find those that are defined in the just 
loaded bundle.

The expensive part is creating proxy classes for all classes in the 
objective-C runtime. If you do 'objc.lookup_class' PyObjC only creates 
proxies for the class itself and any superclasses. I've thought about 
initializing classes lazily, but need to look into the feasability of 
this: You must fully initialize the proxy class before creating the 
first instance of the class, otherwise method lookup might not work. 
Now that I write this down I start to think that this is possible to do 
this: We already have mechanism to detect if the method table of an 
Objective-C class has changed and might as wel use that for lazy 
initialization. I'll look into this.

Ronald

[Pyobjc-dev] (OT: my cvs problems)

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

This is the reply to my sf support request:

  """
  This is a temporary condition resulting from the physical
  relocation of hardware. It will be resolved after the
  completion of the Sunday outage.
  """

So I guess I'll be fine tomorrow...

Just