pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Examples/TableModel2 main.m,1.4,1.5

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

On vrijdag, nov 22, 2002, at 22:05 Europe/Amsterdam, Ronald Oussoren 
wrote:
> Sounds good, but how are you going to deal with moving the .app bundle 
> when not using /usr/bin/python? '#!../Resources/python-interpreter' 
> probably won't work.

Don't even bother trying it: I did, and it doesn't:-)

What we would need is a standard unix tool that we can give 1 argument 
and that would execute a mangled version of argv[0]. I don't think such 
a tool exists:-)
--
- 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] Re: [Pyobjc-checkins] CVS: pyobjc/Examples/TableModel2 main.m,1.4,1.5

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

I guess my long winded message was too long winded.  In short, PyObjC 
in the context of first-class development tool in conjunction with 
Apple's supplied IDE & APIs requires full support for frameworks;   
encapsulated within the app, modified by the DYLD environment 
variables, and working correctly within the Project Builder environment.

(Support for indexed docs within PBX is a nice bonus, but I can live 
without it)

b.bum

On Friday, November 22, 2002, at 05:27 PM, Just van Rossum wrote:
>> Just that no one has shown me that want I want to do in the main.m IS
>> possible in Python....
>
> But neither have you shown why it's all that _important_ to be able do 
> these
> things in main.m (apart from nicer PB integration)... But let's not go 
> there
> again ;-)

Re: [Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Examples/TableModel2 main.m,1.4,1.5

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

bb...@ma... wrote:

> Just that no one has shown me that want I want to do in the main.m IS
> possible in Python....

But neither have you shown why it's all that _important_ to be able do these
things in main.m (apart from nicer PB integration)... But let's not go there
again ;-)

Just

Re: [Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Examples/TableModel2 main.m,1.4,1.5

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

On Friday, November 22, 2002, at 04:52 PM, Just van Rossum wrote:
> Ronald Oussoren wrote:
>> BTW. There is no need to convince me about using Python instead of C 
>> :-)
> Oh, in my mind I was actually talking to Bill ;-)

Oh -- no need to do that -- I'm a firm believer in doing everything in 
Python whenever possible.  Just that no one has shown me that want I 
want to do in the main.m IS possible in Python....

b.bum

[Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Scripts nibclassbuilder,NONE,1.1 README,1.2,1.3

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

Ronald Oussoren wrote:

> --- NEW FILE: nibclassbuilder ---
> #!/usr/bin/env python
> from AppKit import NibClassBuilder
> NibClassBuilder.commandline()

I would actually name this script "makenibtemplate" (or even "mknibtemplate") as
to me that's closer to what the command line program actually does.

Just

Re: [Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Examples/TableModel2 main.m,1.4,1.5

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

Ronald Oussoren wrote:

> BTW. There is no need to convince me about using Python instead of C :-)

Oh, in my mind I was actually talking to Bill ;-)

> >   When building an applet:
> >   - append PYTHONPATH (not prepend as that kindof defeats its purpose)
> >
> >   When building a fully standalone app:
> >   - set PYTHONHOME to something inside the bundle, just to make sure
> >     no modules can be loaded from anywhere but the bundle
> >   - set or replace PYTHONPATH. A bogus PYTHONPATH could otherwise
> >     break the app.
> Sounds good, but how are you going to deal with moving the .app bundle 
> when not using /usr/bin/python? '#!../Resources/python-interpreter' 
> probably won't work. Standalone apps are probably the most important 
> for not using a python-based main.

It works by the assumption that there is _a_ python available as
/usr/bin/env python. This is safe as of Jaguar, unless someone has actually
deleted python. Tough luck for those. The _real_ (python) executable is copied
to Contents/Resources/ and the bootstrapping code calculates its path just like
it calculates the path to the real main script. It passes this path to
os.execve. The bundle can be moved anywhere.

Just

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

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

On Thursday, Nov 21, 2002, at 14:42 Europe/Amsterdam, Just van Rossum 
wrote:

> IMO Tools/mknibwrapper is obsolete now, but if we remove it the Tools 
> dir is
> empty apart from a README. It says:
>
>   Reserved for PyObjC related tools"
>
> However, Scripts/README says:
>
>   Reserved for PyObjC related scripts (for 'end-users')
>
> yet contains meta tools nevertheless. Shall I just clear out the 
> Tools/ dir and
> remove the "for end users" comment from Scripts/README?

So much for actually remembering why I create directories. I've removed 
the mknibwrapper script and added a nibclassbuilder script to Scripts. 
The Tools directory should be gone.

Ronald

[Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Examples/TableModel2 main.m,1.4,1.5

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

On Friday, Nov 22, 2002, at 21:45 Europe/Amsterdam, Just van Rossum 
wrote:

> Look, the patch below shows _exactly_ why I don't like the execve 
> wrapper to
> written in anything but Python. I can't even tell (but then again, I'm 
> lazy)
> whether this prepends or sets or appends PYTHONPATH. (Ronald, please 
> don't take
> this as an insult, the code is just fine, I'm just trying to make a 
> further
> argument for the Python version...)
No insult was taken. This appends to PYTHONPATH, doing it the other way 
around is probably better. I'll check-in a patch latter tonight.

BTW. There is no need to convince me about using Python instead of C :-)

>
> I will apply a similar patch to the execve wrapper, but I need to do 
> different
> things in different situations:
>
>   When building an applet:
>   - append PYTHONPATH (not prepend as that kindof defeats its purpose)
>
>   When building a fully standalone app:
>   - set PYTHONHOME to something inside the bundle, just to make sure
>     no modules can be loaded from anywhere but the bundle
>   - set or replace PYTHONPATH. A bogus PYTHONPATH could otherwise
>     break the app.
Sounds good, but how are you going to deal with moving the .app bundle 
when not using /usr/bin/python? '#!../Resources/python-interpreter' 
probably won't work. Standalone apps are probably the most important 
for not using a python-based main.

Ronald

[Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Examples/TableModel2 main.m,1.4,1.5

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

Look, the patch below shows _exactly_ why I don't like the execve wrapper to
written in anything but Python. I can't even tell (but then again, I'm lazy)
whether this prepends or sets or appends PYTHONPATH. (Ronald, please don't take
this as an insult, the code is just fine, I'm just trying to make a further
argument for the Python version...)

I will apply a similar patch to the execve wrapper, but I need to do different
things in different situations:

  When building an applet:
  - append PYTHONPATH (not prepend as that kindof defeats its purpose)

  When building a fully standalone app:
  - set PYTHONHOME to something inside the bundle, just to make sure
    no modules can be loaded from anywhere but the bundle
  - set or replace PYTHONPATH. A bogus PYTHONPATH could otherwise
    break the app.

With the Python version this is trivial to do. For main.c this would add yet
another 20 or so lines of terse C code.

Just


Ronald Oussoren wrote (on the checkins list):

> Update of /cvsroot/pyobjc/pyobjc/Examples/TableModel2
> In directory sc8-pr-cvs1:/tmp/cvs-serv9080
> 
> Modified Files:
>   main.m 
> Log Message:
> Set PYTHONPATH in main.m
> 
> Index: main.m
> ===================================================================
> RCS file: /cvsroot/pyobjc/pyobjc/Examples/TableModel2/main.m,v
> retrieving revision 1.4
> retrieving revision 1.5
> diff -C2 -d -r1.4 -r1.5
> *** main.m    18 Oct 2002 19:08:57 -0000  1.4
> --- main.m    22 Nov 2002 20:26:12 -0000  1.5
> ***************
> *** 22,25 ****
> --- 22,56 ----
>     NSMutableArray *bundlePaths = [[NSMutableArray array] retain];
>     int i;
> +   int envc;
> +   char** childEnvp;
> +   char*  PYTHONPATH = NULL;
> + 
> +   for (envc = 0; envp[envc] != NULL; envc++) {
> +     if (strncmp(envp[envc], "PYTHONPATH=", sizeof("PYTHONPATH=")-1) == 0) {
> +         PYTHONPATH=envp[envc] + sizeof("PYTHONPATH=") - 1;
> +         /* No break, we also want to know how large envp is */
> +     }
> +   } 
> + 
> +   childEnvp = alloca(sizeof(char*) * (envc + 2));
> +   for (envc = 0; envp[envc] != NULL; envc ++) {
> +     if (strncmp(envp[envc], "PYTHONPATH=", sizeof("PYTHONPATH=")-1) == 0) {
> +         const char* s = [[[NSBundle mainBundle] resourcePath] UTF8String];
> +         childEnvp[envc] = alloca(strlen(envp[envc]) + strlen(s) + 2);
> +         sprintf(childEnvp[envc], "%s:%s", envp[envc], s);
> + 
> +     } else {
> +         childEnvp[envc] = envp[i];
> +     }
> +   }
> +   if (PYTHONPATH) {
> +     envp[envc] = NULL;
> +   } else {
> +     const char* s = [[[NSBundle mainBundle] resourcePath] UTF8String];
> +     childEnvp[envc] = alloca(sizeof("PYTHONPATH=") + strlen(s));
> +     sprintf(childEnvp[envc], "PYTHONPATH=%s", s);
> +     childEnvp[envc+1] = NULL;
> +   }
> + 
>   
>     while ( aBundle = [bundleEnumerator nextObject] ) {
> ***************
> *** 56,60 ****
>     childArgv[i+3] = NULL;
>   
> !   return execve(pythonBinPathPtr, (char **)childArgv, envp);
>   }
>   
> --- 87,93 ----
>     childArgv[i+3] = NULL;
>   
> !   i = execve(pythonBinPathPtr, (char **)childArgv, (char**) childEnvp);
> !   if (i == -1) perror("execv");
> !   return 1;
>   }

Re: [Pyobjc-dev] new app-bundle-making-tools

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

Just van Rossum wrote:

> I have to verify that it works with a Framework build. I think it does, and if
> it doesn't it should be easily fixable. But I don't know yet...

I just tested it, it works. However, by default it will use whater "/usr/bin/env
python" yields, and that's usually stock Python 2.2. To build an applet that
actually uses Python.framework you currently have to invoke the build script
like so:

  % python buildapp.py -e /usr/local/bin/python build

(This is assuming /usr/local/bin/python is the Python.framework main executable)

The -e option specifies which executable to use, and copies this to the app
bundle. The Python.framework main executable is only 16k, but to save even those
16k you can use the --link-exec option which adds a symbolic link to the
executable instead of a copy. The TableModel applet is then under 10000 bytes
(although the Finder calls that 56k...).

Just

Re: [Pyobjc-dev] new app-bundle-making-tools

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

Ronald Oussoren wrote:

> I haven't looked seriously at bundlebuilder.py yet, but from what I've 
> seen I'm all for using this instead of the current 'setup-app.py' 
> scripts.

I have to verify that it works with a Framework build. I think it does, and if
it doesn't it should be easily fixable. But I don't know yet...

> How are we going to deal with the poor souls that haven't installed 
> Python 2.3 or the MacPython 2.2 addon Jack's working on? Should we ship 
> a copy of bundlebuilder.py with PyObjC?

Yeah, I would do that. (It depends on plistlib.py, but other than that it's
completely independent, and runs as is on a vanilla 2.2.)

> BTW. I noticed that the python-based execve wrapper sets PYTHONPATH 
> instead of updating it. Is that intentional?

Ah, so you _have_ seriously looked at it ;-) I haven't thought about it much, I
guess it's wrong. Would this be better:

if os.environ.get("PYTHONPATH"):
    os.environ["PYTHONPATH"] = resources + ":" + os.environ["PYTHONPATH"]
else:
    os.environ["PYTHONPATH"] = resources

?

Just

Re: [Pyobjc-dev] new app-bundle-making-tools

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

I haven't looked seriously at bundlebuilder.py yet, but from what I've 
seen I'm all for using this instead of the current 'setup-app.py' 
scripts.

How are we going to deal with the poor souls that haven't installed 
Python 2.3 or the MacPython 2.2 addon Jack's working on? Should we ship 
a copy of bundlebuilder.py with PyObjC?

BTW. I noticed that the python-based execve wrapper sets PYTHONPATH 
instead of updating it. Is that intentional?

Ronald

On Friday, Nov 22, 2002, at 13:39 Europe/Amsterdam, Just van Rossum 
wrote:

> Just van Rossum wrote:
>
>>   Mac/Lib/bundlebuilder.py -- tools to assemble bundles
>
> Btw. this tool employs the execve wrapper and I've changed it so it'll 
> set
> $PYTHONPATH to <app>/Contents/Resources folder. So if Bill adds the 
> same to his
> main.m, I think it's safe to get rid of the sys.path munging code in
> objc.__init__.py.
>
> Just
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] new app-bundle-making-tools

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

Just van Rossum wrote:

>   Mac/Lib/bundlebuilder.py -- tools to assemble bundles

Btw. this tool employs the execve wrapper and I've changed it so it'll set
$PYTHONPATH to <app>/Contents/Resources folder. So if Bill adds the same to his
main.m, I think it's safe to get rid of the sys.path munging code in
objc.__init__.py.

Just

Re: [Pyobjc-dev] CVS commit notifs

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

Ronald Oussoren wrote:

> Just to add some more noise :-) I'd like to have checkin list with 
> diffs in the messages. The rate of development is currently not large 
> enough to start worrying about the amount of messages.

(Just so everyone knows: Bill created the list yesterday
(pyo...@li...) and I set up the syncmail script. It
already works, perhaps Bill wanted to wait with the announcement until he
finishes his perfect script? ;-)

Just

Re: [Pyobjc-dev] CVS commit notifs

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

Just to add some more noise :-) I'd like to have checkin list with 
diffs in the messages. The rate of development is currently not large 
enough to start worrying about the amount of messages.

Ronald

On Friday, Nov 22, 2002, at 00:44 Europe/Amsterdam, Just van Rossum 
wrote:

> bb...@ma... wrote:
>
>> I like the diffs a lot, but I don't like receiving 85 bazillion
>> messages (as I do from Barry's mailman checkin lists).
>
> I don't understand why you're making such a big deal out of this. I 
> subscribe to
> python-checkins (pretty high volume), and I selectively read the 
> things I'm
> interested in. It goes really quickly: 
> arrowdown-arrowdown-arrowdown-etc. ;-)
> The PyObjC project isn't _that_ big, and there aren't _that_ many 
> active
> developers so I'm sure it'll be managable even for you...
>
> And note that only the commit _log_ is duplicated over several 
> messages for a
> big checkin (and again, how common are these? not very I would think), 
> the
> _diff_ better be different <wink>, so it's not like you're getting all 
> that much
> redundant data.
>
>> So, clearly, neither script will work 100% for me and, given that I
>> have a million things much more important to do, I'll have to merge 
>> our
>> two scripts to put together the Super Cool CVS Commit Auto-Email
>> Coalescer & Differentiation Mechanism.
>
> If that scratches your itch...
>
> Just
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] CVS commit notifs

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

bb...@ma... wrote:

> I like the diffs a lot, but I don't like receiving 85 bazillion 
> messages (as I do from Barry's mailman checkin lists).

I don't understand why you're making such a big deal out of this. I subscribe to
python-checkins (pretty high volume), and I selectively read the things I'm
interested in. It goes really quickly: arrowdown-arrowdown-arrowdown-etc. ;-)
The PyObjC project isn't _that_ big, and there aren't _that_ many active
developers so I'm sure it'll be managable even for you...

And note that only the commit _log_ is duplicated over several messages for a
big checkin (and again, how common are these? not very I would think), the
_diff_ better be different <wink>, so it's not like you're getting all that much
redundant data.

> So, clearly, neither script will work 100% for me and, given that I 
> have a million things much more important to do, I'll have to merge our 
> two scripts to put together the Super Cool CVS Commit Auto-Email 
> Coalescer & Differentiation Mechanism.

If that scratches your itch...

Just

[Pyobjc-dev] new app-bundle-making-tools

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

I checked in two new modules in the Mac subtree of the Python project:

  Mac/Lib/bundlebuilder.py -- tools to assemble bundles
  Mac/Lib/plistlib.py -- generating and parsing plists

I also added a script to the pyobjc/Examples/TableModel/ demo that uses
bundlebuilder. It's called buildapp.py and looks like this:

  #
  # Successor of setup-app.py. Run this program from the command line like so:
  #
  # % python buildapp.py build
  #
  
  from bundlebuilder import buildapp
  
  buildapp(
      mainprogram = "TableModel.py",
      resources = ["English.lproj"],
      nibname = "MainMenu",
  )

Be sure to also try

  % python buildapp.py help

for an overview of options.

It isn't all that different from setup-app.py, but I didn't want to break that
one just yet... bundlebuilder.py and plistlib.py don't depend on any
Mac-specific modules, nor do they depend on pyobjc.

The next thing on my list is to enhance bundlebuilder to use modulefinder to
find all module dependencies and copy all the needed modules to the app bundle
to create a truly standalone application.

Just

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

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

bb...@ma... wrote:

> I have no particular affection for any of this.
> 
> One opinion:  I would like to see a series of scripts that wrap the 
> various tools found in other parts of the module-- some of which is in 
> Lib/*/*-- such that the scripts are installed into /usr/local/bin/ (or 
> /usr/bin/) as per a normal install.
> 
> I don't like scripts that act as a module in one form and a command 
> line tool in another.   I would much rather the command line driver 
> part simply use the separate module -- it keeps the module clean and 
> moves all the command line arg processing/validation to an isolated 
> spot that provides an excellent and clean example of how to work with 
> the module.

Hm, maybe. I prefer to keep things together unless they become too big.
NibClassBuilder isn't all that big I think.

> The auto-nib stuff that can dump a class template is a perfect 
> example....

Hm, I'd agree from the standpoint that this module isn't readily accessible as a
command line too. Why not add a script to Scripts that goes like this:

#!/usr/bin/env python
from AppKit import NibClassBuilder
NibClassBuilder.commandline()

Add it to setup.py as a script and it'll be installed globally, too.

Just

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

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

I have no particular affection for any of this.

One opinion:  I would like to see a series of scripts that wrap the 
various tools found in other parts of the module-- some of which is in 
Lib/*/*-- such that the scripts are installed into /usr/local/bin/ (or 
/usr/bin/) as per a normal install.

I don't like scripts that act as a module in one form and a command 
line tool in another.   I would much rather the command line driver 
part simply use the separate module -- it keeps the module clean and 
moves all the command line arg processing/validation to an isolated 
spot that provides an excellent and clean example of how to work with 
the module.

The auto-nib stuff that can dump a class template is a perfect 
example....

b.bum
(eod, brain done)

On Thursday, November 21, 2002, at 08:42 AM, Just van Rossum wrote:
> yet contains meta tools nevertheless. Shall I just clear out the 
> Tools/ dir and
> remove the "for end users" comment from Scripts/README?

[Pyobjc-dev] CVS commit notifs

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

I like the diffs a lot, but I don't like receiving 85 bazillion 
messages (as I do from Barry's mailman checkin lists).

So, clearly, neither script will work 100% for me and, given that I 
have a million things much more important to do, I'll have to merge our 
two scripts to put together the Super Cool CVS Commit Auto-Email 
Coalescer & Differentiation Mechanism.

b.bum

On Thursday, November 21, 2002, at 04:21 PM, Jack Jansen wrote:
> On donderdag, nov 21, 2002, at 16:49 Europe/Amsterdam, Just van Rossum 
> wrote:
>> I'm on one CVS checkins list that _doesn't_ add diffs: it's useless 
>> for me. I
>> need to see what happened.
>
> Same for me: I see the checkin mailing list as a low-impact form of 
> peer review. As long as there's context diffs I don't care whether it 
> uses Barry's script or Bill's.

Re: [Pyobjc-dev] NibClassBuilder change

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

On donderdag, nov 21, 2002, at 16:49 Europe/Amsterdam, Just van Rossum 
wrote:
> I'm on one CVS checkins list that _doesn't_ add diffs: it's useless 
> for me. I
> need to see what happened.

Same for me: I see the checkin mailing list as a low-impact form of 
peer review. As long as there's context diffs I don't care whether it 
uses Barry's script or Bill's.
--
- 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 woensdag, nov 20, 2002, at 19:39 Europe/Amsterdam, Just van Rossum 
wrote:

> Jack Jansen wrote:
>
>> Let's go all the way and put the Mac/Lib stuff where it belongs,
>
> Ok, but then surely a symlink in the repository would be better than a 
> copy?

No, because we're going to "cvs remove" everything in Mac/Lib in the 
trunk, and "cvs remove" lib-mac in the 2.2 maintainance branch.
--
- 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] nitpicking: lookUpClass vs. lookupClass

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

bb...@ma... wrote:

> /usr/include/objc/objc-runtime.h:OBJC_EXPORT id objc_lookUpClass(const 
> char *name);

Ah, that settles that. Perfect. Sorry for bringing it up!

Just

Re: [Pyobjc-dev] NibClassBuilder change

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

bb...@ma... wrote:

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

Great.

> Assuming python is available on the cvs server [I believe it is],

It is.

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

Does it add a (context) diff to the message?

There's a Python script on SF that's developed by Barry Warsaw (I think, could
have been Fred Drake or both) that various Python projects use on SF (including
my own fonttools project) and I love it.

Yes, it does send one message per directory, but how common are huge patches
that touch large numbers of folders? (And if they _are_ common, I think there's
something horribly wrong...)

I'm on one CVS checkins list that _doesn't_ add diffs: it's useless for me. I
need to see what happened.

Besides, if the amount of messages bothers you, you can always set your
subscription to digest ;-)

Just

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

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

On Thursday, November 21, 2002, at 09:22 AM, Just van Rossum wrote:
> I see Ronald has renamed lookup_class to lookUpClass. I would have 
> expected
> lookupClass (with a lowercase u) as I tend to think of "lookup" as one 
> word.
> Since english isn't my native tongue I can't really judge whether that 
> is
> correct, or whether it really matters...

We should follow the "conventions" as set forth in the ObjC API:

[bumbox:IssueCenter/V3/Python] bbum% grep -i lookup 
/usr/include/objc/*.h
/usr/include/objc/objc-runtime.h:OBJC_EXPORT id objc_lookUpClass(const 
char *name);

b.bum