pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Dinu's ReSTEdit Refactored

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

b.bum:

> It won't run on 10.2.8, that is certain, as I'm using Cocoa Bindings.

Pitty. It would have been nice to have it on 10.2 as well...

> I'm not sure why it won't work under 10.3.2.  Are you using 
> buildapp.py or are you building via the Xcode project?  If 
> buildapp.py, it likely needs to have the WebKit framework added to the 
> build.

Yes, I'm using buildapp.py and have no Xcode yet on my other
box. If you don't mind to adapt the buildapp.py script as
needed, that would be great.

Thanks,

Dinu

[Pyobjc-dev] ReSTedit and buildapp.py

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

Fixed.

I had been building the app solely with Xcode and had not sync'd 
buildapp.py.   By adding an appropriate import to the main file and 
fixing buildapp.py, the app should work when built from buildapp.py.

Note that the buildapp.py result will launch more slowly than the 
version built from Xcode (embedded vs. execve() style interpreter 
startup).

b.bum

Re: [Pyobjc-dev] Dinu's ReSTEdit Refactored

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

On Feb 17, 2004, at 1:46 AM, Dinu Gherman wrote:
> Now I've built it on 10.2.8 with PyObjC from CVS, but on both,
> 10.2.8 (with Safari 1.0) and 10.3.2 (with Sadari 1.2), I'm getting
> this message when launching this version of ReSTedit:
>
> Traceback (most recent call last):
>   File  
> "/Users/dinu/Desktop/source/build/ReSTedit.app/Contents/Resources/ 
> __main__.py", line 21, in ?
>     sys.exit(AppKit.NSApplicationMain([]))
> objc.error: NSInvalidUnarchiveOperationException - ***  
> -[NSKeyedUnarchiver decodeObjectForKey:]: cannot decode object of  
> class (WebView)

It won't run on 10.2.8, that is certain, as I'm using Cocoa Bindings.

I'm not sure why it won't work under 10.3.2.  Are you using buildapp.py  
or are you building via the Xcode project?  If buildapp.py, it likely  
needs to have the WebKit framework added to the build.

b.bum

Re: [Pyobjc-dev] NSFont.alloc() no more needed?

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

On Feb 17, 2004, at 9:07 AM, Dinu Gherman wrote:

> Bob Ippolito:
>
>> ClassName.alloc().classMethod() has never been correct code.  This  
>> pythonism was intentionally changed in PyObjC to accommodate for the  
>> fact that ObjC has separate namespaces for instance methods and class  
>> methods (class methods are really metaclass methods in ObjC).
>
> But when and where did it change?

I don't recall exactly when, but it was over a month ago.

https://sourceforge.net/tracker/? 
func=detail&atid=114534&aid=836342&group_id=14534

-bob

Re: [Pyobjc-dev] NSFont.alloc() no more needed?

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

Bob Ippolito:

> ClassName.alloc().classMethod() has never been correct code.  This 
> pythonism was intentionally changed in PyObjC to accommodate for the 
> fact that ObjC has separate namespaces for instance methods and class 
> methods (class methods are really metaclass methods in ObjC).

But when and where did it change?

Dinu

Re: [Pyobjc-dev] NSFont.alloc() no more needed?

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

On Feb 17, 2004, at 8:14 AM, Dinu Gherman wrote:

> Something weird is going on... I often use code like this:
>
>   from AppKit import NSFont
>   f = NSFont.alloc().fontWithName_size_("Courier", 12)
>
> which worked perfectly well until very recently, giving me now:
>
>   AttributeError: 'NSFont' object has no attribute 'fontWithName_size_'
>
> I'm getting this on PyObjC 1.1 a0 as well as on the CVS version.
> But when moving to the following syntax things magically work
> as they did before:
>
>   f = NSFont.fontWithName_size_("Courier", 12)
>
> The only possible explanation I can come up with is that I've
> recompiled libffi inbetween. Is the alloc() no longer needed
> or has libffi changed or has anybody else a good explanation?

ClassName.alloc().classMethod() has never been correct code.  This 
pythonism was intentionally changed in PyObjC to accommodate for the 
fact that ObjC has separate namespaces for instance methods and class 
methods (class methods are really metaclass methods in ObjC).

-bob

[Pyobjc-dev] NSFont.alloc() no more needed?

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

Hi,

Something weird is going on... I often use code like this:

   from AppKit import NSFont
   f = NSFont.alloc().fontWithName_size_("Courier", 12)

which worked perfectly well until very recently, giving me now:

   AttributeError: 'NSFont' object has no attribute 'fontWithName_size_'

I'm getting this on PyObjC 1.1 a0 as well as on the CVS version.
But when moving to the following syntax things magically work
as they did before:

   f = NSFont.fontWithName_size_("Courier", 12)

The only possible explanation I can come up with is that I've
recompiled libffi inbetween. Is the alloc() no longer needed
or has libffi changed or has anybody else a good explanation?

Thanks,

Dinu

Re: [Pyobjc-dev] Dinu's ReSTEdit Refactored

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

Ronald Oussoren:

> Thanks for that message, appearently setup.py needs an update.
>
> You should remove /Library/Python/2.3/PyObjC before installing. If  
> that doesn't help something else broke.

Ok, that's better...

Now I've built it on 10.2.8 with PyObjC from CVS, but on both,
10.2.8 (with Safari 1.0) and 10.3.2 (with Sadari 1.2), I'm getting
this message when launching this version of ReSTedit:

Traceback (most recent call last):
   File  
"/Users/dinu/Desktop/source/build/ReSTedit.app/Contents/Resources/ 
__main__.py", line 21, in ?
     sys.exit(AppKit.NSApplicationMain([]))
objc.error: NSInvalidUnarchiveOperationException - ***  
-[NSKeyedUnarchiver decodeObjectForKey:]: cannot decode object of class  
(WebView)

Bill?

Dinu

[Pyobjc-dev] electromotive bicycles

[asia <cl...@ed...>]

dear sirs 
   as you know,China is the most largest e-bicycle porducers,it produces no
polution and solves the traffic jam problem,so it is the most suitable
traffic tools for 21th centry.
   we have all kind of quaffied e-bicycles at very low price,if you have
some insterest,please let us know,we would meet what you really need.
                                 
                                                 sincerely asia

Re: [Pyobjc-dev] Cocoa Bindings (was: Re: Default to returning (void)?)

[Marc-Antoine P. <map...@ac...>]

Le 04-02-16, =E0 11:03, b.bum a =E9crit :

> For once, I may have managed to beat Ronald to this.  Let's hope I got=20=

> it right.
...
> def Accessor(func):
>     """
>     Return an Objective-C method object that is conformant with=20
> key-value coding
>     and key-value observing.
>     """
>     argCount =3D func.func_code.co_argcount
>     if argCount is 2:
>         return selector(func, signature=3D"v@:@")
>     elif argCount is 1:
>         return selector(func, signature=3D"@@:")
>     elif argCount is 0:
>         raise ValueError, "Too few arguments to function '%s'.  Cannot=20=

> create selector." % foo.func_name
>     else:
>         raise ValueError, "Too many arguments to function '%s'. =20
> Cannot create selector." % foo.func_name
...
> I added Accessor() to objc.   Accessor is the generic term for the=20
> setters and getters in Key-Value Coding.  The Accessor() function=20
> tries to intelligently determine if it should return the setter or=20
> getter signature.   I can see two problems with that:
> On the 'performance hack' front, supporting indexed accessors in an=20
> automated fashion would also be useful, but I haven't thought about=20
> how useful that might truly be or what implementation pattern should=20=

> be used.

Se were you planning to have an indexedAccessor as a separate function=20=

type?
Because from what I read, the indexed key-value accessor methods are a=20=

bit more complex, and one cannot rely on signatures alone:

getters:
	Core:
		-(uint)countOf<Key>
		-(id)objectIn<Key>AtIndex:
	Optional:
		-(id[])get<Key>:(uint)range:(uint)
setters:
	Core:
		-(void)insertObject:(id)in<Key>AtIndex: (uint)
		-(void)removeObjectFrom<Key>AtIndex:(uint)
	Optional:
		-(void)replaceObjectIn<Key>AtIndex:(uint)withObject:(id)

So what do we do now, if we implement all of these in a Python class?
Python argcount is obviously not the answer. The options I see are
1) introduce so many method types (indexedGetter, indexedInsert,=20
indexedCounter...)
2) Rely on name structures using the same conventions as objective-C
3) assume that any python collection will be handled by an attribute=20
slot

It is made all the more complicated by the fact that the to-many=20
relationships in ObjC can have meta-information that declares the=20
inverse relationship between to objects. Would you want to go so far?

I suggest we all think carefully about this and other KV coding issues,=20=

as it might impact what ends up being the "best" solution for atomic=20
accessors.

Marc-Antoine

Re: [Pyobjc-dev] Default to returning (void)?

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

On Feb 16, 2004, at 10:27 AM, Ronald Oussoren wrote:
> You did manage to beat me. There's one thing I don't like about your 
> change: the function name, I prefer an initial lowercase letter. That 
> also reads nicer with the proposed syntax changes for properties:
>
> 	def objc.accessor setFoo(self, newFoo):
> 	
> or
> 	def setFoo(self, newFoo) [objc.accessor]:

I'm somewhat indifferent to casing on this.  I chose Accessor over 
accessor because it matched the case of IBAction and IBOutlet.   Given 
the usage pattern, 'accessor' works fine, too.

> I'm not yet 100% sure if I like a single function instead of a pair of 
> functions.

The KVO/KVC use 'accessor method' or 'accessor methods' to refer to 
both the setter and getter.   I chose a single function implementation 
to continue that usage pattern.   Personally, I like the single 
function pattern because it eliminates a detail from the resulting 
implementation;  it perpetuates the notion that PyObjC's bridge should 
be as thin and transparent as possible.

b.bum

Re: [Pyobjc-dev] Default to returning (void)?

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

On 16-feb-04, at 17:03, b.bum wrote:

> On Feb 16, 2004, at 7:50 AM, Ronald Oussoren wrote:
>> On 16-feb-04, at 16:15, Marc-Antoine Parent wrote:
>>> Le 04-02-16, =E0 00:00, b.bum a =E9crit :
>> I'm all for adding easy to use names instead of using selector()=20
>> directly, we'll have to do that anyway if we want to use syntactic=20
>> sugar later on.
>>
>> CVS will soon contain the functions that Bob proposed.
>
> For once, I may have managed to beat Ronald to this.  Let's hope I got=20=

> it right.

You did manage to beat me. There's one thing I don't like about your=20
change: the function name, I prefer an initial lowercase letter. That=20
also reads nicer with the proposed syntax changes for properties:

	def objc.accessor setFoo(self, newFoo):
=09
or
	def setFoo(self, newFoo) [objc.accessor]:


I'm not yet 100% sure if I like a single function instead of a pair of=20=

functions.

Ronald

--
X|support bv            http://www.xsupport.nl/
T:  +31 610271479       F:  +31 204416173

Re: [Pyobjc-dev] Dinu's ReSTEdit Refactored

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

On 16-feb-04, at 19:02, Dinu Gherman wrote:

> b.bum:
>
>> That is correct.
>>
>>> Thanks for jumping on it! Am I right to believe that it depends
>>> on a CVS build of PyObjC? See this error message:
>
> Hmm, what about this one after compiling from CVS...?
>
> Dinu
>
> Importing objc failed
> Traceback (most recent call last):
>   File  
> "/Users/dinu/Desktop/source/build/ReSTedit.app/Contents/Resources/ 
> __main__.py", line 10, in ?
>     import objc
>   File "/usr/lib/python2.3/site-packages/PyObjC/objc/__init__.py",  
> line 103, in ?
>     from _convenience import CONVENIENCE_METHODS, CLASS_METHODS
>   File "/usr/lib/python2.3/site-packages/PyObjC/objc/_convenience.py",  
> line 354, in ?
>     from _Foundation import NSDecimal
> ImportError: cannot import name NSDecimal
>

Thanks for that message, appearently setup.py needs an update.

You should remove /Library/Python/2.3/PyObjC before installing. If that  
doesn't help something else broke.

Ronald
--
X|support bv            http://www.xsupport.nl/
T:  +31 610271479       F:  +31 204416173

Re: [Pyobjc-dev] Dinu's ReSTEdit Refactored

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

b.bum:

> That is correct.
>
>> Thanks for jumping on it! Am I right to believe that it depends
>> on a CVS build of PyObjC? See this error message:

Hmm, what about this one after compiling from CVS...?

Dinu

Importing objc failed
Traceback (most recent call last):
   File  
"/Users/dinu/Desktop/source/build/ReSTedit.app/Contents/Resources/ 
__main__.py", line 10, in ?
     import objc
   File "/usr/lib/python2.3/site-packages/PyObjC/objc/__init__.py", line  
103, in ?
     from _convenience import CONVENIENCE_METHODS, CLASS_METHODS
   File "/usr/lib/python2.3/site-packages/PyObjC/objc/_convenience.py",  
line 354, in ?
     from _Foundation import NSDecimal
ImportError: cannot import name NSDecimal

Re: [Pyobjc-dev] Dinu's ReSTEdit Refactored

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

That is correct.

On Feb 16, 2004, at 9:27 AM, Dinu Gherman wrote:

> b.bum:
>
>> I have been writing a bunch of Restructured Text recently and decided  
>> I needed a tool better than Emacs.   This reminded me of Dinu's  
>> wonderful ReSTEdit example.
>
> Thanks for jumping on it! Am I right to believe that it depends
> on a CVS build of PyObjC? See this error message:
>
> Traceback (most recent call last):
>   File  
> "/Users/dinu/Desktop/source/build/ReSTedit.app/Contents/Resources/ 
> __main__.py", line 16, in ?
>     import REDocument
>   File  
> "/Users/dinu/Desktop/source/build/ReSTedit.app/Contents/Resources/ 
> REDocument.py", line 12, in ?
>     from objc import YES, NO, Accessor
> ImportError: cannot import name Accessor

Re: [Pyobjc-dev] Dinu's ReSTEdit Refactored

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

b.bum:

> I have been writing a bunch of Restructured Text recently and decided  
> I needed a tool better than Emacs.   This reminded me of Dinu's  
> wonderful ReSTEdit example.

Thanks for jumping on it! Am I right to believe that it depends
on a CVS build of PyObjC? See this error message:

Traceback (most recent call last):
   File  
"/Users/dinu/Desktop/source/build/ReSTedit.app/Contents/Resources/ 
__main__.py", line 16, in ?
     import REDocument
   File  
"/Users/dinu/Desktop/source/build/ReSTedit.app/Contents/Resources/ 
REDocument.py", line 12, in ?
     from objc import YES, NO, Accessor
ImportError: cannot import name Accessor

Dinu

Re: [Pyobjc-dev] Cocoa Bindings (was: Re: Default to returning (void)?)

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

On Feb 16, 2004, at 8:42 AM, Marc-Antoine Parent wrote:
> Sounds great. I did not realize this, as I had not seen any trace of 
> the Controller classes in {Lib|Modules}/Foundation/*
> I have not done it yet, but I meant to attempt the Currency converter 
> from the Bindings example in PyObjC. If I make it sometime in the next 
> week, should it make it to the Examples? or do you have better 
> examples in the work for controllers?

Credit for that goes to Ronald, the transparency of the PyObjC bridge, 
and the brilliant engineers at Apple that built the bindings layer (I 
can say that because it was built before I joined that particular team 
:)....

There wasn't any kind of special bridging required for the various 
Controller classes.   As long as an object can do key/value coding and 
key/value observing, it will work with the controller layer.

Automatic Key/Value observing is currently a challenge.   There have 
been a number of patches that addressed issues with KVO and, at this 
point, it mostly "just works".   As previously mentioned, having a set 
of unit tests that provide decent testing coverage is on the todo list.

On the 'performance hack' front, supporting indexed accessors in an 
automated fashion would also be useful, but I haven't thought about how 
useful that might truly be or what implementation pattern should be 
used.

As it stands, the Currency Converter should be able to be ported 
without much effort.   I would recommend starting with the examples and 
docs on developer.apple.com as they are the most up to date source of 
info....

b.bum

[Pyobjc-dev] Dinu's ReSTEdit Refactored

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

I have been writing a bunch of Restructured Text recently and decided I 
needed a tool better than Emacs.   This reminded me of Dinu's wonderful 
ReSTEdit example.

So, I grabbed the source and modified it a bit to be more convenient.   
It is mid-refactor right now, but is quite usable.   The toolbar is 
just a placeholder.   The big features are that it now supports 
side-by-side ReST editing w/preview on right, the preview is now done 
in a WebView (leveraging all that is Safari), and the content is only 
re-rendered after 5 seconds of no text-changing events.

Dinu was open to having ReSTedit live in a revision control system and, 
as such, it is now hosted in an SVN repository @ red-bean.  Dinu and I 
have commit rights.

Subversion repository:

	http://svn.red-bean.com/restedit/

You don't need a subversion client to check out the HEAD revision.  I 
believe you should be able to mount this in Finder and simply 
drag-n-drop a copy of the trunk.

ToDo list:

	http://svn.red-bean.com/restedit/trunk/TODO.txt

b.bum

[Pyobjc-dev] Cocoa Bindings (was: Re: Default to returning (void)?)

[Marc-Antoine P. <map...@ac...>]

>> I must admit that I haven't read those documents yet, and haven't 
>> done much with Cocoa Bindinds, but it is my intention that Cocoa 
>> Bindings "just work" without special code in python. We're probably 
>> not there yet, although Cocoa Bindings should work just fine.
>
> It mostly "just works" right now.  There are a couple of areas that 
> have been problematic in the past, but I believe they have mostly been 
> fixed.

Sounds great. I did not realize this, as I had not seen any trace of 
the Controller classes in {Lib|Modules}/Foundation/*
I have not done it yet, but I meant to attempt the Currency converter 
from the Bindings example in PyObjC. If I make it sometime in the next 
week, should it make it to the Examples? or do you have better examples 
in the work for controllers?
Marc-Antoine

Re: [Pyobjc-dev] Default to returning (void)?

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

On Feb 16, 2004, at 7:50 AM, Ronald Oussoren wrote:
>> Aside: I just had a look at the Cocoa Bindings documentation, and was 
>> very impressed. I do hope we will be able to exploit this from PyObjC 
>> as seamlessly as possible, and if my (still very, very limited) 
>> understanding of PyObjC serves me right, following the K-V standards 
>> is still a stumbling block, and this would definitely help. Please 
>> correct me if I got it all wrong, and it is totally unrelated after 
>> all!
>
> I must admit that I haven't read those documents yet, and haven't done 
> much with Cocoa Bindinds, but it is my intention that Cocoa Bindings 
> "just work" without special code in python. We're probably not there 
> yet, although Cocoa Bindings should work just fine.

It mostly "just works" right now.  There are a couple of areas that 
have been problematic in the past, but I believe they have mostly been 
fixed.

It is on my rather long todo list to right a series of unit tests 
against KVO and KVC that exercise all the myriad of features 
thoroughly.   Since that particular task coincides nicely with my day 
job, it may actually get done.   Having a thorough test of KVO/KVC from 
a bridged language will actually be very helpful to me.

b.bum

Re: [Pyobjc-dev] Default to returning (void)?

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

On Feb 16, 2004, at 7:50 AM, Ronald Oussoren wrote:
> On 16-feb-04, at 16:15, Marc-Antoine Parent wrote:
>> Le 04-02-16, =E0 00:00, b.bum a =E9crit :
> I'm all for adding easy to use names instead of using selector()=20
> directly, we'll have to do that anyway if we want to use syntactic=20
> sugar later on.
>
> CVS will soon contain the functions that Bob proposed.

For once, I may have managed to beat Ronald to this.  Let's hope I got=20=

it right.

I added Accessor() to objc.   Accessor is the generic term for the=20
setters and getters in Key-Value Coding.  The Accessor() function tries=20=

to intelligently determine if it should return the setter or getter=20
signature.   I can see two problems with that:

- what if it is overriding an already existing setter/getter?  In that=20=

case, the signature should be determined by the super.

- what if the developer wants to return a scalar type?

def Accessor(func):
     """
     Return an Objective-C method object that is conformant with=20
key-value coding
     and key-value observing.
     """
     argCount =3D func.func_code.co_argcount
     if argCount is 2:
         return selector(func, signature=3D"v@:@")
     elif argCount is 1:
         return selector(func, signature=3D"@@:")
     elif argCount is 0:
         raise ValueError, "Too few arguments to function '%s'.  Cannot=20=

create selector." % foo.func_name
     else:
         raise ValueError, "Too many arguments to function '%s'.  Cannot=20=

create selector." % foo.func_name

Re: [Pyobjc-dev] Default to returning (void)?

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

On 16-feb-04, at 16:15, Marc-Antoine Parent wrote:

> Le 04-02-16, =E0 00:00, b.bum a =E9crit :
>> 	def takeAction_(self, sender):
>> 		pass
>> 	takeAction_ =3D selector(takeAction_, type=3D'action')
>
> ...
> Le 04-02-16, =E0 00:11, Bob Ippolito a =E9crit :
>> Why not objc.getter / objc.setter / objc.action?  This is really why=20=

>> Python needs a way to decorate functions that isn't so f*!@#!ing=20
>> ugly.
>
> I am just a clueless lurker, but +1 to having those transformations=20
> sooner rather than later, with as nice a name as you all can devise.=20=

> If we also get syntax sugar at some point, as per Michael Hudson's=20
> post, all the better, but I feel that we (PyObjC users) need a way to=20=

> say those things that does not depend on ObjC selector syntax.

I'm all for adding easy to use names instead of using selector()=20
directly, we'll have to do that anyway if we want to use syntactic=20
sugar later on.

CVS will soon contain the functions that Bob proposed.

>
> Aside: I just had a look at the Cocoa Bindings documentation, and was=20=

> very impressed. I do hope we will be able to exploit this from PyObjC=20=

> as seamlessly as possible, and if my (still very, very limited)=20
> understanding of PyObjC serves me right, following the K-V standards=20=

> is still a stumbling block, and this would definitely help. Please=20
> correct me if I got it all wrong, and it is totally unrelated after=20
> all!

I must admit that I haven't read those documents yet, and haven't done=20=

much with Cocoa Bindinds, but it is my intention that Cocoa Bindings=20
"just work" without special code in python. We're probably not there=20
yet, although Cocoa Bindings should work just fine.

Ronald
--
X|support bv            http://www.xsupport.nl/
T:  +31 610271479       F:  +31 204416173

Re: [Pyobjc-dev] Default to returning (void)?

[Marc-Antoine P. <map...@ac...>]

Le 04-02-16, =E0 00:00, b.bum a =E9crit :
> Barring automated intelligence, being able to do something like the=20
> following would be preferable to the crypting exposed signatures we=20
> have today.
>
>     def setContent_(self, someContent):
>         print "Setting content...."
>         self._content =3D someContent
>     setContent_ =3D selector(setContent_, type=3D'setter')
> 	objc.makeSetter(setContent_) # this would be even better
>
> 	def takeAction_(self, sender):
> 		pass
> 	takeAction_ =3D selector(takeAction_, type=3D'action')

...
Le 04-02-16, =E0 00:11, Bob Ippolito a =E9crit :
> Why not objc.getter / objc.setter / objc.action?  This is really why=20=

> Python needs a way to decorate functions that isn't so f*!@#!ing ugly.

I am just a clueless lurker, but +1 to having those transformations=20
sooner rather than later, with as nice a name as you all can devise. If=20=

we also get syntax sugar at some point, as per Michael Hudson's post,=20
all the better, but I feel that we (PyObjC users) need a way to say=20
those things that does not depend on ObjC selector syntax.

Aside: I just had a look at the Cocoa Bindings documentation, and was=20
very impressed. I do hope we will be able to exploit this from PyObjC=20
as seamlessly as possible, and if my (still very, very limited)=20
understanding of PyObjC serves me right, following the K-V standards is=20=

still a stumbling block, and this would definitely help. Please correct=20=

me if I got it all wrong, and it is totally unrelated after all!

Marc-Antoine

[Pyobjc-dev] Re: Default to returning (void)?

[Michael H. <mw...@py...>]

Bob Ippolito <bo...@re...> writes:

> On Feb 16, 2004, at 5:26 AM, Michael Hudson wrote:
>
>> Bob Ippolito <bo...@re...> writes:
>>
>>> Why not objc.getter / objc.setter / objc.action?  This is really why
>>> Python needs a way to decorate functions that isn't so f*!@#!ing
>>> ugly.
>>
>> I've only had a patch to do that for ... 3? ... years now.  Maybe it's
>> finally time to agitate on its behalf properly on python-dev.
>
> Sounds like a good plan, where's the patch,

The patch is at 

    http://starship.python.net/crew/mwh/hacks/meth-syntax-sugar-3.diff

It has been discussed a bit on python-dev already (part of those huge
threads about syntax ~9 months back);

 http://www.google.com/search?q=+site:mail.python.org+%22meth-syntax-sugar%22

is a good start :-)

I assume that patch applies cleanly; haven't actually tried it lately.

> and does it already have a PEP?

It's kinda covered by PEP 318, but that advocates a different syntax
variant.

Cheers,
mwh

-- 
  MARVIN:  What a depressingly stupid machine.
                    -- The Hitch-Hikers Guide to the Galaxy, Episode 7

Re: [Pyobjc-dev] Re: Default to returning (void)?

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

On Feb 16, 2004, at 5:26 AM, Michael Hudson wrote:

> Bob Ippolito <bo...@re...> writes:
>
>> Why not objc.getter / objc.setter / objc.action?  This is really why
>> Python needs a way to decorate functions that isn't so f*!@#!ing
>> ugly.
>
> I've only had a patch to do that for ... 3? ... years now.  Maybe it's
> finally time to agitate on its behalf properly on python-dev.

Sounds like a good plan, where's the patch, and does it already have a 
PEP?

-bob