pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] NGPython

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

On Feb 29, 2004, at 12:13 PM, Helge Hess wrote:
> With the mapping mechanism taking keywords and positional parameters 
> into account.
> I think that this was much more beautiful than the current automatic 
> ":" => "_" scheme used in PyObjC ;-)

It fails this simple test:  can the mapping rule be expressed as a 
single rule.

The ":" -> "_" mapping, though ugly (really -- none of us are attached 
to it), can:

"Given an ObjC method name, replace all ":" with "_" to find the python 
name."

A 'bridget' style mapping cannot.  There will be special cases and the 
end result will be a new language that is effectively a hybrid between 
Python and Objective-C.

Just like the Java<->Objective-C bridge, such an approach to "mapping" 
Objective-C methods into Python in a "Pythonic" fashion will yield 
something that requires the developer to learn a new language.

To use the provided examples:

>   set = NSSet(array=myarray)
>   set = NSSet(set=otherSet)

Neither of these are meaningful to either the Python or Objective-C 
developer.   The current form is as follows:

set = NSSet.setWithArray_(myarray)
set = NSSet.setWithSet_(otherSet)

While the trailing '_' are unpalatable to the traditional Python 
programmer, it is extremely clear exactly what the code is doing.  If 
not, the developer only has to remember one rule to figure out what bit 
of Foundation documentation to read to figure it out.

Relevant post here:

http://www.pycs.net/bbum/2003/11/29.html

Thread starts here:

http://mail.python.org/pipermail/pythonmac-sig/2002-October/006458.html

b.bum

[Pyobjc-dev] NGPython

[Helge H. <hel...@op...>]

Hi,

just tried out the 1.1b1 release, very nice :-)

Actually I have written an Objective-C bridge for Python on 
GNUstep/libFoundation some five years ago, this was called NGPython. 
While it doesn't seem to compile anymore out of the box even on 
GNUstep, I thought someone might be interested in ripping of some code 
nevertheless.

The most interesting part is probably the "pybridget2.py" tool 
contained in NGPython. This is actually a parser for headers and "jobs" 
files - similiar to those used for the NeXT Java bridge, and for 
generating class wrapping information.
It was pretty flexible on mapping Python function names to selectors:
---snip---
class NSSet = FoundationCollections.NSSet
   constructor -initWithArray:
   constructor -initWithSet:
   @{
keyConstructors = { "array":  "initWithArray",
                     "set":    "initWithSet" }
lenConstructors = { 0: "init", 1: "initWithArray" }
   @}
   -allObjects
---snap---
For construction of Python objects you could then use code like this:
---snip---
   set = NSSet(array=myarray)
   set = NSSet(set=otherSet)
---snap---
With the mapping mechanism taking keywords and positional parameters 
into account.
I think that this was much more beautiful than the current automatic 
":" => "_" scheme used in PyObjC ;-)


So, if someone is interested, drop me a line and I send you the code 
;-) Unfortunately I won't find the time to look at adding the mapping 
stuff to PyObjC, but maybe someone else has ...

best regards,
   Helge
-- 
http://docs.opengroupware.org/Members/helge
OpenGroupware.org

[Pyobjc-dev] Souper Seckscoleadura

[leisha l. <hs...@ya...>]

Did you know That the normal co|st for Super V|agra is 20 bucks, per do|se=
? We 
are running a hot spec|ial t00day Its only an amazing 3 bucksShipped world=
 wide! get more secks
<a href=3D"http://niceways.net/sv/index.php?pid=3Deph6636">DISC|0UNT 0RD|E=
RS</a> hereditario

[Pyobjc-dev] Link Exchange Request

[Link M. <li...@bu...>]

Hi

I recently visited your website pyobjc.sourceforge.net
I feel your site would make a great addition to my link directory found at 
http://buyforeclosurereports.com/linksdirectory
As you already know exchanging links is a great way to increase traffic to
your site.
I have already added your link under the general links theme. You will be
able to change the theme and description for your link on the site below.

Submit your link here: http://buyforeclosurereports.com/submitalink.php

Thank you in advance
Brian Kleiner
http://buyforeclosurereports.com

[Pyobjc-dev] Re: [Python-Dev] Plea for function/method syntax sugar (PEP 318, with a different syntax)

[Sjoerd M. <sj...@ac...>]

Barry Warsaw wrote:
> On Wed, 2004-02-18 at 21:26, Bob Ippolito wrote:
> 
> 
>>the latest version of mwh's patch is here:  
>>http://starship.python.net/crew/mwh/hacks/meth-syntax-sugar-3.diff
> 
> 
> Does anybody else have problems applying this patch?  I get:
> 
> % patch < meth-syntax-sugar-3.diff
> patch: **** File Grammar is not a regular file -- can't patch
> 
> Grammar/Grammar sure seems like a regular file to me though.  Standard
> RH9 patch(1), v 2.5.4.  Above patch snagged with wget.

Try patch -p0.  Patch removes directory names by default.

-- 
Sjoerd Mullender <sj...@ac...>

[Pyobjc-dev] atlantic re: company downsizing

[Luis <ocp...@ya...>]

GET YOUR UNIVERSITY DIPLOMA

Do you want a prosperous future, increased earning power more money and th=
e respect of all?

Call this number: 1-646-304-7925 (24 hours)                 LNorman

There are no required tests, classes, books, or interviews!
 
Get a Bachelors, Masters, MBA, and Doctorate (PhD) diploma!
 
Receive the benefits and admiration that comes with a diploma!
 
No one is turned down! 

Call Today  1-646-304-7925  (7 days a week)

Confidentiality assured! 


Tue, 24 Feb 2004 14:19:57 -0500 niggardly cowpea flannel city original sec=
ure abduct elves cicero who'd confidante bedspring bromine confessor laure=
nt squatter cabal blab sideway nary fluster perimeter substantial hebrew y=
ou'd debate beachcomb droopy mulch abyss debugging fugitive=20.
NEWS: earning more boa cornelia yea trial refer bryant incomprehensible do=
t orphan guttural rhoda demon donnelly biota lumpur=20.

[Pyobjc-dev] Re: [Python-Dev] Plea for function/method syntax sugar (PEP 318, with a different syntax)

[Barry W. <ba...@py...>]

On Tue, 2004-02-24 at 11:14, Sjoerd Mullender wrote:

> Try patch -p0.  Patch removes directory names by default.

Blah.  D'uh.  Thanks.

-B

[Pyobjc-dev] Re: [Python-Dev] Plea for function/method syntax sugar (PEP 318, with a different syntax)

[Barry W. <ba...@py...>]

On Wed, 2004-02-18 at 21:26, Bob Ippolito wrote:

> the latest version of mwh's patch is here:  
> http://starship.python.net/crew/mwh/hacks/meth-syntax-sugar-3.diff

Does anybody else have problems applying this patch?  I get:

% patch < meth-syntax-sugar-3.diff
patch: **** File Grammar is not a regular file -- can't patch

Grammar/Grammar sure seems like a regular file to me though.  Standard
RH9 patch(1), v 2.5.4.  Above patch snagged with wget.

-Barry

Re: [Pyobjc-dev] PyObjC 1.1b1 released

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

On 23-feb-04, at 22:23, Pierce T.Wetter III wrote:
>
> became:
>
> PyObject *
> pythonify_c_value (const char *type, void *datum)
> .
> . code omittted
> .
>
> 	case _C_ID:
> 	{
> 		id obj = *(id *) datum;
> 		obj=[obj self];   <----- added call
>
> 		if (obj == nil) {
> 			retobject = Py_None;
> 			Py_INCREF (retobject);
> 		} else {
> 			retobject = [obj  __pyobjc_PythonObject__];
> 		}
> 		break;
> 	}
>
> So its just that one line in that one place.
>
>  Pierce
>

I've just checked this in, including a comment-block that explains why 
the line is there. As this was an 'obvious correct' I didn't run the 
testsuite or even compile the code (famous last words)

Ronald

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

Re: [Pyobjc-dev] PyObjC 1.1b1 released

[Pierce T. W. I. <pi...@tw...>]

On Feb 23, 2004, at 2:08 PM, Ronald Oussoren wrote:

>
> On 23-feb-04, at 20:32, Pierce T. Wetter III wrote:
>
>>
>> On Feb 21, 2004, at 1:03 PM, Ronald Oussoren wrote:
>>
>>> I've just pushed release 1.1b1 to the website.
>>
>>   What could I do to convince you to add the
>>
>>  [obj self]
>>
>>   call to the release? Its the only change I have left to make pyobjc 
>> work well with EOF 4.5, and while its a no-op for non-EOF objects, 
>> its necessary to trigger faults before converting to a pyobj. Its 
>> really annoying to have to distribute a custom version to our 
>> developers.
>
> In august 2003, Pierce wrote:
>
>>  I found one spot:
>>
>> Changing
>>
>> #define   PyObjCObject_GetObject(object) 
>> (((PyObjCObject*)(object))->objc_object)
>>
>> to
>>
>> #define   PyObjCObject_GetObject(object) 
>> ([((PyObjCObject*)(object))->objc_object self])
>>
>> in pyobjc.h seems to do it.
>
> Are you still using this patch?
>
> If so, could you try if adding 'objc_object = [objc_object self]' just 
> below the code below (in Modules/objc/objc-object.m, line 712, in 
> function PyObjCObject_New) also works?
>
>         res = find_existing_proxy(objc_object);
>         if (res) return res;
>
> If I recall the issues correctly this should convert any "ghost" 
> objects to real objects before passing them to python. This reduces 
> the changes of confusing the bridge w.r.t. the patch above.
>
> A simular change might be needed in PyObjCObject_NewUnitialized, that 
> function is only called for the result of +alloc and probably doesn't 
> need changing.
>
> I'll add this to the bridge if this solves your problems with EOF (and 
> doesn't introduce new problems).


  The only change I have from HEAD right now is in objc_support.m, where:

PyObject *
pythonify_c_value (const char *type, void *datum)
.
. code omittted
.
	case _C_ID:
	{
		id obj = *(id *) datum;

		if (obj == nil) {
			retobject = Py_None;
			Py_INCREF (retobject);
		} else {
			retobject = [obj  __pyobjc_PythonObject__];
		}
		break;
	}


became:

PyObject *
pythonify_c_value (const char *type, void *datum)
.
. code omittted
.

	case _C_ID:
	{
		id obj = *(id *) datum;
		obj=[obj self];   <----- added call

		if (obj == nil) {
			retobject = Py_None;
			Py_INCREF (retobject);
		} else {
			retobject = [obj  __pyobjc_PythonObject__];
		}
		break;
	}

So its just that one line in that one place.

  Pierce

Re: [Pyobjc-dev] PyObjC 1.1b1 released

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

On 23-feb-04, at 20:32, Pierce T. Wetter III wrote:

>
> On Feb 21, 2004, at 1:03 PM, Ronald Oussoren wrote:
>
>> I've just pushed release 1.1b1 to the website.
>
>   What could I do to convince you to add the
>
>  [obj self]
>
>   call to the release? Its the only change I have left to make pyobjc 
> work well with EOF 4.5, and while its a no-op for non-EOF objects, its 
> necessary to trigger faults before converting to a pyobj. Its really 
> annoying to have to distribute a custom version to our developers.

In august 2003, Pierce wrote:

>  I found one spot:
>
> Changing
>
> #define   PyObjCObject_GetObject(object) 
> (((PyObjCObject*)(object))->objc_object)
>
> to
>
> #define   PyObjCObject_GetObject(object) 
> ([((PyObjCObject*)(object))->objc_object self])
>
> in pyobjc.h seems to do it.

Are you still using this patch?

If so, could you try if adding 'objc_object = [objc_object self]' just 
below the code below (in Modules/objc/objc-object.m, line 712, in 
function PyObjCObject_New) also works?

         res = find_existing_proxy(objc_object);
         if (res) return res;

If I recall the issues correctly this should convert any "ghost" 
objects to real objects before passing them to python. This reduces the 
changes of confusing the bridge w.r.t. the patch above.

A simular change might be needed in PyObjCObject_NewUnitialized, that 
function is only called for the result of +alloc and probably doesn't 
need changing.

I'll add this to the bridge if this solves your problems with EOF (and 
doesn't introduce new problems).

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

Re: [Pyobjc-dev] PyObjC 1.1b1 released

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

The PackageManager databases should work again.

They referred to files on http://pyobjc.sf.net/, that doesn't work 
because the SF webservers redirect those URLs to 
http://pyobjc.sourceforge.net/ and PackMan doesn't like the redirect.

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

[Pyobjc-dev] Re: Odd testcase

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

On Feb 21, 2004, at 12:01 PM, Ronald Oussoren wrote:
>         a = objc.runtime.NSMutableArray.array()
>         a.addObject_(o)
>         b = objc.runtime.NSMutableArray.arrayWithObject_("m")
>         self.assertEquals(a.valueForKey_("keyM"), b)
>
>         self.assertRaises(KeyError, getKey, o, "nokey")
>
> I don't understand the last part of the testcase, why does 
> "self.assertEquals(a.valueForKey_("keyM"), b)" succeed on OS X 10.3. 
> It fails on OS X 10.2 and GNUstep, and that is what I would expect.

10.2 and GNUstep are broken, then. :-)  Seriously, I *believe* this 
should work as written on Jaguar.

         a = objc.runtime.NSMutableArray.array()
         a.addObject_(o)

The assertEquals() is checking to see if valueForKey() is returning an 
array of values when invoked upon an array of objects.   b is just an 
array of the expected values.  That is only one item is because whoever 
wrote the test [me] was lazy.

b.bum

[Pyobjc-dev] MacUpdate Dev: PyObjC updated

[<mac...@ma...>]

the PyObjC team,

PyObjC 1.1a0 has just been updated to version 1.1b1 on MacUpdate. Check it out at:

http://www.macupdate.com/info.php/id/11709

Please keep MacUpdate informed of any new Mac version releases of your products, so we can promote them for you. You can update your listing by sending us an email or going to:

http://www.macupdate.com/email/submission.php

-Joel Mueller
www.macupdate.com

[You're being notified of this update because you're listed as the developer of PyObjC. Please email us if you are not the developer: mac...@ma...].

Re: [Pyobjc-dev] PyObjC 1.1b1 released

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

On Feb 21, 2004, at 12:03 PM, Ronald Oussoren wrote:
> Bill: I renamed the function to 'accessor' (lower case), 'Accessor' 
> still works but should give a warning.

Since I'm [likely] the only one yet using this in a body of code that 
is experimental and tracking the pyobjc repos, I'd say kill the wrong 
spelling.

[Pyobjc-dev] PyObjC 1.1b1 released

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

I've just pushed release 1.1b1 to the website.

This should fix the issues found in the 1.1a0 release, adds python file 
templates for Xcode and includes the 'accessor' function that was 
discussed a couple of days ago.

Bill: I renamed the function to 'accessor' (lower case), 'Accessor' 
still works but should give a warning.

BTW. Is anyone using PyObjC with /usr/bin/python on Jaguar? I noticed 
yesterday that the CVS version didn't work anymore with python2.2, it 
is mostly fixed now (runPyObjCTests still crashes, but runalltests no 
longer gives errors)

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

[Pyobjc-dev] Odd testcase

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

In Lib/PyObjCTools/test/test_keyvalue.py:


     def testValueForKey(self):
         o = KeyValueClass7.alloc().init()
         o.addMultiple()

         self.assertEquals(getKey(o, "key1"), 1)
         self.assertEquals(getKey(o, "key2"), 2)
         self.assertEquals(getKey(o, "key3"), 3)
         self.assertEquals(getKey(o, "key4"), "4")
         self.assertEquals(getKey(o, "multiple"), o.multiple)

         self.assertEquals(o.valueForKey_("keyM"), "m")

         a = objc.runtime.NSMutableArray.array()
         a.addObject_(o)
         b = objc.runtime.NSMutableArray.arrayWithObject_("m")
         self.assertEquals(a.valueForKey_("keyM"), b)

         self.assertRaises(KeyError, getKey, o, "nokey")

I don't understand the last part of the testcase, why does 
"self.assertEquals(a.valueForKey_("keyM"), b)" succeed on OS X 10.3. It 
fails on OS X 10.2 and GNUstep, and that is what I would expect.

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

Re: [Pyobjc-dev] Question about Python sockets and NSFileDescriptors

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

On Feb 19, 2004, at 8:33 PM, Bob Ippolito wrote:

>
> On Feb 19, 2004, at 8:04 PM, Jim Clause wrote:
>
>> Hello,
>> 	I've narrowed my problem down a bit more.  I'm wrapping a python  
>> socket in an NSFileDescriptor and then registering to receive  
>> ConnectionAccepted notifications.  When I run my code listed below I  
>> just get an infinite number of notifications.  Can anyone see any  
>> errors in my code or explain why I might be getting some many  
>> connection notices?
>
> Take a look at the notification's userInfo(), those are not connection  
> notifications, they are EBADF errors..  Why they keep coming is beyond  
> me, but that's what's happening.

Ok on further inspection here's what's happening:

- You are creating a Python socket.  When this python socket gets  
garbage collected, it automatically closes (hence the initial  
ECONNABORTED error).  You need to make sure this Python socket does not  
get garbage collected by keeping a reference to it somewhere.
- You are telling the NSFileHandle to listen to a connection over and  
over again.  You should only do that once (hence the continuing EBADF  
errors).

Here is a working example, slightly modified to run nibless and it has  
a waker so ^C can work:

import socket
import signal

from Foundation import *
from AppKit import *
from PyObjCTools import AppHelper

class TestServer(NSObject):
     def applicationDidFinishLaunching_(self, aNotification):
         sock = self._sock = socket.socket(socket.AF_INET,  
socket.SOCK_STREAM)
         sock.bind((socket.gethostname(), 0))
         sock.listen(5)
         print 'Listening on:', sock.getsockname()

         # Wrap the socket in an NSFileHandle using fileno() to get the
         # file descriptor for the socket object
         listeningSocket =  
NSFileHandle.alloc().initWithFileDescriptor_(sock.fileno())

         # Register that we want to be informed of connection  
notifications
          
NSNotificationCenter.defaultCenter().addObserver_selector_name_object_(s 
elf, "handleConnectionNotification:",  
NSFileHandleConnectionAcceptedNotification, listeningSocket)
         listeningSocket.acceptConnectionInBackgroundAndNotify()

     def handleConnectionNotification_(self, aNotification):
         print "Got Connection", aNotification.userInfo()

class Waker(NSObject):
     def init(self):
         self = super(Waker, self).init()
         self._shouldQuit = False
         self._timer =  
NSTimer.scheduledTimerWithTimeInterval_target_selector_userInfo_repeats_ 
(0.5, self, self.wakeUp_, None, True)
         signal.signal(signal.SIGINT, self.setQuit)

     def wakeUp_(self, userInfo):
         if self._shouldQuit:
             NSApplication.sharedApplication().terminate_(None)
             self._shouldQuit = False

     def setQuit(self, aSignal, aStackFrame):
         self._shouldQuit = True

if __name__ == "__main__":
     server = TestServer.alloc().init()
     app = NSApplication.sharedApplication()
     app.setDelegate_(server)
     # make ^C kill the process in a reasonable amount of time
     waker = Waker.alloc().init()
     # start
     app.run()

Re: [Pyobjc-dev] Question about Python sockets and NSFileDescriptors

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

On Feb 19, 2004, at 8:04 PM, Jim Clause wrote:

> Hello,
> 	I've narrowed my problem down a bit more.  I'm wrapping a python 
> socket in an NSFileDescriptor and then registering to receive 
> ConnectionAccepted notifications.  When I run my code listed below I 
> just get an infinite number of notifications.  Can anyone see any 
> errors in my code or explain why I might be getting some many 
> connection notices?

Take a look at the notification's userInfo(), those are not connection 
notifications, they are EBADF errors..  Why they keep coming is beyond 
me, but that's what's happening.

-bob

[Pyobjc-dev] Question about Python sockets and NSFileDescriptors

[Jim C. <cl...@cs...>]

Hello,
	I've narrowed my problem down a bit more.  I'm wrapping a python  
socket in an NSFileDescriptor and then registering to receive  
ConnectionAccepted notifications.  When I run my code listed below I  
just get an infinite number of notifications.  Can anyone see any  
errors in my code or explain why I might be getting some many  
connection notices?

Thanks again,
	Jim

import socket

from Foundation import *
from AppKit import *
from PyObjCTools import NibClassBuilder, AppHelper

NibClassBuilder.extractClasses("MainMenu")

class TestServer(NibClassBuilder.AutoBaseClass):
     def awakeFromNib(self):
         sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
         sock.bind((socket.gethostname(), 0))
         sock.listen(1)

         # Wrap the socket in an NSFileHandle using fileno() to get the
         # file descriptor for the socket object
         listeningSocket =  
NSFileHandle.alloc().initWithFileDescriptor_(sock.fileno())

         # Register that we want to be informed of connection  
notifications
          
NSNotificationCenter.defaultCenter().addObserver_selector_name_object_(s 
elf, "handleConnectionNotification:",  
NSFileHandleConnectionAcceptedNotification, listeningSocket)
         listeningSocket.acceptConnectionInBackgroundAndNotify()

     def handleConnectionNotification_(self, aNotification):
         print "Got Connection"
         aNotification.object().acceptConnectionInBackgroundAndNotify()

if __name__ == "__main__":
     AppHelper.runEventLoop()

[Pyobjc-dev] Re: [Python-Dev] Plea for function/method syntax sugar (PEP 318, with a different syntax)

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

On Feb 19, 2004, at 1:36 PM, Thomas Heller wrote:

> Bob Ippolito <bo...@re...> writes:
>
>> Here's a quick overview:
>>
>> def foo(args) [sugary, expressions, list]:
>> 	pass
>>
>> This is equivalent to:
>>
>> def foo(args):
>> 	pass
>> foo = list(expressions(sugary(foo)))

[examples showing how much nicer it makes type annotation in ctypes and 
PyObjC]

> BTW (I have this patch not yet applied), is it possible to use more 
> than
> one line, in this way?
>
> def function(arg1, arg2, arg3, arg4, arg5, arg6)
>         [dothis, dothat, doanother]:
>
> All in all, I'm +1 on the patch.

No, that is not valid syntax with the current patch.. you would need:
def function(arg1, arg2, arg3, arg4, arg5, arg6
	) [dothis, dothat, doanother]:

or

def function(arg1, arg2, arg3, arg4, arg5, arg6) [
	dothis, dothat, doanother]:

(or some variation, that makes it obvious to Python that the def is not 
complete).

-bob

[Pyobjc-dev] Re: [Python-Dev] Plea for function/method syntax sugar (PEP 318, with a different syntax)

[Thomas H. <th...@py...>]

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

> Here's a quick overview:
>
> def foo(args) [sugary, expressions, list]:
> 	pass
>
> This is equivalent to:
>
> def foo(args):
> 	pass
> foo = list(expressions(sugary(foo)))
>
> This evaluation order is Guido approved, though at least one person
> wanted it to be the other way around
>
> One would use this in scenarios such as:
>
> class FooClass(object):
>      def className(klass) [classmethod]:
>          return klass.__name__
>
> or, even more importantly (to me anyway):
>
> # we would change PyObjC to make this a built-in feature.. but, for
> # completeness:
> import objc
> def signature(sig):
>      def _signature(fn):
>          return objc.selector(fn, signature=sig)
>      return _signature
>
> class FooClass(NSObject):
>      def returnsAnInteger(self) [signature('i@:')]:
>          return 1
>      def returnsVoidTakesAnInteger_(self, anInteger) [signature('v@:i')]:
>          pass

I was thinking of a similar usecase for ctypes, defining C callback
functions.  In ctypes, you would be able to write

"""
WndProc = WINFUNCTYPE(c_int, HWND, MSG, WPARAM, LPARAM)

def my_wndproc(hwnd, msg, wParam, lParam) [WndProc]:
    ....
"""

instead of this

"""
WndProc = WINFUNCTYPE(c_int, HWND, MSG, WPARAM, LPARAM)

def my_wndproc(hwnd, msg, wParam, lParam):
    ....

my_wndproc = WndProc(my_wndproc)
"""

BTW (I have this patch not yet applied), is it possible to use more than
one line, in this way?

def function(arg1, arg2, arg3, arg4, arg5, arg6)
        [dothis, dothat, doanother]:

All in all, I'm +1 on the patch.

Thomas

[Pyobjc-dev] Plea for function/method syntax sugar (PEP 318, with a different syntax)

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

Some time ago, mwh developed a patch that adds some syntactical sugar  
to def, which is equivalent to PEP 318 though it has a different and  
more flexible syntax...
previous threads can be easily found here:   
http://www.google.com/search?q=+site:mail.python.org+%22meth-syntax- 
sugar%22
the latest version of mwh's patch is here:  
http://starship.python.net/crew/mwh/hacks/meth-syntax-sugar-3.diff

Here's a quick overview:

def foo(args) [sugary, expressions, list]:
	pass

This is equivalent to:

def foo(args):
	pass
foo = list(expressions(sugary(foo)))

This evaluation order is Guido approved, though at least one person  
wanted it to be the other way around

One would use this in scenarios such as:

class FooClass(object):
     def className(klass) [classmethod]:
         return klass.__name__

or, even more importantly (to me anyway):

# we would change PyObjC to make this a built-in feature.. but, for  
completeness:
import objc
def signature(sig):
     def _signature(fn):
         return objc.selector(fn, signature=sig)
     return _signature

class FooClass(NSObject):
     def returnsAnInteger(self) [signature('i@:')]:
         return 1
     def returnsVoidTakesAnInteger_(self, anInteger) [signature('v@:i')]:
         pass

With current syntax, PyObjC is extremely cumbersome:

class FooClass(NSObject):
     def returnsAnInteger(self):
         return 1
     returnsAnInteger = objc.selector(returnsAnInteger, signature='i@:')

     def returnsVoidTakesAnInteger_(self, anInteger):
         pass
     returnsVoidTakesAnInteger_ =  
objc.selector(returnsVoidTakesAnInteger_, signature='v@:i')
     # these are actually short examples, compare to something like:
     # textView_completions_forPartialWordRange_indexOfSelectedItem_

Why we need this:
	Without it, it's hard use PyObjC correctly.  ObjC selector  
nomenclature is extremely verbose, and your fingers hurt after a while  
having to type each function name three times.  The function __name__  
is important, because the objc.selector type has to convert it to a  
selector:that:uses:colons:, or else the colon:using:name: would have to  
be specified manually.
	It makes classmethod/staticmethod/etc more palatable.

What the patch doesn't do:
	lambda is not allowed in the "sugary expressions list"
	there's no *expansion and it won't take an actual list so if you want  
a prebaked list of transformations then you'll have to roll a callable  
that does it such as:

def prebake(*expressions):
     def _prebake(fn):
         for transformation in expressions:
             fn = transformation(fn)
         return fn
     return fn

This syntactical sugar for def is so unbelievably important to PyObjC  
(and likely other projects) that I am willing to distribute my own  
modified version of Python if it doesn't make 2.4 (though I would  
probably use Stackless as the base, but that's another plea for another  
day).

The patch looks like it still applies to CVS HEAD, but there is a  
little fuzz on hunk 2.  I have not tested it yet, but I have tested it  
against CVS HEAD of the 2.3.3 based Stackless.

I'm willing to help however I can in order to get this into Python 2.4.

-bob

[Pyobjc-dev] Picture Share Example

[Jim C. <cl...@cs...>]

Hello,
	I have been attempting to rewrite the Picture Browser examples from  
Apple (  
http://developer.apple.com/samplecode/Sample_Code/Networking/ 
PictureSharing.htm and  
http://developer.apple.com/samplecode/Sample_Code/Networking/ 
PictureSharingBrowser.htm)  Most of the feature are working.  The  
Picture Server publishes it self via rendezvous and the Browser is able  
to find it.  However, when I try and connect using a python socket  
errors start to crop up.  Does anyone have experience using rendezvous  
services through python instead of just publishing and locating them?   
I can provide my code if someone is willing to take a look at it.   
Thanks for your help.

~Jim

  
  

Re: [Pyobjc-dev] ReSTedit and buildapp.py

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

On Feb 17, 2004, at 11:30 AM, b.bum wrote:

> 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).

I can pretty easily give bundlebuilder2 the same kind of bootstrap 
executable functionality.. though I would prefer that the PyObjC 'pth' 
not be hardcoded into the loader.  There has to be a better way 
(parsing pth files legitimately, including a site.py, etc.).

-bob