pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Support for iCalendar?

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

On Saturday, Apr 19, 2003, at 05:36 US/Eastern, Dinu Gherman wrote:
> Hi,
>
> I wonder if iCalendar is equally well supported by PyObjC as the
> Address-Book application on OS X? I tried to figure out the ICS
> format it imports and exports from my own files and specs like
> this: http://www.faqs.org/rfcs/rfc2445.html but there seem to be
> many magic IDs which I can't make much sense of. So I hesitate
> to seriously convert data to such a format and do a lot of trial
> and error testing.

It isn't so much a PyObjC support issue as it is a published API issue. 
  The AddressBook API was made public and mostly documented by Apple 
with the release of OS X 10.2.

The iCal API and the backing store behind it (there is a lot more going 
on than just the application itself) is still all private API.

With that said, the ICS format is very well documented via the RFC.   
For the purposes of exporting to iCal, it isn't that hard to write data 
that iCal can easily import.    As well, the publish/subscribe 
mechanism generally "just works" using the RFC documented formats.

In the context of PyObjC, I wrote a custom Cocoa client to the Web 
Service API of Intent (www.intentcenter.com -- if it complains about 
https, switch the URL to http... we have a certificate issue).  You 
could subscribe to the data from iCal (the Cocoa app simply created an 
HTTPServer and barfed up the ICS data whenever iCal requested it).

For the most part, you can ignore all of the magic unique identifiers.  
  Simply keep them consistent and iCal will do its best to update 
records (as opposed to creating new records).

Export/import is considerably easier, but less featureful, than 
syncronization.  The syncro APIs/protocol is all private at this point. 
  It is not *that* hard to reverse engineer and you can actually load 
the various conduits into Python via PyObjC at the command line as a 
sort of test bench.

But, no, none of this is documented.  When Apple makes the API 
available, you can rest assured that PyObjC will support it...

b.bum

[Pyobjc-dev] Support for iCalendar?

[Dinu G. <gh...@da...>]

Hi,

I wonder if iCalendar is equally well supported by PyObjC as the
Address-Book application on OS X? I tried to figure out the ICS
format it imports and exports from my own files and specs like
this: http://www.faqs.org/rfcs/rfc2445.html but there seem to be
many magic IDs which I can't make much sense of. So I hesitate
to seriously convert data to such a format and do a lot of trial
and error testing.

Regards,

Dinu

--
Dinu C. Gherman
......................................................................
"If the Nuremberg laws were applied, then every post-war American
president would have been hanged." (Noam Chomsky)

Re: [Pyobjc-dev] Re: [Python-Dev] Re: Masks in getargs.c (was: 2.3b1 release)

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

Folks, don't start hacking just yet (if any hacking needs to be done for
PyObjC): Guido just suggested keeping the old format characters 
compatible.
That may solve the problem.
--
- 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] Re: [Python-Dev] Re: Masks in getargs.c (was: 2.3b1 release)

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

On woensdag, apr 16, 2003, at 20:11 Europe/Amsterdam, Thomas Heller 
wrote:
> | How about the following counterproposal. This also changes some of 
> the
> | other format codes to be a little more regular.
> |
> | Code C type Range check
> |
> | b unsigned char 0..UCHAR_MAX
> | B unsigned char none **
> | h unsigned short 0..USHRT_MAX
> | H unsigned short none **
> | i int INT_MIN..INT_MAX
> | I * unsigned int 0..UINT_MAX
> | l long LONG_MIN..LONG_MAX
> | k * unsigned long none
> | L long long LLONG_MIN..LLONG_MAX
> | K * unsigned long long none
> |
> | Notes:
> |
> | * New format codes.
> |
> | ** Changed from previous "range-and-a-half" to "none"; the
> | range-and-a-half checking wasn't particularly useful.

Do I understand correctly that there is no format code that works on 
both
2.2 and 2.3 that converts 32 bit quantities without complaining
(B and H will work for 8 and 16 bit quantities)?

That may be a serious problem for PyObjC....
--
- 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] Another 0.9 todo

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

We should move the templates and examples to:

/Library/Developer/ProjectBuilder Extras/
/Library/Developer/Examples/

I asked a PB guru/engineer and this is the unofficially officially 
sanctioned spot for such things.

(I'll do this when I add the PBX Python colorizing stuff...)

b.bum

[Pyobjc-dev] 0.9 pre-release

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

Folks,

Ronald has prepared a pre-release of PyObjC 0.9:

  Binary: http://pyobjc.sourceforge.net/prerelease/pyobjc-0.9.dmg
  Source: http://pyobjc.sourceforge.net/prerelease/pyobjc-0.9.tar.gz

Please give it a good beating. Ronald is on vacation for another 12 days
or so, it would be great to get gather some feedback before he gets back
so we can do a proper public release a.s.a.p. Actually, he mentioned it
should be ready for release as-is, but Bill wants to do a couple more
things. Maybe a release can even be done before Ronald gets back.

Here's the 0.9 snippet from the NEWS file:

Version 0.9 (April-??-2003):
- This version includes numerous bugfixes and improvements.

- The module AppKit.NibClassBuilder has been moved to the package
  PyObjCTools.

- Usage of libFFI (http://sources.redhat.com/libffi) is now mandatory.
  The setup.py gives the impression that it isn't, but we do *not*
  support non-FFI builds.

- We actually have some documentation, more will be added in future
  releases.

- There are more Project Builder templates (see 'Project Templates').

- The InterfaceBuilder, PreferencePanes and ScreenSaver frameworks have
  been wrapped.

- Management of reference counts is now completely automatic, it is no
  longer necessary to manually compensate for the higher reference count
  of objects returned by the alloc, copy and copyWithZone: class
  methods.

- Various function and keyword arguments have been renamed for a better 
  integration with Cocoa. A partial list is of the changed names is:
    objc.lookup_class -> objc.lookUpClass
    objc.selector arguments/attributes:
        is_initializer -> isInitializer
        is_allocator -> isAlloc
        donates_ref -> doesDonateReference
        is_required -> isRequired
        class_method -> isClassMethod
        defining_class -> definingClass
        returns_self -> returnsSelf
        argument_types -> argumentTypes
        return_type -> returnType
    objc.get_class_list -> objc.getClassList

- On Python 2.2, objc.YES and objc.NO are instances of a private
boolean type, on Python 2.3 these are instances of the builtin type
bool.


Just

[Pyobjc-dev] [ pyobjc-Bugs-721137 ] setup.py install --help fails

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

Bugs item #721137, was opened at 2003-04-14 16:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=721137&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup.py install --help fails

Initial Comment:
If you run "python setup.py install --help" you get a stack trace.

Not very helpful:-)

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

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

Re: [Pyobjc-dev] step by step tutorial - second edition

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

On Thursday, Apr 3, 2003, at 23:05 Europe/Amsterdam, Just van Rossum 
wrote:

> Jack Jansen wrote:
>
>>> - Use 'PyObjCTools.AppHelper.runEventloop()' instead of your main
>
> Aaargh, I just noticed this spelling. I feel strongly it should be
>
>   "runEventLoop"
>
> "Event loop" is not one word, so camelcasing it should cause the L to 
> be
> capitalized.

Right. I just noticed another problem with this name, the event loop is 
called 'NSRunLoop' in Cocoa. Our name might be confusing for new users. 
Should I rename it to something like 'runApplicationMain'?

Ronald

Re: [Pyobjc-dev] step by step tutorial - second edition

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

On Friday, Apr 4, 2003, at 00:10 Europe/Amsterdam, Jack Jansen wrote:

>
> On donderdag, apr 3, 2003, at 23:05 Europe/Amsterdam, Just van Rossum 
> wrote:
>> Since the output of NibClassBuilder always needs to be manually edited
>> anyway, I see nothing against always adding the runEventLoop call. 
>> Good
>> idea!
>
> Ik sta op het punt om (na een biertje en een nachtje slaap) voor het 
> weekend
> naar Limburg te gaan, kan ik dit aan jou overlaten? Ik heb ook nog een 
> NibClassBuilder
> bug report gemaakt, trouwens. En een AppHelper bug (maar als je die 
> fixt graag ook even
> mijn tutorial:-)

Ik was al begonnen aan de NibClassBuilder bugmelding, ik neem dit 
meteen mee.

Veel plezier in Limburg,

	Ronald

Re: [Pyobjc-dev] step by step tutorial - second edition

[Chris R. <cp...@em...>]

On Wednesday, April 2, 2003, at 02:34  PM, Ronald Oussoren wrote:

> (*) Not that installing Python 2.3 would hurt, Apple's version of 
> Python 2.2 is ancient and Python 2.3 is way better than Python 2.2 
> even if you don't use the Mac-specific modules.

I'm sure this is preaching to the choir, but please do make sure that 
PyObjC can work with the Jaguar-distributed Python 2.2, so we can 
distribute small-ish bundles that don't require any additional Python 
installation to work "out of the box". Thanks.

Cheers!
--Chris Ryland / Em Software, Inc. / www.emsoftware.com

Re: [Pyobjc-dev] step by step tutorial - second edition

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

On donderdag, apr 3, 2003, at 23:05 Europe/Amsterdam, Just van Rossum 
wrote:
> Since the output of NibClassBuilder always needs to be manually edited
> anyway, I see nothing against always adding the runEventLoop call. Good
> idea!

Ik sta op het punt om (na een biertje en een nachtje slaap) voor het 
weekend
naar Limburg te gaan, kan ik dit aan jou overlaten? Ik heb ook nog een 
NibClassBuilder
bug report gemaakt, trouwens. En een AppHelper bug (maar als je die 
fixt graag ook even
mijn tutorial:-)
--
- 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] [ pyobjc-Bugs-714903 ] AppHelper crashes on exceptions.

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: AppHelper crashes on exceptions.

Initial Comment:
AppHelper.runEventLoop() crashes when there is an exception: it
uses traceback, but doesn't import this.

Moreover, I would also suggest a modification (that I actually
use in Doc/tutorial): re-raise the exception with "raise" if the
user chooses "quit". That way, you can set PYTHONINSPECT to 1,
run your PyObjC code and do post-mortem debugging when it
crashes.

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

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

[Pyobjc-dev] [ pyobjc-Bugs-714900 ] NibClassBuilder generates deprecated code

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: NibClassBuilder generates deprecated code

Initial Comment:
NibClassBuilder creates deprecated code when run as a script,
referring to itself as AppKit.NibClassBuilder. If this is fixed before
0.9 then the sample files in Doc/tutorial need to be fixed as well.

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

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

Re: [Pyobjc-dev] step by step tutorial - second edition

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

Jack Jansen wrote:

> > - Use 'PyObjCTools.AppHelper.runEventloop()' instead of your main 

Aaargh, I just noticed this spelling. I feel strongly it should be

  "runEventLoop"

"Event loop" is not one word, so camelcasing it should cause the L to be
capitalized.

> > function (that should also address your concern about the amount of 
> > boilerplate code).
> 
> Your other suggestions I have incorporated (or am incorporating right
> now, along with Bob's suggestion in private mail that I cater more
> for 2.2 users too), and actually I've put this in the document
> already too, but it just struck me that it would be a lot easier if
> NibClassBuilder would also optionally create the main program. Is it
> okay if I add a "--main" option to NibClassBuilder to do this?
> 
> Actually, coming to think of it, does it even have to be optional?
> The code is going to be inside an "if __name__ == '__main__':" guard
> anyway, so we could always add it. Or not?

Since the output of NibClassBuilder always needs to be manually edited
anyway, I see nothing against always adding the runEventLoop call. Good
idea!

Just

Re: [Pyobjc-dev] step by step tutorial - second edition

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

On woensdag, apr 2, 2003, at 21:34 Europe/Amsterdam, Ronald Oussoren 
wrote:

>
> On Wednesday, Apr 2, 2003, at 17:20 Europe/Amsterdam, Jack Jansen 
> wrote:
>
>> I've converted my step-by-step tutorial to Restructured Text, fixed a 
>> couple of things people reported and made the directory and file 
>> structure a bit more palatable. If people could have a look and 
>> comment on it (especially on the bits with "XXX editorial note" or 
>> "XXX implementation note") that would be helpful. I've included the 
>> generated HTML so you don't have to read the ReST source (or install 
>> the docutils) to read it.


> Step 5:
> - AppKit.NibClassBuilder has recently moved to 
> 'PyObjCTools.NibClassBuilder' (the former will also work in 0.9 but 
> will emit a warning).
> - Use 'PyObjCTools.AppHelper.runEventloop()' instead of your main 
> function (that should also address your concern about the amount of 
> boilerplate code).

Your other suggestions I have incorporated (or am incorporating right 
now, along with Bob's suggestion
in private mail that I cater more for 2.2 users too), and actually I've 
put this in the document
already too, but it just struck me that it would be a lot easier if 
NibClassBuilder would also
optionally create the main program. Is it okay if I add a "--main" 
option to NibClassBuilder to do
this?

Actually, coming to think of it, does it even have to be optional? The 
code is going to be
inside an "if __name__ == '__main__':" guard anyway, so we could always 
add it. Or not?
--
- 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] README-OLD, ReadMe, INSTALL files and more

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

On donderdag, apr 3, 2003, at 20:50 Europe/Amsterdam, Ronald Oussoren 
wrote:
>> Something else is that I think we should put the HTML output files for
>> the restructured text in the repository. True, those files are 
>> generated, but
>> I personally hate packages that require you to install a gazillion 
>> other things
>> you are not interested in before you can get them to work.
>
> I'm not sure about the repository, but I will make sure that the are 
> in the source tarball and the installer package.

The reason I would like to have the html in the repository too is that 
if person A. is
interested in tracking PyObjC developments but not in modifying the 
documentation
there's really no reason to make them install docutils.

But if you want to keep the repository clean of generated files: okay, 
I grudgingly
give in. What I *would* like then, though, is a setup.py script to 
create the html
(and warns you to install docutils if you haven't done so already).
--
- 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] README-OLD, ReadMe, INSTALL files and more

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

On Thursday, Apr 3, 2003, at 11:16 Europe/Amsterdam, Jack Jansen wrote:

> I think the readme files at the toplevel need some cleanup before a 
> 0.9 distribution.

You're right, these files are not very usefull if your new to PyObjC.

[usefull critique removed]

>
> Something else is that I think we should put the HTML output files for
> the restructured text in the repository. True, those files are 
> generated, but
> I personally hate packages that require you to install a gazillion 
> other things
> you are not interested in before you can get them to work.

I'm not sure about the repository, but I will make sure that the are in 
the source tarball and the installer package.

Ronald

[Pyobjc-dev] README-OLD, ReadMe, INSTALL files and more

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

I think the readme files at the toplevel need some cleanup before a 0.9 
distribution.

The stuff in ReadMe.txt is probably better suited for something called 
HISTORY
or some such, this isn't really the 100% essential stuff you want to 
know
when you've just downloaded the package. Some of the things in 
README-OLD
are probably better suited as the first thing to read.

INSTALL should be more explicit the version of libffi you need: the 
patched
one from the pyobjc download page. At least: I have not been able to 
use any
other one without surgery, not even the current one from the gcc CVS 
repository.

Something else is that I think we should put the HTML output files for
the restructured text in the repository. True, those files are 
generated, but
I personally hate packages that require you to install a gazillion 
other things
you are not interested in before you can get them to work.
--
Jack Jansen, <Jac...@cw...>, 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] Creating selectors for NSTimer

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

On Wednesday, Apr 2, 2003, at 22:59 Europe/Amsterdam, Antonio Rodriguez 
wrote:

> Hello all,
>
> trying to create a a selector argument for the creation of an NSTimer 
> from python code. Does anyone have the magic incantation required. I 
> figured that since PyObjC is so graceful, I could pass a string (ie, 
> 'self.doUpdate' for a method 'def doUpdate (self, sender):') but it 
> doesn't seem to work.
>
> Basically I'm trying to create an NSTimer to fire stuff off given that 
> threading doesn't work yet.

The names of your action methods should end in an underscore (e.g. 'def 
doUpdate_(self, sender):'). This is required due to the way this name 
is translated into an Objective-C method name, which in your cause 
would be -doUpdate:(id)sender.

Ronald

[Pyobjc-dev] Creating selectors for NSTimer

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

Hello all,

trying to create a a selector argument for the creation of an NSTimer 
from python code. Does anyone have the magic incantation required. I 
figured that since PyObjC is so graceful, I could pass a string (ie, 
'self.doUpdate' for a method 'def doUpdate (self, sender):') but it 
doesn't seem to work.

Basically I'm trying to create an NSTimer to fire stuff off given that 
threading doesn't work yet.

Thx

Antonio

Re: [Pyobjc-dev] step by step tutorial - second edition

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

On Wednesday, Apr 2, 2003, at 17:20 Europe/Amsterdam, Jack Jansen wrote:

> I've converted my step-by-step tutorial to Restructured Text, fixed a  
> couple of things people reported and made the directory and file  
> structure a bit more palatable. If people could have a look and  
> comment on it (especially on the bits with "XXX editorial note" or  
> "XXX implementation note") that would be helpful. I've included the  
> generated HTML so you don't have to read the ReST source (or install  
> the docutils) to read it.

Even though I do most of my hacking in Python 2.3 at the moment (PyObjC  
and otherwise), I think the tutorial should mention Apple's Python 2.2  
with Python 2.3 mentioned in footnotes. I definitely don't want peoply  
to get the impression that the must install a completely new python  
interpreter to use PyObjC (*).

I'd also include a link to the Objective-C tutorial you're mirroring  
(http://developer.apple.com/techpubs/macosx/Cocoa/ObjCTutorial/ 
index.html).

Step 4 can also be done as 'nibclassbuilder MainMenu.nib >  
CurrentConverter.py'. <offtopic>This is installed into /usr/bin when  
your using Apple's python, should fix this for our installer, with a  
Python 2.3 framework install it is installed somewhere inside the  
framework</offtopic>

Step 5:
- AppKit.NibClassBuilder has recently moved to  
'PyObjCTools.NibClassBuilder' (the former will also work in 0.9 but  
will emit a warning).
- Use 'PyObjCTools.AppHelper.runEventloop()' instead of your main  
function (that should also address your concern about the amount of  
boilerplate code).

Step 8:
- The translation of method names is described in `An introduction to  
PyObjC` (Doc/intro.txt), there is no real reference guide at the moment.
- The same document describes how to tell about argument types, but  
again there is no really detailed documentation about that.

Section 'Creating an applet for local use'
- This can be done using a buildapp.py script (just like the TableModel  
example), or not using '--link' in the invocation of bundlebuilder.py.  
If you include all sources as resources you end up with an applet that  
you can relocate to ~/Applications.

Section 'Creating a fullblown distributable applications'
- This is slightly harder at the moment. If your using Apple's python  
(and therefore targeting OSX 10.2) you just have to copy  
$PYLIB/site-packages/PyObjC/* and all other site-packages your using  
into build/CurrencyConverter.app/Resources.
- If your using a non-Apple python you're on your own. Bundlebuilder.py  
seems to have support for standalone applications, but I haven't used  
this yet.

>
> <pyobjc-currencyconverter-stepbystep.tgz>
>
> Shall I check this in? Where? Under what name?

Please do, in a subdirectory of either Doc/Tutorials or  
Examples/Tutorials. The former is probably better, this is mostly about  
documentation.

Many thanks for your work on this tutorial!

Ronald

> --
> Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack
> If I can't dance I don't want to be part of your revolution -- Emma  
> Goldman
>
(*) Not that installing Python 2.3 would hurt, Apple's version of  
Python 2.2 is ancient and Python 2.3 is way better than Python 2.2 even  
if you don't use the Mac-specific modules.

[Pyobjc-dev] step by step tutorial - second edition

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

I've converted my step-by-step tutorial to Restructured Text, fixed a 
couple of things people reported and made the directory and file 
structure a bit more palatable. If people could have a look and comment 
on it (especially on the bits with "XXX editorial note" or "XXX 
implementation note") that would be helpful. I've included the 
generated HTML so you don't have to read the ReST source (or install 
the docutils) to read it.

Re: [Pyobjc-dev] Interesting historic tidbit

[Lele G. <le...@se...>]

>>>>> Just van Rossum wrote:

    Just> I guess the project mentioned in the post below turned out
    Just> differently:

    Just> http://www.cwi.nl/www.python.org/search/hypermail/python-recent=
/0994.html

    Just> It's good to see that Guido's first suggested Python syntax
    Just> for ObjC method calls matches PyObjC's exactly...

Yum, I must try harder to find the time to collect my memories on that
period, as I promised to bbum.

I remember that at that time I asked GvR a somewhat deeper change to
the calling mechanism in Python to allow, with a new flag, a method to
collect its keyword args in a dual-faced object behaving both as list
and as a dictionary, thus permitting a closer look&feel between the
two languages by respecting keywords order, as is in ObjC. I even
produced some sort of patch against Python 1.2, but Guido never
accepted the proposal, and finally dropped official objc support (in
1.3?) :/

Thanx for bringing this to my attention ;-)

bye, lele.
--=20
nickname: Lele Gaifax	| Quando vivr=F2 di quello che ho pensato ieri
real: Emanuele Gaifas	| comincer=F2 ad aver paura di chi mi copia.
email: le...@se...	|		-- Fortunato Depero, 1929.

[Pyobjc-dev] Interesting historic tidbit

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

I guess the project mentioned in the post below turned out differently:

http://www.cwi.nl/www.python.org/search/hypermail/python-recent/0994.
html

It's good to see that Guido's first suggested Python syntax for ObjC
method calls matches PyObjC's exactly...

Just

Re: [Pyobjc-dev] Incompatible change in CVS

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

On Saturday, Mar 29, 2003, at 22:56 Europe/Amsterdam, Just van Rossum 
wrote:

>> It is also no longer necessary to call the release method on objects
>> allocated using the 'alloc' classmethod, due to a fix for bug 711700.
>
> But does this also mean that code that _does_ release objects that were
> allocated using alloc will now crash?

Yes. I've intentionaly not mentioned that you should have called 
release upto now, because doing this manually is bad IMNSHO. Python 
programmers won't expect that they have to do manual memory management 
and there is no technical reason for not doing it automaticly.

Note that you can always increate the retainCount before calling 
autorelease if you do want to create an autoreleased object 
(appearantly this can be usefull in non-GUI situations such as 
webobjects).

Ronald