pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Adding outlets and actions without rewiring it all

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

On Sunday, Mar 23, 2003, at 22:00 Europe/Amsterdam, Jack Jansen wrote:

>
> On zaterdag, maa 22, 2003, at 19:48 Europe/Amsterdam, Ronald Oussoren 
> wrote:
>> What I usually do is:
>> - Paint a UI in Interface Builder, including the initial definition 
>> of one or
>>   more model classes/objects.
>> - Generate a template using AppKit.NibClassBuilder (used a script)
>> - Fill in the template.
>>
>> If the model interface changes later on I change the definition in IB 
>> and update the python files. There is no need to rewire anything in > 
>> IB.
>
> This procedure needs to be documented. and probably in a step-by-step 
> way. It is essential to PyObjC
> development, but it is also pretty obscure. Even more obscure than the 
> corresponding ObjC procedure
> (which you also will never find if you don't do one of Apple's 
> examples).

Thanks for the tip. It is pretty obvious to me, hence the lack of 
documentation. I'm sure there are more features/procedures that are 
obvious for someone familiar with PyObjC but not for a newby. Please 
keep us informed of them. "There are no dumb questions, only lacking 
documentation"

Ronald

Re: [Pyobjc-dev] Adding outlets and actions without rewiring it all

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

On zaterdag, maa 22, 2003, at 19:48 Europe/Amsterdam, Ronald Oussoren 
wrote:
> What I usually do is:
> - Paint a UI in Interface Builder, including the initial definition of 
> one or
>   more model classes/objects.
> - Generate a template using AppKit.NibClassBuilder (used a script)
> - Fill in the template.
>
> If the model interface changes later on I change the definition in IB 
> and update the python files. There is no need to rewire anything in > IB.

This procedure needs to be documented. and probably in a step-by-step 
way. It is essential to PyObjC
development, but it is also pretty obscure. Even more obscure than the 
corresponding ObjC procedure
(which you also will never find if you don't do one of Apple's 
examples).
--
- 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] Adding outlets and actions without rewiring it all

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

On Saturday, Mar 22, 2003, at 19:07 Europe/Amsterdam, Antonio Rodriguez 
wrote:

> Excuse me if this is more my ineptitude with IB than a pyobjc question:
>
> Using Obj-C, when I change a class definition in IB by adding an 
> outlet or an action, I can use the "Read Files" option to find the 
> changes in the instance which I have wired up to my view. In PyObjc 
> this is not an option.
>
> the way I'm understanding it now (and correct me if I am wrong), I 
> have to re-instatiate and re-wire everytime I find that I forgot that 
> I needed an extra outlet or action. Is that correct or am I missing 
> something? I seem to remember that it was the same with the java 
> bridge which was  a real show stopper for those of us constantly 
> tweaking our apps.

If I understand you correctly you seem to assume that you have to 
recreate your model objects in the NIB everytime you want to change the 
python class for the model. That is not true, the class definition in 
IB is a different beast than the one in you python script.

What I usually do is:
- Paint a UI in Interface Builder, including the initial definition of 
one or
   more model classes/objects.
- Generate a template using AppKit.NibClassBuilder (used a script)
- Fill in the template.

If the model interface changes later on I change the definition in IB 
and update the python files. There is no need to rewire anything in IB.

Ronald

Re: [Pyobjc-dev] Adding outlets and actions without rewiring it all

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

Just van Rossum wrote:

> If you subclass from AppKit.NibClassBuilder.AutoBaseClass [ ... ]

Btw. NibClassBuilder.py is also a candidate to move to PyObjCTools.

Just

Re: [Pyobjc-dev] NSApplicationMain idiom: wish to standardize

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

On Saturday, Mar 22, 2003, at 19:36 Europe/Amsterdam, Just van Rossum 
wrote:

> Ronald Oussoren wrote:
>
>> That doesn't mean I'm not interested in speeding up PyObjC. I'm not
>> much into import hacks, so how would one cause the creation of a
>> custom module-like object when doing 'import AppKit'? Does this
>> entrail creating an importhook, or is replacing sys.modules['AppKit']
>> from inside AppKit/__init__.py sufficient?
>
> The latter is sufficient. Supporting __getattr__ and having an __all__
> attribute is all that's needed, if I recall correctly. For a package
> directory it should have a __path__ attribute.

Interesting, that's pretty easy. I'm going to experiment with this. I'm 
going to target two things:
1. Speedier initialisation
2. Make the NSApp global variable available as a variable instead of a 
function

I foresee one problem: Dynamicly adding the class names in AppKit to 
the __all__ list of the AppKit module/package. The only method I can 
come up with right now is about as expensive as the current code, which 
is not very usefull. We could depricate 'from AppKit import *', but 
that doesn't make me much happier. The other alternative is staticly 
filling __all__ (possibly based on the OS version).

Ronald

Re: [Pyobjc-dev] Adding outlets and actions without rewiring it all

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

Antonio Rodriguez wrote:

> Excuse me if this is more my ineptitude with IB than a pyobjc
> question:
> 
> Using Obj-C, when I change a class definition in IB by adding an
> outlet or an action, I can use the "Read Files" option to find the
> changes in the instance which I have wired up to my view. In PyObjc
> this is not an option.
> 
> the way I'm understanding it now (and correct me if I am wrong), I
> have to re-instatiate and re-wire everytime I find that I forgot that
> I needed an extra outlet or action. Is that correct or am I missing
> something? I seem to remember that it was the same with the java
> bridge which was  a real show stopper for those of us constantly
> tweaking our apps.

If you subclass from AppKit.NibClassBuilder.AutoBaseClass, all your
outlets are created automatically from the nib. Most examples in the
Examples sudirectory use it. You need to call
AppKit.NibClassBuilder.extractClasses() with your nib's name before you
can use AutoBaseClass.

Regarding actions: you have to write them yourself anyway, so I'm not
even sure how PyObjC could help you there.

Just

Re: [Pyobjc-dev] NSApplicationMain idiom: wish to standardize

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

Ronald Oussoren wrote:

> That doesn't mean I'm not interested in speeding up PyObjC. I'm not
> much into import hacks, so how would one cause the creation of a
> custom module-like object when doing 'import AppKit'? Does this
> entrail creating an importhook, or is replacing sys.modules['AppKit']
> from inside AppKit/__init__.py sufficient?

The latter is sufficient. Supporting __getattr__ and having an __all__
attribute is all that's needed, if I recall correctly. For a package
directory it should have a __path__ attribute.

Just

[Pyobjc-dev] Adding outlets and actions without rewiring it all

[Antonio R. <an...@me...>]

Excuse me if this is more my ineptitude with IB than a pyobjc question:

Using Obj-C, when I change a class definition in IB by adding an outlet 
or an action, I can use the "Read Files" option to find the changes in 
the instance which I have wired up to my view. In PyObjc this is not an 
option.

the way I'm understanding it now (and correct me if I am wrong), I have 
to re-instatiate and re-wire everytime I find that I forgot that I 
needed an extra outlet or action. Is that correct or am I missing 
something? I seem to remember that it was the same with the java bridge 
which was  a real show stopper for those of us constantly tweaking our 
apps.


Thanks all

Antonio

Re: [Pyobjc-dev] NSApplicationMain idiom: wish to standardize

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

On Friday, Mar 21, 2003, at 18:02 Europe/Amsterdam, Just van Rossum 
wrote:
>
>> (using a savagely butchered version of PyObjC, 'import
>> AppKit' would use another 2 seconds if I hadn't build a mini module
>> that exports all definitions I need from AppKit and Foundation).
>
> Does this mean we should revisit the idea of replacing the Cocoa 
> modules
> with "lazy" module-like objects? If *you* are butchering up PyObjC that
> should be a sign...

I did this to investigate how much faster I could get the application 
without rewriting in Objective-C, which would not be worth it just for 
shaving a couple of seconds from the lauch-time. I wonder if there are 
a lot of problems where (re)writing in Objective-C instead of Python 
would be worthwile.

That doesn't mean I'm not interested in speeding up PyObjC. I'm not 
much into import hacks, so how would one cause the creation of a custom 
module-like object when doing 'import AppKit'? Does this entrail 
creating an importhook, or is replacing sys.modules['AppKit'] from 
inside AppKit/__init__.py sufficient?

Ronald

Re: [Pyobjc-dev] NSApplicationMain idiom: wish to standardize

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

On Friday, Mar 21, 2003, at 20:26 Europe/Amsterdam, Zachery Bir wrote:

> On Friday, Mar 21, 2003, at 13:02 US/Eastern, Ronald Oussoren wrote:
>
>> Project Builder starts in about 5 seconds (Powerbook G5 667 Mhz, 512 
>> MB).
>
> Ooh, when do I get one? :)

Oops, I shouldn't have mentioned the G5. I hope my NDA doesn't get 
revoked because of this :-)

Ronald

Re: [Pyobjc-dev] NSApplicationMain idiom: wish to standardize

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

On Friday, Mar 21, 2003, at 23:07 Europe/Amsterdam, Jack Jansen wrote:

>
> On vrijdag, maa 21, 2003, at 17:33 Europe/Amsterdam, Ronald Oussoren 
> wrote:
>> Speaking of NSApplicationMain... Does anyone care to offer on opinion 
>> on the enormous amount of time between the call to NSApplicationMain 
>> and the call to awakeFromNib in a simple application? That period of 
>> time takes about 4 seconds of the 5 seconds my application needs to 
>> start up (using a savagely butchered version of PyObjC, 'import 
>> AppKit' would use another 2 seconds if I hadn't build a mini module 
>> that exports all definitions I need from AppKit and Foundation).
>
> Are you using Python from CVS? Python 2.3a2 still had prebinding 
> enabled, which slowed down dynamic loading terribly (see the thread 
> "Slow loading of modules" around 23-Feb-2003 in pythonmac-sig, for the 
> people who weren't in on this).
>
> And if you are using a non-prebinding Python: try using "sample" on 
> python while it is doing it's
> NSApplicationMain dance.

I'm using Python from CVS. I didn't know about 'sample', it looks like 
very usefull tool. Thanks for the hint.

Ronald

[Pyobjc-dev] Re: hashbang in applets

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

Jack Jansen wrote:

> > 'os.path.join(os.dirname(hashbang), os.readlink(hashbang))'
> 
> Don't use this construct, use os.path.realpath(sys.executable). It
> follows recursive symlinks and understands about relative symlinks
> too.

Ah, nice. Will patch bundlebuilder accordingly.

Just

Re: [Pyobjc-dev] NSApplicationMain idiom: wish to standardize

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

On vrijdag, maa 21, 2003, at 17:33 Europe/Amsterdam, Ronald Oussoren 
wrote:
> Speaking of NSApplicationMain... Does anyone care to offer on opinion 
> on the enormous amount of time between the call to NSApplicationMain 
> and the call to awakeFromNib in a simple application? That period of 
> time takes about 4 seconds of the 5 seconds my application needs to 
> start up (using a savagely butchered version of PyObjC, 'import 
> AppKit' would use another 2 seconds if I hadn't build a mini module 
> that exports all definitions I need from AppKit and Foundation).

Are you using Python from CVS? Python 2.3a2 still had prebinding 
enabled, which slowed down dynamic loading terribly (see the thread 
"Slow loading of modules" around 23-Feb-2003 in pythonmac-sig, for the 
people who weren't in on this).

And if you are using a non-prebinding Python: try using "sample" on 
python while it is doing it's
NSApplicationMain dance.
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

[Pyobjc-dev] hashbang in applets

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

On vrijdag, maa 21, 2003, at 21:12 Europe/Amsterdam, Ronald Oussoren 
wrote:
> P.S. bundlebuilder.py from the current Python CVS doesn't work for me, 
> I get #!python2.3 at the start of the bootstrap script. That's 
> probably because 'which python' is  '/usr/local/bin/python' and that 
> is a symlink to 'python2.3' in the same directory.  This fragment of 
> code doesn't work correctly with that:
>   hashbang = sys.executable
>   while os.path.islink(hashbang):
>      hashbang = os.readlink(hashbang)
>
> The second time through the loop hashbang is 'python2.3', which 
> doesn't exist. The assignment should probably be something like 
> 'os.path.join(os.dirname(hashbang), os.readlink(hashbang))'

Don't use this construct, use os.path.realpath(sys.executable). It 
follows recursive symlinks and understands about relative symlinks too.
--
- 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] NSApplicationMain idiom: wish to standardize

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

Ronald Oussoren wrote:

> P.S. bundlebuilder.py from the current Python CVS doesn't work for me, 
> I get #!python2.3 at the start of the bootstrap script. That's
probably 
> because 'which python' is  '/usr/local/bin/python' and that is a 
> symlink to 'python2.3' in the same directory.  This fragment of code 
> doesn't work correctly with that:
>    hashbang = sys.executable
>    while os.path.islink(hashbang):
>       hashbang = os.readlink(hashbang)
> 
> The second time through the loop hashbang is 'python2.3', which
> doesn't exist. The assignment should probably be something like
> 'os.path.join(os.dirname(hashbang), os.readlink(hashbang))'

Beh -- but thanks for reporting it!

I changed it (reluctantly) from #!/user/bin/python to what you see now
by Jack's request, basically so the same interpreter is used for
bootstrapping and running the applet (if it's a standalone app we use
/usr/bin/python). It seems a micro optimization that caused more trouble
than it's worth. Unless I get some more arguments for using an improved
readlink approach, I'll go back to hardcoding it again, or possibly
using #!/usr/bin/env python.

Just

Re: [Pyobjc-dev] NSApplicationMain idiom: wish to standardize

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

On Friday, Mar 21, 2003, at 18:02 Europe/Amsterdam, Just van Rossum 
wrote:
>
>> Speaking of NSApplicationMain... Does anyone care to offer on opinion
>> on the enormous amount of time between the call to NSApplicationMain
>> and the call to awakeFromNib in a simple application? That period of
>> time takes about 4 seconds of the 5 seconds my application needs to
>> start up
>
> I'm also still seeing long startup times, about 8-10 seconds. I'll
> measure later how much of that is spent between NSApplicationMain() and
> the first awakeFromNib call.

Part of the time is in bootstrapping Python, not much we can do about 
that (and not part of the 5 seconds I mentioned earlier).

>
>> (using a savagely butchered version of PyObjC, 'import
>> AppKit' would use another 2 seconds if I hadn't build a mini module
>> that exports all definitions I need from AppKit and Foundation).
>
> Does this mean we should revisit the idea of replacing the Cocoa 
> modules
> with "lazy" module-like objects? If *you* are butchering up PyObjC that
> should be a sign...

As a datapoint (PB 667Mhz) I've done some crude experiments using the 
TableModel example (Python 2.3):

* Plain example starts in 6 bounces

* Objective-C version of same starts in 2 bounces

* Simplified AppKit/Foundation starts in 4 bounces

I've attached the source code for the modified versions. Building these 
is not too hard: Call buildapp.py to create the plain version. For the 
Objective-C version compile tm.m and use that to replace 
Contents/MacOS/TableModel. For the simplified version copy 
TableModel.py to Contents/Resources and then copy _AppKit*, 
NibClassBuilder.py* and _Foundation* from the site-packages directory 
to Contents/Resources.

Some further investigation shows lots (about 8000) of calls to 
get_class_info in objc-class.m between the call to NSApplicationMain 
and the call to awakeFromNib. Removing these calls using the new 
PyHeapTypeObject to store the additional information in the class proxy 
instead of a seperate datastructure doesn't reduce the startup time for 
me. It would have made live much easier if this had been available in 
2.2 :-). I'll probably add this change to CVS if I can do so without 
negative effects on the source code.

Ronald

P.S. bundlebuilder.py from the current Python CVS doesn't work for me, 
I get #!python2.3 at the start of the bootstrap script. That's probably 
because 'which python' is  '/usr/local/bin/python' and that is a 
symlink to 'python2.3' in the same directory.  This fragment of code 
doesn't work correctly with that:
   hashbang = sys.executable
   while os.path.islink(hashbang):
      hashbang = os.readlink(hashbang)

The second time through the loop hashbang is 'python2.3', which doesn't 
exist. The assignment should probably be something like 
'os.path.join(os.dirname(hashbang), os.readlink(hashbang))'

Re: [Pyobjc-dev] NSApplicationMain idiom: wish to standardize

[Zachery B. <zb...@ur...>]

On Friday, Mar 21, 2003, at 13:02 US/Eastern, Ronald Oussoren wrote:

> Project Builder starts in about 5 seconds (Powerbook G5 667 Mhz, 512 
> MB).

Ooh, when do I get one? :)

Zac

Re: [Pyobjc-dev] NSApplicationMain idiom: wish to standardize

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

On Friday, Mar 21, 2003, at 17:52 Europe/Amsterdam, bb...@ma... wrote:

> On Friday, Mar 21, 2003, at 11:33 US/Eastern, Ronald Oussoren wrote:
>> Speaking of NSApplicationMain... Does anyone care to offer on opinion 
>> on the enormous amount of time between the call to NSApplicationMain 
>> and the call to awakeFromNib in a simple application? That period of 
>> time takes about 4 seconds of the 5 seconds my application needs to 
>> start up (using a savagely butchered version of PyObjC, 'import 
>> AppKit' would use another 2 seconds if I hadn't build a mini module 
>> that exports all definitions I need from AppKit and Foundation).
>
> How long does it normally take to launch an app of similar complexity 
> on your machine?

Project Builder starts in about 5 seconds (Powerbook G5 667 Mhz, 512 
MB).

>
> The period of time between NSApplicationMain() and the first 
> awakeFromNib() is comprised of most of the "hard stuff" of launching 
> an app;  setting up the notification stuff, the mach ports, and all 
> the other innards that integrate the App into OS X....
>
> Unless we have a bug somewhere, that period of time shouldn't really 
> be any longer than a 'normal' app as there really isn't anything from 
> PyObjC that is involved (unless your app delegate implements 
> willFinishLaunching())?

I don't implement an app delegate at all.

Ronald

Re: [Pyobjc-dev] NSApplicationMain idiom: wish to standardize

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

Ronald Oussoren wrote:

> I think this would be very usefull. However, I think this module
> should be in a seperate package to make it clear that this is a
> PyObjC helper module instead of wrapped Cocoa functionality.
> Foundation.Conversion should be moved to this package as well.
> 
> How about PyObjCTools?

Fine with me.

> - module PyObjCTools.Conversion would be the new name of 
> Foundation.Conversion
> - module PyObjCTools.AppHelper would contain your function and other 
> NSApplication related tools

Ok.

> Speaking of NSApplicationMain... Does anyone care to offer on opinion
> on the enormous amount of time between the call to NSApplicationMain
> and the call to awakeFromNib in a simple application? That period of
> time takes about 4 seconds of the 5 seconds my application needs to
> start up

I'm also still seeing long startup times, about 8-10 seconds. I'll
measure later how much of that is spent between NSApplicationMain() and
the first awakeFromNib call.

> (using a savagely butchered version of PyObjC, 'import
> AppKit' would use another 2 seconds if I hadn't build a mini module
> that exports all definitions I need from AppKit and Foundation).

Does this mean we should revisit the idea of replacing the Cocoa modules
with "lazy" module-like objects? If *you* are butchering up PyObjC that
should be a sign...

Just

Re: [Pyobjc-dev] NSApplicationMain idiom: wish to standardize

[<bo...@pa...>]

only if you never want to change the name. --bob


> How about PyObjCTools?
>
> - module PyObjCTools.Conversion would be the new name of 
> Foundation.Conversion
> - module PyObjCTools.AppHelper would contain your function and other 
> NSApplication related tools

Re: [Pyobjc-dev] NSApplicationMain idiom: wish to standardize

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

On Friday, Mar 21, 2003, at 11:33 US/Eastern, Ronald Oussoren wrote:
> Speaking of NSApplicationMain... Does anyone care to offer on opinion 
> on the enormous amount of time between the call to NSApplicationMain 
> and the call to awakeFromNib in a simple application? That period of 
> time takes about 4 seconds of the 5 seconds my application needs to 
> start up (using a savagely butchered version of PyObjC, 'import 
> AppKit' would use another 2 seconds if I hadn't build a mini module 
> that exports all definitions I need from AppKit and Foundation).

How long does it normally take to launch an app of similar complexity 
on your machine?

The period of time between NSApplicationMain() and the first 
awakeFromNib() is comprised of most of the "hard stuff" of launching an 
app;  setting up the notification stuff, the mach ports, and all the 
other innards that integrate the App into OS X....

Unless we have a bug somewhere, that period of time shouldn't really be 
any longer than a 'normal' app as there really isn't anything from 
PyObjC that is involved (unless your app delegate implements 
willFinishLaunching())?

b.bum

Re: [Pyobjc-dev] NSApplicationMain idiom: wish to standardize

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

On Thursday, Mar 20, 2003, at 15:23 Europe/Amsterdam, Just van Rossum 
wrote:

> I've been using the following idiom to enter the Cocoa main event loop 
> for
> some time now:

[example removed]

> It's more complicated than what I originally thought was needed back 
> when we
> discussed NSApplicationMain raising exceptions, as simply calling
> NSApplicationMain() again causes the main nib to be reloaded.
>
> The thing is, it's quite a few lines now, and I keep copying it to new 
> apps.
> I would like to put it in a module, but if it's deemed general enough, 
> I
> could also integrate it into PyObjC somewhere. What do people think, 
> is it
> desirable to have in PyObjC? I would propose a new submodule op 
> AppKit, eg.
> named mainHelper.py. The above could then become
>
> from AppKit import mainHelper
> mainHelper.runEventLoop()
>
> Better names are gladly accepted...

I think this would be very usefull. However, I think this module should 
be in a seperate package to make it clear that this is a PyObjC helper 
module instead of wrapped Cocoa functionality. Foundation.Conversion 
should be moved to this package as well.

How about PyObjCTools?

- module PyObjCTools.Conversion would be the new name of 
Foundation.Conversion
- module PyObjCTools.AppHelper would contain your function and other 
NSApplication related tools

Speaking of NSApplicationMain... Does anyone care to offer on opinion 
on the enormous amount of time between the call to NSApplicationMain 
and the call to awakeFromNib in a simple application? That period of 
time takes about 4 seconds of the 5 seconds my application needs to 
start up (using a savagely butchered version of PyObjC, 'import AppKit' 
would use another 2 seconds if I hadn't build a mini module that 
exports all definitions I need from AppKit and Foundation).

Ronald

[Pyobjc-dev] NSApplicationMain idiom: wish to standardize

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

I've been using the following idiom to enter the Cocoa main event loop for
some time now:


def unexpectedErrorAlert():
    exceptionInfo =
traceback.format_exception_only(*sys.exc_info()[:2])[0].strip()
    return NSRunAlertPanel("An unexpected error has occurred",
            "(%s)" % exceptionInfo,
            "Continue", "Quit", None)


mainFunc = NSApplicationMain
args = (sys.argv,)
while 1:
    try:
        mainFunc(*args)
    except:
        traceback.print_exc()
        if not unexpectedErrorAlert():
            break
        mainFunc = NSApp().run
        args = ()
    else:
        break


It's more complicated than what I originally thought was needed back when we
discussed NSApplicationMain raising exceptions, as simply calling
NSApplicationMain() again causes the main nib to be reloaded.

The thing is, it's quite a few lines now, and I keep copying it to new apps.
I would like to put it in a module, but if it's deemed general enough, I
could also integrate it into PyObjC somewhere. What do people think, is it
desirable to have in PyObjC? I would propose a new submodule op AppKit, eg.
named mainHelper.py. The above could then become

from AppKit import mainHelper
mainHelper.runEventLoop()

Better names are gladly accepted...

Just

[Pyobjc-dev] [ pyobjc-Bugs-704900 ] It is not possible to create boolean NSNumbers from python

[SourceForge.net <no...@so...>]

Bugs item #704900, was opened at 2003-03-17 11:08
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=704900&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: It is not possible to create boolean NSNumbers from python

Initial Comment:
It is currently not possible to create NSNumbers that
behave like booleans ([NSNumber numberWithBool:1]) from
python, when using Python 2.2.

This is problematic when trying to create a plist file
containing a boolean value (see testPropertyList1 in
test_nsnumber.py). I'm currently working around this by
using a patched version of PyObjC that doesn't convert
NSNumber instances back to python objects.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=704900&group_id=14534

Re: [Pyobjc-dev] O'Reilly contest

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

On Thursday, Mar 13, 2003, at 22:08 Europe/Amsterdam, Just van Rossum 
wrote:

> O'Reilly has an OSX software contest:
>   http://www.macdevcenter.com/mac/developer/
>
> Perhaps PyObjC itself could be a contender? I suppose we'd need an 0.9
> release for that...

We might as well try, but we have to some work on documentation before 
entering.

Ronald