pyobjc-dev

Re: [Pyobjc-dev] Objective-P?

[Ronald O. <ron...@ma...>]

On 12 Nov, 2009, at 0:01, Anders Hovmöller wrote:

> Ever since I saw Objective-J (http://cappuccino.org/learn/tutorials/objective-j-tutorial.php) it has bothered me a bit how you have to mangle the function calls in pyobjc. The calling syntax in Objective-C is a big part of what makes the API so nice to use and easy to maintain, and it seems pretty trivial to get something similar running for python.
> 
> I implemented a little proof of concept for "Objective-P", which is basically python with support for Objective-C-like method calls. Because I'm not really good with parsers I used < and > instead of [ and ] to not mess with list comprehensions which I have in my code a lot (I know, it breaks other stuff but those cases are more rare and it's just a quick and dirty hack so far). Some example code:
> 
> class Foo:
> 	def <self foo:foo bar:bar>:
> 	    print 'success!'
> 
> foo = Foo()
> <foo foo:1 bar:2>
> 
> This code is converted at import time from a ".opy" file to a ".py" file which is in turn loaded by the standard python loader. 
> 
> Find attached the source for the custom importer.

While this is a nice trick I'd be much more interested in a syntax-change that at least has a chance of getting accepted into the Python core.   Your syntax for calling a method is ambiguous, at least for the parser using in CPython and possibly in general:

    10 <foo + bar> baz

Python's parser needs to know if the '<' token is the start of a method call or a comparison operator (and so do humans, it's far from clear what's going on here when I look at the code).

I've been thinking about syntax enhancements during the summer, the best I could think of was the introduction of a new operator:

    class MyObject (NSObject):
         def $[setValue: value]:
		pass

   $[myObject setValue:42]

In this code '$[' would be a new operator, which should be unambigous w.r.t. existing code. Better yet, one could use a simular trick for anonymous functions:

    foo = $(a, b):
	print a
	print b
	return 4

I've haven't tried to actually implement my ideas yet and have no idea whether they could be implemented in CPython. I am pretty sure though that my ideas have about 0% of getting accepted into CPython (even without the proposed language moratorium).

What really annoys me though is that I haven't been able to find a way to get clear integration of Cocoa and Python without changing the Python syntax, and without using manual translation of method names (as was used by the Java-Cocoa bridge).

Ronald

Re: [Pyobjc-dev] Objective-P?

[Orestis M. <or...@or...>]

On 12 Nov 2009, at 11:59, Ronald Oussoren wrote:

> What really annoys me though is that I haven't been able to find a way to get clear integration of Cocoa and Python without changing the Python syntax, and without using manual translation of method names (as was used by the Java-Cocoa bridge).

I've given some thought to that in the past, and of course I know it comes up on the list every couple of months.

I think an important step is maintaing the order of the **kwargs dictionary:

def set(self, **kwargs):
     # construct method name from kwargs
     # extract positional args from kwargs
     objc.dispatch(methodname, args)


foo.set(Value=1, forKey='a')
foo.set(forKey='a', Value=1)

If those calls could be differentiated in the body of 'set', would it not help? Some cases could be ambiguous, but in that case a warning could be emitted and the current convention could be used instead.

Orestis

Re: [Pyobjc-dev] Objective-P?

[Anders H. <bo...@ki...>]

On Thu, Nov 12, 2009 at 11:18 AM, Orestis Markou <or...@or...> wrote:

>
> On 12 Nov 2009, at 11:59, Ronald Oussoren wrote:
>
> > What really annoys me though is that I haven't been able to find a way to
> get clear integration of Cocoa and Python without changing the Python
> syntax, and without using manual translation of method names (as was used by
> the Java-Cocoa bridge).
>
> I've given some thought to that in the past, and of course I know it comes
> up on the list every couple of months.
>
> I think an important step is maintaing the order of the **kwargs
> dictionary:
>
> def set(self, **kwargs):
>     # construct method name from kwargs
>     # extract positional args from kwargs
>     objc.dispatch(methodname, args)
>
>
> foo.set(Value=1, forKey='a')
> foo.set(forKey='a', Value=1)
>
> If those calls could be differentiated in the body of 'set', would it not
> help? Some cases could be ambiguous, but in that case a warning could be
> emitted and the current convention could be used instead.
>

Mapping python-style named parameters to objective-c message sending would
probably incur quite a bit of overhead, and the end result, in my mind, ends
up being not so readable either.

Best regards,
Anders