pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] top level namespaces

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

On Saturday, Feb 1, 2003, at 21:08 Europe/Amsterdam, Bill Bumgarner 
wrote:

> On Saturday, Feb 1, 2003, at 15:02 US/Eastern, Tony Lownds wrote:
>> Hi,
>> At 2:15 PM -0500 2/1/03, Bill Bumgarner wrote:
>>> As Just mentioned, it is about time to do a 0.9 release.
>> Out of curiosity, will 0.9 be FFI only?
>
> Good question.   Personally, I think it should be for two reasons:
>
> - we have FFI only features now [classAddMethods]
>
> - we have already had a situation where the non-FFI stuff broke 
> because it went untested... i.e. non-FFI support is being neglected by 
> the dev team.

I'd prefer to make 0.9 a libffi-by-default release (if you really don't 
want libffi you can change setup.py and do without classAddMethods). 
The next release beyond that should probably be FFI only, this would 
allow for easier to comprehend code.

>
>>> If we are going to do any major changes to the namespace, now is the 
>>> time.
>>>
>>> I would like to see *everything* in pyobjc move into a 'pyobjc' 
>>> package... and have the other three/four packages hang below that.
>>>
>>> pyobjc.obj
>>> pyobjc.foundation
>>> pyobjc.appkit
>>> pyobjc.addressbook
>>
>> lowercase for appkit and foundation?
>
> Follows Python standard?     Personally, I like Foundation and AppKit, 
> as well -- of course, AppKit really should be Cocoa for OS X even 
> though Cocoa is basically an empty framework...

There are enough modules whose name start with an uppercase letter to 
make this a non-issue. The MacPython Carbon/CoreFoundation modules also 
use names starting with an uppercase letter.

And wrt. Cocoa, we could add a Cocoa.py that does 'from Foundation 
import *; from AppKit import *', but I don't think that would buy us 
much, the developer docs mention AppKit/NSFoobar.h not the Cocoa 
version.
>
>>> ... etc ...
>>>
>>> This will make for much easier packaging in app wrappers [simplifies 
>>> build targets] and much less clutter in site-packages.
>>>
>>> thoughts?
>>
>> FWIW, I am -0
>>
>> 1. The current flat nesting adds weight to the idea that Foundation 
>> and AppKit are big frameworks in their own right
>
> I still think they should be nested, just under a single roof....
>
>> 2. This adds some text for every import (and there tend to be a lot 
>> in pyobjc programs)
>
> True.
>
>> 3. Its not hard to package the modules in a subdirectory, using .pth 
>> files in /usr/lib/site-packages and with minimal extra code in 
>> bin-python-main.m. Hmm, and some extra code in bundlebuilder.py too, 
>> I think. OTOH, extra code somewhere is still extra code, and putting 
>> everything in a package doesn't require any extra code.
>
> I'm not sure what this means....
We could install our python files in another location than 
site-packages (say /opt/pyobjc) and add a pyobjc.pth to site-packages. 
This makes site-packages less cluttered :-)

I'm not too worried about this, we currently add:
- bundlebuilder and friends: Those are part of Python 2.3 and provided 
as a convenience for our users.
- package objc: This is the core bridge, normal users should only need 
this in exceptional cases
- packages Foundation, AppKit, AddressBook: These are wrappers around 
(large) Apple provided class libraries.
- autoGIL: Might move to MacPython in the future. We might move this to 
the Foundation package

One change to the toplevel namespaces might be usefull: Add a 
PyObjCUtils packages containing usefull addon facilities (like the 
Just's TelnetInspector and NibClassLoader). Foundation.Conversion could 
also be moved to this package.

>
>> 4. If I see "Declared in: AppKit/NSMatrix.h" in Apple's docs, I write:
>> "from AppKit import NSMatrix". One-to-one correspondence!
>
> Which would change to:
>
>     from pyobjc.AppKit import NSMatrix
>
> Strictly speaking, this emphasizes that one is using the 'pyobjc' 
> gateway into the 'AppKit' framework -- a more correct nomenclature 
> because the pyobjc bridge changes the way the AppKit is accessed.

I don't want to know that I'm using a gateway. The beauty of PyObjC is 
that it the bridge is almost invisible. This also makes it pretty 
boring to talk about, but you can't have everything :-)

BTW. On what timescale do you want to do a 0.9 release? There's one 
issue that IMHO should be fixed soon: Users must currently manually 
adjust the reference count if they allocate an object using 
'SomeClass.alloc().init()'. I'd like to fix this soon.

Ronald

[Pyobjc-dev] Constants etc.

[Martina O. <Ma...@Oe...>]

Hi All,

Currently, PyObjC bridges apparently only classes, but the Cocoa 
headers contain a lot of stuff outside the class definitions, e.g. 
constants. Is there any intent to bridge these definitions?

ciao
Martina

Re: [Pyobjc-dev] 0.9

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

On Saturday, Feb 1, 2003, at 20:15 Europe/Amsterdam, Bill Bumgarner 
wrote:

> As Just mentioned, it is about time to do a 0.9 release.
>
> If we are going to do any major changes to the namespace, now is the 
> time.
Speaking of namespaces, I'd like to some massive surgery on function 
names in the C code (to make them comply with our coding style).

>
> I would like to see *everything* in pyobjc move into a 'pyobjc' 
> package... and have the other three/four packages hang below that.
>
> pyobjc.obj
pyobjc.objc (?)
> pyobjc.foundation
> pyobjc.appkit
> pyobjc.addressbook

-1 on this

I like having AppKit and Foundation at toplevel, this neatly mirrors 
the <AppKit/..> and <Foundation/..> "namespaces" in Objective-C. It 
also introduces a fundamental difference between frameworks wrapped by 
the PyObjC-team and other frameworks: The latter cannot be in the 
pyobjc package (which would introduce compatibility issues if the 
wrapper is moved into the core later on)\

>
> ... etc ...
>
> This will make for much easier packaging in app wrappers [simplifies 
> build targets] and much less clutter in site-packages.

This may actually make it harder to build a minimal standalone 
application, IIRC modulefinder assumes you'll need the entire package 
if you use one module from a package. That may or may not be an issue.

Ronald

Re: [Pyobjc-dev] Sockets, Files, Fun

[Martina O. <Ma...@Oe...>]

Am Samstag, 01.02.03 um 19:42 Uhr schrieb Just van Rossum:

> Hm, I can't reproduce it with current CVS of PyObjC, neither with 
> Python
> 2.2 nor CVS Python.

Thanks Just - I finally dared to build PyObjC from CVS, and it works!

> A lot has changed since 0.8, and I think it's time
> for a 0.9 release...

:-)

ciao
Martina

Re: [Pyobjc-dev] Debugging PyObjc Apps

[Martina O. <Ma...@Oe...>]

Am Sonntag, 02.02.03 um 01:25 Uhr schrieb Just van Rossum:

>> I haven't looked at pdb;  does it do remote debugging?
>
> Not directly, but I think we can find a way so we can just run it
> _inside_ the app process, and access it through TelnetInspect or
> something similar. Hm, that might actually work out of the box... I

it doesn't work - at least in my attempts the app froze completely.
When PDB suspends the running app, the run loop is suspended, too, and 
so TelnetInspect can't perform any I/O for PDB, so that you don't have 
a chance to resume the program.

PDB would need an I/O mechanism which doesn't depend on the run loop.

ciao
Martina

Re: [Pyobjc-dev] applicationShouldOpenUntitledFile_

[Mitch C. <mit...@ea...>]

On Saturday, February 1, 2003, at 11:00 PM, bb...@ma... wrote:

> On Saturday, Feb 1, 2003, at 23:34 US/Eastern, Mitch Chapman wrote:
>> I'm not sure if this is a bug or if I've screwed up my installation.
>>
>> Using the CVS PyObjC (updated about 1930 MST today), with its
>> slightly-modified project templates (see below) installed under 
>> ~/Developer,
>> I created a new Cocoa-Python Document-based application.  Then in
>> MyAppDelegate.py I changed the return value from YES to NO.  When the
>> application started it opened an Untitled document, despite the 
>> changed
>> return value.
>>
>> I'm having similar problems convincing the application that 
>> openFile_ofType_
>> is successful -- I keep getting "Can't open file <pathname>" dialogs.
>>
>> Thanks for any hints.  Please be gentle with the clue stick :)
>
> Very easy fix and not at all obvious.  The problem is that there is no 
> way for the bridge to know that your implementation of the method 
> should return BOOL.  So, you either have to tell the bridge that your 
> method returns a BOOL through the use of the objc.selector() function 
> or, better yet, declare that your class implements the informal 
> NSApplication delegate protocol.
>
> That is, change your class declaration to something like...
>
> class MyAppDelegate(NSObject, NSApplicationDelegate):
>     ....
> [...]
> It also works with the AutoBaseClass mechanism.
>

Hm... I think the project template already did this for me.
(BTW thanks for including the project templates -- way cool.)
Here's the relevant code, showing the class declaration provided by
the template:

# create ObjC classes as defined in MainMenu.nib
NibClassBuilder.extractClasses("MainMenu")
class MyAppDelegate(AutoBaseClass, NSApplicationDelegate):
     def applicationShouldOpenUntitledFile_(self, sender):
         # return NO if you don't want untitled document to be opened on 
app launch
         NSLog("applicationShouldOpenUntitledFile_")
         return NO

The log message is showing up in the PB Run window, right about the
time the unwanted Untitled document appears.

Just for grins I tried replacing 'AutoBaseClass' with 'NSObject', but
the result was the same.  The declaration for the selector in
AppKit/__init__.py looks okay, but I'm new at reading Objective-C
method signatures.

--
Mitch

Re: [Pyobjc-dev] applicationShouldOpenUntitledFile_

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

On Saturday, Feb 1, 2003, at 23:34 US/Eastern, Mitch Chapman wrote:
> I'm not sure if this is a bug or if I've screwed up my installation.
>
> Using the CVS PyObjC (updated about 1930 MST today), with its
> slightly-modified project templates (see below) installed under 
> ~/Developer,
> I created a new Cocoa-Python Document-based application.  Then in
> MyAppDelegate.py I changed the return value from YES to NO.  When the
> application started it opened an Untitled document, despite the changed
> return value.
>
> I'm having similar problems convincing the application that 
> openFile_ofType_
> is successful -- I keep getting "Can't open file <pathname>" dialogs.
>
> Thanks for any hints.  Please be gentle with the clue stick :)

Very easy fix and not at all obvious.  The problem is that there is no 
way for the bridge to know that your implementation of the method 
should return BOOL.  So, you either have to tell the bridge that your 
method returns a BOOL through the use of the objc.selector() function 
or, better yet, declare that your class implements the informal 
NSApplication delegate protocol.

That is, change your class declaration to something like...

class MyAppDelegate(NSObject, NSApplicationDelegate):
     ....

... and the bridge will automatically make sure that the signatures-- 
that the types of the arguments and return values-- of the methods that 
act as the app delegate are correct.   Similar mechanisms also exist 
for window delegates, table data sources, dragging 
destinations/sources, and a number of other collections of methods.

It also works with the AutoBaseClass mechanism.

b.bum

[Pyobjc-dev] applicationShouldOpenUntitledFile_

[Mitch C. <mit...@ea...>]

I'm not sure if this is a bug or if I've screwed up my installation.

Using the CVS PyObjC (updated about 1930 MST today), with its
slightly-modified project templates (see below) installed under 
~/Developer,
I created a new Cocoa-Python Document-based application.  Then in
MyAppDelegate.py I changed the return value from YES to NO.  When the
application started it opened an Untitled document, despite the changed
return value.

I'm having similar problems convincing the application that 
openFile_ofType_
is successful -- I keep getting "Can't open file <pathname>" dialogs.

I may have a screwed-up installation.  I'm running against
/usr/local/bin/python, a Python 2.2.2 installation.  I also had to
modify the project templates under ~/Developer, changing the
*.pbproj/project.pbxproj files to refer to /usr/local/lib/python2.2
instead of to /usr/lib/python2.2.  The main reason for these
changes is that I want to use ZODB3.1, which is not compatible with
Python 2.2.

Thanks for any hints.  Please be gentle with the clue stick :)

--
Mitch

[Pyobjc-dev] project templates fixed

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

The project templates have been fixed to represent the new installation 
style.

Web Services Tool has also been fixed.

TableModel2 is way broken in many ways -- needs to be updated.

b.bum

Re: [Pyobjc-dev] *** Important Notice for people working from CVS

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

bb...@ma... wrote:

> > The same goes for people that don't use the installer but build
> > from the source. Hmmm. Perhaps setup.py should be hacked to do this.
> 
> Yes.  It should.  That would be very helpful.

Done. So forget my previous warning/notice... (The setup.py hack wasn't
as nearly as bad as I though it would be...)

Must Sleep.

Just

Re: [Pyobjc-dev] autoGIL and project templates

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

David Eppstein wrote:

> Just ran a cvs update, saw it adds a new autoGIL.so to site-packages.
>  The CVS project templates don't look like they've been touched since
> Jan 17 -- I can't find autoGIL in the ChangeLog, but according to
> pyobjc-checkins it was added yesterday, so I'm guessing the templates
> don't yet include autoGIL among the stuff copied for a standalone
> build, and probably should to avoid unnecessary surprises...

Which reminds me, I should enhance my bundlebuilder tool so it can build
"partially-standalone" apps, like the PB templates do. Right now you can
only make a non-standalone (only use modules from the installation,
which is great for development, esp. with the --link option: no need to
rebuild the bundle after an edit) and standalone (include everything
needed, from .py and .so files to the interpreter itself. The advantage
is that the dependency checking is done for you, there's no need to
specify which modules to include in the bundle (so no need to change
anything to the project when a new module gets added).

Just

Re: [Pyobjc-dev] autoGIL and project templates

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

They don't and they should [and will] be updated immediately.

On Saturday, Feb 1, 2003, at 19:42 US/Eastern, David Eppstein wrote:
> Just ran a cvs update, saw it adds a new autoGIL.so to site-packages.  
> The CVS project templates don't look like they've been touched since 
> Jan 17 -- I can't find autoGIL in the ChangeLog, but according to 
> pyobjc-checkins it was added yesterday, so I'm guessing the templates 
> don't yet include autoGIL among the stuff copied for a standalone 
> build, and probably should to avoid unnecessary surprises...

Re: [Pyobjc-dev] *** Important Notice for people working from CVS

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

On Saturday, Feb 1, 2003, at 19:38 US/Eastern, Just van Rossum wrote:
> I applied the previously discussed patch that will install all PyObjC
> modules in a subdir of site-packages, called "PyObjC". This has the
> following consequence if you update:
>
> ***** WARNING: you must remove the previous version of PyObjC by hand:
>       site-packages/objc/
>       site-packages/Foundation/
>       site-packages/AppKit/
>       site-packages/autoGIL.so
>
> Can this step be automated in the installer for 0.9? Otherwise people
> upgrading from 0.8 will have to do this manually, too :-(

If I can figure out how to make a package that is effectively a new 
version of the existing PyObjC project, then Installer should handle it 
automatically -- removing and replacing files as well as copying the 
new files into place.

If I can't figure it out, it is trivial to write a postflight script 
that removes the original packages as a part of the installer.

> The same goes for people that don't use the installer but build
> from the source. Hmmm. Perhaps setup.py should be hacked to do this.

Yes.  It should.  That would be very helpful.

b.bum

[Pyobjc-dev] autoGIL and project templates

[David E. <epp...@ic...>]

Just ran a cvs update, saw it adds a new autoGIL.so to site-packages.  The 
CVS project templates don't look like they've been touched since Jan 17 -- 
I can't find autoGIL in the ChangeLog, but according to pyobjc-checkins it 
was added yesterday, so I'm guessing the templates don't yet include 
autoGIL among the stuff copied for a standalone build, and probably should 
to avoid unnecessary surprises...

--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

[Pyobjc-dev] *** Important Notice for people working from CVS

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

I applied the previously discussed patch that will install all PyObjC
modules in a subdir of site-packages, called "PyObjC". This has the
following consequence if you update:

***** WARNING: you must remove the previous version of PyObjC by hand:
      site-packages/objc/
      site-packages/Foundation/
      site-packages/AppKit/   
      site-packages/autoGIL.so

Can this step be automated in the installer for 0.9? Otherwise people
upgrading from 0.8 will have to do this manually, too :-(

The same goes for people that don't use the installer but build
from the source. Hmmm. Perhaps setup.py should be hacked to do this.

Just

Re: [Pyobjc-dev] Debugging PyObjc Apps

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

bb...@ma... wrote:

> I haven't looked at pdb;  does it do remote debugging?

Not directly, but I think we can find a way so we can just run it
_inside_ the app process, and access it through TelnetInspect or
something similar. Hm, that might actually work out of the box... I
never got used to pdb, or rather command line debuggers in general -- I
want a graphical debugger... I wrote one for the MacPython IDE but that
one doesn't do remote debugging at all.

Just

Re: [Pyobjc-dev] Sockets, Files, Fun

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

Just van Rossum wrote:

> I _did_ manage to get a crash this way:
> 
> - start TelnetServer like you did
> - open a telnet session (works)
> - type cmd-. or ctl-C in the window running the server. This does
> nothing (not surprisingly...)
> - type return in the telnet window.
> Boom goes the server process:
> 
> Thread 0 Crashed:
>  #0   0x00034044 in PyObject_GetAttrString (object.c:1133)
>  #1   0x004f91d8 in ObjCErr_ToObjC (objc_util.m:136)
>  #2   0x004f91d8 in ObjCErr_ToObjC (objc_util.m:136)
>  #3   0x004fde78 in ObjC_call_to_python (class-builder.m:1128)
>  #4   0x0050ac84 in method_stub (libffi_support.m:250)
>  #5   0x0050b7d8 in ffi_closure_helper_DARWIN (ffi_darwin.c:710)
>  #6   0x0050bb48 in ffi_closure_ASM
>  #7   0x907eaf7c in _nsNotificationCenterCallBack
>  #8   0x90168580 in _postNotification
>  #9   0x90165ca0 in _CFNotificationCenterPostLocalNotification
>  #10  0x908b83ac in _performFileHandleSource
>  #11  0x90149534 in __CFRunLoopDoSources0
>  #12  0x90148918 in __CFRunLoopRun
>  #13  0x90180fe4 in CFRunLoopRunSpecific

Fixed in CVS. (Not that the above scenario does anything useful now but
at least it won't crash ;-)

Just

Re: [Pyobjc-dev] Article on MacDevCenter

[Bob I. <bo...@re...>]

On Saturday, Feb 1, 2003, at 19:01 America/New_York, Jack Jansen wrote:

>
> On zaterdag, feb 1, 2003, at 07:07 Europe/Amsterdam, Bill Bumgarner 
> wrote:
>
>> http://www.macdevcenter.com/pub/a/mac/2003/01/31/pyobjc_one.html
>
> Bill,
> looks good!!
>
> There's, however, one little thing that bothers me. Actually, it's 
> been bothering me since I first came across the PyObjC module a few 
> years ago: PyObjC is very daunting to a Python programmer initially, 
> with all the long method names with _ all over them. This made me stay 
> away from it for a long time (until less than a year ago, actually, 
> after I had done a few Cocoa examples in ObjC itself and got to know 
> the power of Cocoa). Your article shares that treat of PyObjC, I 
> think: if you're a Python programmer fresh to OSX and you start your 
> foray into Cocoa with reading it you'll probably turn away and stick 
> to Tk or wxWindows.
>
> I think PyObjC popularity would be helped very much if there was an 
> introduction to PyObjC that was targeted at Python users, which would 
> somehow ease them into the funny naming scheme and such...

Well the biggest plus for me is that it's the easiest to install and 
lightest to deploy python GUI framework on OS X.

-bob

Re: [Pyobjc-dev] Article on MacDevCenter

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

On zaterdag, feb 1, 2003, at 07:07 Europe/Amsterdam, Bill Bumgarner 
wrote:

> http://www.macdevcenter.com/pub/a/mac/2003/01/31/pyobjc_one.html

Bill,
looks good!!

There's, however, one little thing that bothers me. Actually, it's been 
bothering me since I first came across the PyObjC module a few years 
ago: PyObjC is very daunting to a Python programmer initially, with all 
the long method names with _ all over them. This made me stay away from 
it for a long time (until less than a year ago, actually, after I had 
done a few Cocoa examples in ObjC itself and got to know the power of 
Cocoa). Your article shares that treat of PyObjC, I think: if you're a 
Python programmer fresh to OSX and you start your foray into Cocoa with 
reading it you'll probably turn away and stick to Tk or wxWindows.

I think PyObjC popularity would be helped very much if there was an 
introduction to PyObjC that was targeted at Python users, which would 
somehow ease them into the funny naming scheme and such...
--
- 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] [ pyobjc-Bugs-678818 ] Missing NSCFNumber to int conversions

[David E. <epp...@ic...>]

On 2/1/03 6:15 PM -0500 bb...@ma... wrote:
> I "fixed" it and your test prog now spews:
>
> [bumbox:~/bbum-developer/sourceforge/pyobjc] bbum% python foo.py
> Increment by 3 to 3
> Null decrement to 3
> Null increment to 3
> Decrement by 3 to 0
>
> Is this correct?

Yes.  Was there a recent change that would have caused the "if x:" to work 
on your system and not on mine?  My most recent cvs update was Jan. 23.

Also, I'm not sufficiently familiar w/the sf bugtracker -- is there an 
address to include in email so that comments like this can get 
auto-attached to the bug?  Or do all comments have to be done through the 
web page?
--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

Re: [Pyobjc-dev] [ pyobjc-Bugs-678818 ] Missing NSCFNumber to int conversions

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

On Saturday, Feb 1, 2003, at 18:24 US/Eastern, Just van Rossum wrote:
> bb...@ma... wrote:
>
>> On Saturday, Feb 1, 2003, at 17:16 US/Eastern, SourceForge.net wrote:
>
> Bill, not to be a pain in the neck, but it's really best to add 
> comments
> to the bug report itself and not post directly to the list...

Yes -- I'm actually going to update the bug, but I wanted to open some 
of the discussion here because it involves adding a feature back to the 
bridge that was clearly removed at some point for some reason...

b.bum

Re: [Pyobjc-dev] [ pyobjc-Bugs-678818 ] Missing NSCFNumber to int conversions

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

bb...@ma... wrote:

> On Saturday, Feb 1, 2003, at 17:16 US/Eastern, SourceForge.net wrote:

Bill, not to be a pain in the neck, but it's really best to add comments
to the bug report itself and not post directly to the list...

Just

Re: [Pyobjc-dev] [ pyobjc-Bugs-678818 ] Missing NSCFNumber to int conversions

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

On Saturday, Feb 1, 2003, at 17:16 US/Eastern, SourceForge.net wrote:
> 1. if x: should only execute the if clause when x is
> nonzero.  But if x is a zero NSCFNumber, the clause
> gets executed erroneously (third line of code's output
> is "Increment by ..." instead of "Null increment")

I believe this is working correctly on my system?

[bumbox:~/bbum-developer/sourceforge/pyobjc] bbum% python foo.py
Increment by 3 to 3
Null decrement to 3
Null increment to 3
Decrement by <NSCFNumber objective-c instance 0x470330> to 0

> 2. str(x) should produce a decimal representation of x,
> but if x is an NSCFNumber, it instead produces a string
> like '<NSCFNumber objective-c instance 0x832ed0>'
> (third and fourth lines of code's output).

This is definitely broken.  Both str() and repr() do not do what one 
might expect.

Why doesn't str() invoke -description?  ...or repr()?  __repr__ mapping 
to -description was commented out of _convenience.py.

I "fixed" it and your test prog now spews:

[bumbox:~/bbum-developer/sourceforge/pyobjc] bbum% python foo.py
Increment by 3 to 3
Null decrement to 3
Null increment to 3
Decrement by 3 to 0

Is this correct?

Change committed (along with a unit test).

There is still a bug in NSNumber handling, though:

[bumbox:~/bbum-developer/sourceforge/pyobjc] bbum% python 
Lib/Foundation/test/test_nsnumber.py -v
testAsBool (__main__.TestNSNumber) ... FAIL
testNSNumber (__main__.TestNSNumber) ... ok
testStr (__main__.TestNSNumber) ... ok

======================================================================
FAIL: testAsBool (__main__.TestNSNumber)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/Foundation/test/test_nsnumber.py", line 34, in testAsBool
     raise AssertionError, "%s is not true"%(a.description())
AssertionError: -0.01 is not true

----------------------------------------------------------------------
Ran 3 tests in 0.035s

FAILED (failures=1)

b.bum

Re: [Pyobjc-dev] top level namespaces

[Bill B. <bb...@co...>]

On Saturday, Feb 1, 2003, at 16:00 US/Eastern, Just van Rossum wrote:
> Shall I go for it?

+1

Re: [Pyobjc-dev] top level namespaces

[Bill B. <bb...@co...>]

On Saturday, Feb 1, 2003, at 15:31 US/Eastern, Just van Rossum wrote:
> Nah, there's StringIO, BaseHTTPServer.py, Carbon, and these are just 
> the
> first three that popped up in my head...

Oh, duh!  Don't know where my brain was on that one!

>>> 3. Its not hard to package the modules in a subdirectory, using
>>> .pth files in /usr/lib/site-packages and with minimal extra code in
>>> bin-python-main.m. Hmm, and some extra code in bundlebuilder.py
>>> too, I think. OTOH, extra code somewhere is still extra code, and
>>> putting everything in a package doesn't require any extra code.
>>
>> I'm not sure what this means....
>
> This means there will be a folder inside site-packages containing a
> folder (eg.) PyObjC which contains all our stuff. Right next to it in
> site-packages there's a file called PyObjC.pth which contains one line
> "PyObjC", which is the relative path to our dir which will then be 
> added
> to sys.path by site.py. So this solves the cluttering of the
> site-packages dir.

Ahhh... OK.   That makes sense.   It also doesn't break anything.  Way 
superior.  Didn't even know it existed.

b.bum