pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Displaying a numpy array

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

On 30 Mar, 2009, at 21:28, Thomas Robitaille wrote:

> Hello,
>
> I have been using Python for a few months, and have now learned how to
> use PyObjC in a basic way to design a Cocoa interface (.nib) for a
> python script.
>
> I am interested in displaying a numpy array or PIL image using the
> interface. Is the way to do this to use an OpenGL view? or an Image
> View? Are there examples of such scripts anywhere? I looked at the
> OpenGLDemo.py example, but could not understand how this could be used
> to display the contents of an array.
>
> Any advice would be welcome,

There will be some code to convert to/from PIL images in a future  
release of PyObjC,
but I haven't written that code yet and wouldn't mind if someone send  
me a patch
for that ;-).

A kludgy way to display a PIL image is to convert the image to a  
string and then
create an NSImage from that.

I have no personal experience with numpy or OpenGL. AFAIK the OpenGL  
stuff
works almost completely through PyOpenGL and the Cocoa bindings in Cocoa
are just a way to represent a regular OpenGL canvas as a Cocoa object.

That btw. would be another nice contribution to PyObjC: write an  
OpenGL example
that does something more interesting than displaying a solid color. I  
guess a rotating
teapot would be appropriate for such an example.

Ronald
>
> Thanks,
>
> Thomas
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] PyObjC 2.0 & Xcode 3.0

[Mike M. <mm...@wy...>]

I am attempting to write a small program using Python/PyObjC 2.0 and  
Xcode 3.  I have Python experience, but no Objective C experience.  I  
have developed Cocoa applications in the past using AppleScript, but I  
am finding there is a huge learning curve to using Python and Cocoa.   
I have found one or two good tutorials that that have gotten me pretty  
far.  However, I am now at the point where I am trying to use Apple's  
built in documentation of the ObjC/Cocoa classes and having trouble  
implementing them in my Python code.  I have searched Google high and  
low for material relating to PyObjC 2.0 and Xcode 3.0, but have not  
found much.  Can anyone recommend tutorials, websites, even books,  
that might help me get a handle on Cocoa development with Python in  
Xcode?
Thanks,
Mike

Re: [Pyobjc-dev] Pure Python Cocoa GUI application?

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

On 31 Mar 2009, at 12:12, Greg Ewing wrote:

> Orestis Markou wrote:
>
>> I'm a bit confused about Dock icons and applications - some times  
>> I  get the rocket icon, some times I don't
>
> Is it python vs. pythonw? I find I need to use pythonw
> in order to get a dock icon.

pythonw does display the dock icon (and virtualenv doesn't copy that,  
I'll raise an issue). I'm more interested in having a menubar so I can  
press command-Q to exit. For some reason ctrl-c doesn't work, even  
when using the relevant AppHelper method  
(AppHelper.installMachInterrupt()).

Orestis
> -- 
> Greg

Re: [Pyobjc-dev] Pure Python Cocoa GUI application?

[Greg E. <gre...@ca...>]

Orestis Markou wrote:

> I'm a bit confused about Dock icons and applications - some times I  get 
> the rocket icon, some times I don't

Is it python vs. pythonw? I find I need to use pythonw
in order to get a dock icon.

-- 
Greg

Re: [Pyobjc-dev] Pure Python Cocoa GUI application?

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

Hi,

I'm a bit confused about Dock icons and applications - some times I  
get the rocket icon, which I can use to force quit the app, some times  
I don't get anything and I have to kill the process by getting the PID.

How can I get the standard application behaviour with no nibs?

Orestis
--
or...@or...
http://orestis.gr/




On 17 Mar 2009, at 10:50, Greg Ewing wrote:

> Ronald Oussoren wrote:
>>
>> Is there any way from pure python (no main.m, no
>>> nib) to get something showing on the screen? I know that without a  
>>> nib
>>> I won't get a proper dock icon or a menu bar,
>
> It's possible to get a proper menu bar without a nib
> using a trick or two. Let me know if you want details.
>
> -- 
> Greg
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM)  
> are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly  
> and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based  
> development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Pure Python Cocoa GUI application?

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

Interesting - I'm using virtualenv, and when using the python  
executable created by virtualenv I don't get the dock icon, whereas if  
I use the system python executable I do. I wonder if there's a way to  
overcome this...
--
or...@or...
http://orestis.gr/




On 31 Mar 2009, at 10:39, Orestis Markou wrote:

> Hi,
>
> I'm a bit confused about Dock icons and applications - some times I  
> get the rocket icon, which I can use to force quit the app, some  
> times I don't get anything and I have to kill the process by getting  
> the PID.
>
> How can I get the standard application behaviour with no nibs?
>
> Orestis
> --
> or...@or...
> http://orestis.gr/
>
>
>
>
> On 17 Mar 2009, at 10:50, Greg Ewing wrote:
>
>> Ronald Oussoren wrote:
>>>
>>> Is there any way from pure python (no main.m, no
>>>> nib) to get something showing on the screen? I know that without  
>>>> a nib
>>>> I won't get a proper dock icon or a menu bar,
>>
>> It's possible to get a proper menu bar without a nib
>> using a trick or two. Let me know if you want details.
>>
>> -- 
>> Greg
>>
>> ------------------------------------------------------------------------------
>> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM)  
>> are
>> powering Web 2.0 with engaging, cross-platform capabilities.  
>> Quickly and
>> easily build your RIAs with Flex Builder, the Eclipse(TM)based  
>> development
>> software that enables intelligent coding and step-through debugging.
>> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

[Pyobjc-dev] Displaying a numpy array

[Thomas R. <tho...@gm...>]

Hello,

I have been using Python for a few months, and have now learned how to  
use PyObjC in a basic way to design a Cocoa interface (.nib) for a  
python script.

I am interested in displaying a numpy array or PIL image using the  
interface. Is the way to do this to use an OpenGL view? or an Image  
View? Are there examples of such scripts anywhere? I looked at the  
OpenGLDemo.py example, but could not understand how this could be used  
to display the contents of an array.

Any advice would be welcome,

Thanks,

Thomas

Re: [Pyobjc-dev] Need design input for method names

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

On 30 Mar, 2009, at 18:17, Orestis Markou wrote:

>
>> I'm not totally against a HotCocoa-style add-on for PyObjC and am
>> willing to ship is as part of PyObjC itself.  This would need
>> commitment from a number of people to get going though, and I'd very
>> much prefer if the Pythonic addons were as complete as possible
>> before merging them into the core framework wrappers to avoid
>> getting stuck with partial addons that noone is willing to maintain
>> or enhance.  BTW. "as complete as possible" means covers all API's
>> that are part of
>> Cocoa and other useful frameworks in SnowLeopard.
>
> I was more pointing out that a separate project will be better suited,
> and of course it doesn't have to be as complete as possible in order
> to be useful (as the post by Tal Leming illustrates).

It needs to be fairly complete to be part of of the PyObjC project, I  
don't feel like answering questions about missing functionality. A  
partial mapping to a Pythonic API is IMHO way more confusing than our  
current state.

Ronald

Re: [Pyobjc-dev] Need design input for method names

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

> I'm not totally against a HotCocoa-style add-on for PyObjC and am  
> willing to ship is as part of PyObjC itself.  This would need  
> commitment from a number of people to get going though, and I'd very  
> much prefer if the Pythonic addons were as complete as possible  
> before merging them into the core framework wrappers to avoid  
> getting stuck with partial addons that noone is willing to maintain  
> or enhance.  BTW. "as complete as possible" means covers all API's  
> that are part of
> Cocoa and other useful frameworks in SnowLeopard.

I was more pointing out that a separate project will be better suited,  
and of course it doesn't have to be as complete as possible in order  
to be useful (as the post by Tal Leming illustrates).

> What's needed most is a PEP-style document that describes what the  
> goals of this work would be, including descriptions of the way to  
> map Cocoa API's onto Python API's in a consistent manner.  This  
> document will also have to describe how to deal with subclassing.  
> Don't worry about getting it 100% correct on the first try.

That is true - although again my idea was to try to provide a Pythonic  
API for the simple cases that occur when developing applications and  
fall back to plain PyObjC for anything more complicated. That is, take  
the HotCocoa approach of reusing the NS* stuff rather than wrapping  
them.

I am going to be involved in a sizeable Core Animation project for the  
next couple of months and I might be able to extract something out of  
it, at least to initiate discussion.

Orestis

Re: [Pyobjc-dev] Need design input for method names

[Tal L. <ta...@ty...>]

> One approach taken from the Ruby guys is HotCocoa (http://www.macruby.org/trac/wiki/HotCocoa 
> ) that aims to provide simplified wrappers for common Cocoa use-cases.

For what it is worth, Just van Rossum and I wrote a less verbose  
wrapper for Cocoa/PyObjC a while back. I have used it for a number of  
shipping applications. You can get the code here:

	http://code.typesupply.com/wiki/Vanilla

I'm not all that familiar with HotCocoa, but maybe this is similar.

Tal

[Pyobjc-dev] CFNetworkCopyProxiesForAutoConfigurationScript not available?

[Mani G. <ma...@tu...>]

Hi all,

CFNetworkCopyProxiesForAutoConfigurationScript is a new API available
in 10.5: http://developer.apple.com/releasenotes/Networking/RN-CFNetwork/index.html#//apple_ref/doc/uid/TP40000990-DontLinkElementID_3

However, I don't think it is supported by PyObjC (doesn't show up in
the namespace after importing Foundation or CoreFoundation).

Any way I can work around this?

I have an app built using PyObjC, using Python's urllib2 for HTTP
access. urllib2 handles "manual" proxies as configured in System
Preferences, but not PAC file proxy configurations. I would like to
support PAC files in my application and
CFNetworkCopyProxiesForAutoConfigurationScript seemed like the answer,
but now I'm struggling.

Any ideas greatly appreciated.

Cheers,
Mani

Re: [Pyobjc-dev] Need design input for method names

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

On 29 Mar, 2009, at 18:42, Orestis Markou wrote:

> It occurs to me (having started to do Obj-C development this past  
> month full-time) that a major source of annoyance is not the  
> verboseness of the bridge, but the lack of a Pythonic API to Cocoa,  
> which can be very verbose itself.
>
> One approach taken from the Ruby guys is HotCocoa (http://www.macruby.org/trac/wiki/HotCocoa 
> ) that aims to provide simplified wrappers for common Cocoa use- 
> cases. For example, rather than doing:
>
> win = NSWindow.alloc.initWithContentRect [10,20,300,300], :styleMask  
> => (
> NSTitledWindowMask | NSClosableWindowMask |  
> NSMiniaturizableWindowMask | NSResizableWindowMask)
> you do:
> win = window :frame => [10,20,300,300]
> However, I know that the PyObjC maintainers don't want to do this  
> since it has to be manually maintained. Perhaps then this can be  
> another project? Maybe the fact that as bbum said there hasn't been  
> an acceptable solution for 15 years now is in an indicator of wrong  
> scope. Even if an acceptable method name convention can be reached,  
> the fact that to create a usual NSWindow you need to pass in 4 flags  
> won't go away.

The reason I don't like HotCocoa's approach  is that someone will have  
to write and maintain that layer, including good documentation.  The  
past has learned that "someone" tends to be me in the long run, which  
makes me very hesitant to work on this.

The advantage of the current approach is that we can point users to  
Apple's documentation because translating from ObjC to Python (and  
v.v. is trivial).

That said, I'm very slowly adding some shortcuts to PyObjC where that  
makes sense (such as a number of contextmanagers in the CoreGraphics  
bindings), and will add more in the future. One of the items on my  
todolist is to check if we can adopt Twisted-style deferred's and  
their generator-based pseudothreads to make dealing with sheets easier.

To summarize:

I'm not totally against a HotCocoa-style add-on for PyObjC and am  
willing to ship is as part of PyObjC itself.  This would need  
commitment from a number of people to get going though, and I'd very  
much prefer if the Pythonic addons were as complete as possible before  
merging them into the core framework wrappers to avoid getting stuck  
with partial addons that noone is willing to maintain or enhance.   
BTW. "as complete as possible" means covers all API's that are part of  
Cocoa and other useful frameworks in SnowLeopard.

What's needed most is a PEP-style document that describes what the  
goals of this work would be, including descriptions of the way to map  
Cocoa API's onto Python API's in a consistent manner.  This document  
will also have to describe how to deal with subclassing. Don't worry  
about getting it 100% correct on the first try.

Ronald
> Orestis
> --
> or...@or...
> http://orestis.gr/
>
>
>
>
> On 29 Mar 2009, at 19:21, Ronald Oussoren wrote:
>
>>
>> On 29 Mar, 2009, at 13:11, Bill Bumgarner wrote:
>>>>
>>>
>>> This again? :)
>>>
>>> Here is a good starting point for one of the more signal-oriented
>>> discussions on this subject (it has come up once every 6 to 24  
>>> months
>>> since PyObjC was created in '94):
>>
>> I know, but the current syntax really annoys me.
>>
>> Ronald 
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] Need design input for method names

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

It occurs to me (having started to do Obj-C development this past  
month full-time) that a major source of annoyance is not the  
verboseness of the bridge, but the lack of a Pythonic API to Cocoa,  
which can be very verbose itself.

One approach taken from the Ruby guys is HotCocoa (http://www.macruby.org/trac/wiki/HotCocoa 
) that aims to provide simplified wrappers for common Cocoa use-cases.  
For example, rather than doing:

win = NSWindow.alloc.initWithContentRect [10,20,300,300], :styleMask  
=> (
NSTitledWindowMask | NSClosableWindowMask | NSMiniaturizableWindowMask  
| NSResizableWindowMask)
you do:
win = window :frame => [10,20,300,300]
However, I know that the PyObjC maintainers don't want to do this  
since it has to be manually maintained. Perhaps then this can be  
another project? Maybe the fact that as bbum said there hasn't been an  
acceptable solution for 15 years now is in an indicator of wrong  
scope. Even if an acceptable method name convention can be reached,  
the fact that to create a usual NSWindow you need to pass in 4 flags  
won't go away.
Orestis
--
or...@or...
http://orestis.gr/




On 29 Mar 2009, at 19:21, Ronald Oussoren wrote:

>
> On 29 Mar, 2009, at 13:11, Bill Bumgarner wrote:
>>>
>>
>> This again? :)
>>
>> Here is a good starting point for one of the more signal-oriented
>> discussions on this subject (it has come up once every 6 to 24 months
>> since PyObjC was created in '94):
>
> I know, but the current syntax really annoys me.
>
> Ronald 
> ------------------------------------------------------------------------------
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Need design input for method names

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

On 29 Mar, 2009, at 13:11, Bill Bumgarner wrote:
>>
>
> This again? :)
>
> Here is a good starting point for one of the more signal-oriented
> discussions on this subject (it has come up once every 6 to 24 months
> since PyObjC was created in '94):

I know, but the current syntax really annoys me.

Ronald

Re: [Pyobjc-dev] Dot syntax style setters.

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

On 29 Mar, 2009, at 13:03, Bill Bumgarner wrote:

> On Mar 29, 2009, at 7:41 AM, Ronald Oussoren wrote:
>> The easy one is properties: I'd love to use "someObject.size = 5"  
>> instead of "someObject.setSize_(5)". This is fairly easy to  
>> implement, although defining custom read-accessors makes live  
>> slightly more interesting (you cannot have a property named "foo"  
>> and a method named "foo" in the same class in PyObjC).    The  
>> largest blob of work for this is generating the right metadata for  
>> PyObjC.
>
> The ObjC rule for the above is that someObject.size is exactly  
> equivalent to [someObject size] (get) or [someObject setSize: 5]  
> (set).
>
> If PyObjC can implement it with the same level of exactness, it  
> makes sense to do and would be a boon.


The annoying bit is that method names and attribute names are in the  
same namespace on Python, which makes it impossible to make both  
someObject.size valid as a property and someObject.size() valid as a  
getter.  It would be possible to use metaclass trickery to allow  
defining a 'size' getter method and still have the 'size' property, at  
the cost of breaking all existing code that uses the getter methods.

That's why I'd be reluctant to add this without also implementing some  
kind of fix for the overly long method names.

Any change in this field would IMHO also require a refactoring tool to  
automate the transition. That should at least be doable using the  
lib2to3 machinery that's in python 2.6; that name is misleading the  
code actually implements a Python refactoring engine that happens to  
be configured with Python 2 -> Python 3 refactorings.

Ronald
>
> b.bum

Re: [Pyobjc-dev] Need design input for method names

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

On Mar 29, 2009, at 11:11 AM, Bill Bumgarner wrote:
> On Mar 29, 2009, at 7:41 AM, Ronald Oussoren wrote:
>> The other change I'd like to make is to get rid of the extremely
>> long and ugly method names in Python that are caused by segmented
>> method names in Objective-C.
>> "someObject.loadResource_withType_inDirectory_error_(.........)" is
>> ugly and often results in code that is too wide for a reasonably
>> sized window.   This is were I need help, at the moment I don't know
>> how to get to a nicer API without changing the Python language
>> (which I don't want to do).
>
> This again? :)
>
> Here is a good starting point for one of the more signal-oriented
> discussions on this subject (it has come up once every 6 to 24 months
> since PyObjC was created in '94):
>
> 	http://mail.python.org/pipermail/pythonmac-sig/2002-October/006471.html
>
> Summary:  The current syntax is ugly, but all other technically viable
> proposals are either uglier *or* lack the dead-simple precision of the
> current syntax.
>
> The most viable I have found was hacking the interpreter to accept:
>
> 	someObject.loadResource:withType:inDirectory:error:(...)
>
> But that ain't gonna fly with Guido, I'd wager.

Just to be utterly clear, I didn't post the above because I wanted to  
stop the conversation.

I just want to short-circuit around the initial flurry of posts  
suggesting that which has been suggested before and shot down.

The hope is to get to the New Stuff more quickly.

b.bum

Re: [Pyobjc-dev] Need design input for method names

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

On Mar 29, 2009, at 7:41 AM, Ronald Oussoren wrote:
> The other change I'd like to make is to get rid of the extremely  
> long and ugly method names in Python that are caused by segmented  
> method names in Objective-C.  
> "someObject.loadResource_withType_inDirectory_error_(.........)" is  
> ugly and often results in code that is too wide for a reasonably  
> sized window.   This is were I need help, at the moment I don't know  
> how to get to a nicer API without changing the Python language  
> (which I don't want to do).

This again? :)

Here is a good starting point for one of the more signal-oriented  
discussions on this subject (it has come up once every 6 to 24 months  
since PyObjC was created in '94):

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

Summary:  The current syntax is ugly, but all other technically viable  
proposals are either uglier *or* lack the dead-simple precision of the  
current syntax.

The most viable I have found was hacking the interpreter to accept:

	someObject.loadResource:withType:inDirectory:error:(...)

But that ain't gonna fly with Guido, I'd wager.

b.bum

[Pyobjc-dev] Dot syntax style setters.

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

On Mar 29, 2009, at 7:41 AM, Ronald Oussoren wrote:
> The easy one is properties: I'd love to use "someObject.size = 5"  
> instead of "someObject.setSize_(5)". This is fairly easy to  
> implement, although defining custom read-accessors makes live  
> slightly more interesting (you cannot have a property named "foo"  
> and a method named "foo" in the same class in PyObjC).    The  
> largest blob of work for this is generating the right metadata for  
> PyObjC.

The ObjC rule for the above is that someObject.size is exactly  
equivalent to [someObject size] (get) or [someObject setSize: 5] (set).

If PyObjC can implement it with the same level of exactness, it makes  
sense to do and would be a boon.

b.bum

Re: [Pyobjc-dev] Underscores in methods/instance variables

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

Let me clarify something - is this only an issue when you need to call  
a method from Obj-C or is it affecting everything that inherits from  
NSObject?

Orestis

On 29 Mar 2009, at 15:27, Ronald Oussoren wrote:

> That's correct. Apple reserves names starting with underscores for  
> their own usage. I do sometimes use underscores in my own code, but  
> that code could get broken on future versions of OSX.
>
> BTW. PyObjC code and regular python code cannot follow exactly the  
> same coding conventions for other reasons as well, PEP8 style  
> nameing for methods ("do_something" instead of "doSomething") causes  
> problems with PyObjC's automatic deduction of the ObjC method name.
>
> Ronald
>
> On 28 Mar, 2009, at 18:32, Petr Mifek wrote:
>
>> Hi,
>>
>> I made some more digging into this matter and the only thing I  
>> found so
>> far is this one (sorry, a long one):
>>
>> http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/CodingGuidelines/Articles/NamingMethods.html#/ 
>> /apple_ref/doc/uid/20001282-1003829-BCIBDJCA
>>
>> and some good insights here:
>>
>> http://www.cocoadev.com/index.pl?CodingGuidelines
>>
>> So unless anybody knows and posts more profound answer, I suggest  
>> that
>> the paragraph in the PyObjC intro stating """...instance variables
>> prefixed with underscores are reserved by the Objective-C  
>> runtime..."""
>> was put there based on the Apple's recommendation of not using such
>> variables.
>>
>> Cheers,
>> Petr
>>
>> Orestis Markou wrote:
>>> Hello all,
>>>
>>> I want to clarify a bit the advice of the documentation to *not* use
>>> the Python conventions of not using leading underscores for  
>>> "private"
>>> instance attributes.
>>>
>>> Is it the danger of accidentally overwriting some other Obj-C
>>> attribute if there's a name clash? What about methods with leading
>>> underscores?
>>>
>>> I fully understand that in order a method to be accessible from  
>>> Obj-C
>>> code it has to follow the methodWithArg_andArg_(self, arg1, arg2)
>>> convention. In my case, these are "private" methods that I have no
>>> desire to expose to anyone.
>>>
>>> The class in question is just a delegate that implements a custom  
>>> init
>>> method and the delegate method. These are the only things that use  
>>> the
>>> obj-c convention. The rest of the code is using the Python  
>>> convention,
>>> with leading underscores in attributes and methosd, property
>>> decorators and so on.
>>>
>>> Testing indicates that things are working perfectly fine, I'm just
>>> worried that there may some stability issues that may not visible at
>>> this point. I've heard rumours of hard crashes that may have been
>>> related to this, so I'm a bit worried.
>>>
>>> Thanks,
>>> Orestis
>>> --
>>> or...@or...
>>> http://orestis.gr/
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Pyobjc-dev mailing list
>>> Pyo...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] Need design input for method names

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

I had some thoughts about this the other day, I'm glad you want to  
resolve this.

I was wondering if dynamic dispatch could handle this:

someObject.loadResource would be a 'proxy' selector that would  
dispatch to the correct selector depending on the keyword arguments  
present. So for example:

someObject.loadResource(1, error=None) would dispatch to:

loadResource:error:

while

someObject.loadResource(1, inDirectory=2, error=None) would dispatch to:

loadResource:inDirectory:error:

Choosing the correct selector would require gathering meta-data about  
the selectors and storing them in the generated class. The only case  
that this is brittle is the unlikely one that a selector has the same  
arguments in the different order (which would need a change to Python  
to use an ordered kwarg dict).

For defining methods, why not have a decorator (similar to  
objc.selector) that would look something like:

@objc.selector
def loadResource(resource, inDirectory, error):
     pass

The decorator has access to the arguments and the ordering so it could  
reconstruct the desired selector. (using func.func_code.co_varnames  
which is a hack, unfortunately).

I'm sure I'm forgetting something here, but it sounds plausible.

Orestis


On 29 Mar 2009, at 17:51, Ronald Oussoren wrote:

>
> On 29 Mar, 2009, at 10:28, Ian Beck wrote:
>
>> Hey Ronald,
>>
>>> The other change I'd like to make is to get rid of the extremely
>>> long and ugly method names in Python that are caused by segmented
>>> method names in Objective-C.
>>
>> Regarding your keyword argument solution, what if you did something
>> that merged the current underscore method with keyword arguments:
>>
>> someObject.loadResource_(1, inDirectory=2, error=None)
>
> This could work for calling methods, and as you note this could even
> be implemented in a backward compatible way.
>
> This won't work for defining new methods (or overriding existing ones
> for that matter) because some selectors  are prefixes of other  
> selectors.
>
>>
>> Of course, unique mappings from keyword selectors to methods would
>> still be a potential problem, but that might just be something that
>> the user would need to be responsible for.  As long as there was some
>> verbiage in the basic PyObjC documentation that made it clear you had
>> to get your keyword arguments in the exact same order as the  
>> Objective-
>> C method it probably wouldn't be too much of a barrier to entry.
>
>
> The order of keyword arguments is irrelevant for resolving to the  
> correct
> selector,  the keywords dictionary argument is basically unordered.  
> Ordered
> keyword dictionaries would make live a lot easier in this respect.
>
> Ronald
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Need design input for method names

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

On 29 Mar, 2009, at 10:28, Ian Beck wrote:

> Hey Ronald,
>
>> The other change I'd like to make is to get rid of the extremely
>> long and ugly method names in Python that are caused by segmented
>> method names in Objective-C.
>
> Regarding your keyword argument solution, what if you did something
> that merged the current underscore method with keyword arguments:
>
> someObject.loadResource_(1, inDirectory=2, error=None)

This could work for calling methods, and as you note this could even
be implemented in a backward compatible way.

This won't work for defining new methods (or overriding existing ones
for that matter) because some selectors  are prefixes of other  
selectors.

>
> Of course, unique mappings from keyword selectors to methods would
> still be a potential problem, but that might just be something that
> the user would need to be responsible for.  As long as there was some
> verbiage in the basic PyObjC documentation that made it clear you had
> to get your keyword arguments in the exact same order as the  
> Objective-
> C method it probably wouldn't be too much of a barrier to entry.


The order of keyword arguments is irrelevant for resolving to the  
correct
selector,  the keywords dictionary argument is basically unordered.  
Ordered
keyword dictionaries would make live a lot easier in this respect.

Ronald

Re: [Pyobjc-dev] Need design input for method names

[Ian B. <ia...@on...>]

Hey Ronald,

> The other change I'd like to make is to get rid of the extremely  
> long and ugly method names in Python that are caused by segmented  
> method names in Objective-C.

Regarding your keyword argument solution, what if you did something  
that merged the current underscore method with keyword arguments:

someObject.loadResource_(1, inDirectory=2, error=None)

This is slightly less straight-forward for users to wrap their heads  
around thanks to the mixture of standard and keyword arguments, but at  
least invoking single or no-argument methods would be a no-brainer  
(would function identically to the current implementation).  I'm not  
sure how you would implement this (just got into PyObjC a month or two  
ago, and what's going on behind the scenes still feels very much like  
magic), but from a design standpoint this is the best way to define  
methods I can think of that still offers a straight-forward conversion  
from Objective-C to Python but doesn't require heinous linelengths.

As an additional bonus, because it's essentially a refinement of the  
current implementation syntactically you might be able to maintain  
backwards compatibility (no keyword arguments? Fine, parse it the old  
way).

Of course, unique mappings from keyword selectors to methods would  
still be a potential problem, but that might just be something that  
the user would need to be responsible for.  As long as there was some  
verbiage in the basic PyObjC documentation that made it clear you had  
to get your keyword arguments in the exact same order as the Objective- 
C method it probably wouldn't be too much of a barrier to entry.

Ian

——————————————————
Ian Beck
ia...@on...

Tagamac: simple mac tagging
http://tagamac.com

Re: [Pyobjc-dev] Need design input for method names

[Ian B. <ia...@on...>]

Regarding this suggestion I made:

> someObject.loadResource_(1, inDirectory=2, error=None)

Of course that wouldn't work, because of methods that start the same  
(loadResource: vs. loadResource:inDirectory).  Of course I realize  
this after I send the email. D'oh!

Will continue to think about this.  The lengthy Objective-C methods  
are one of the things I dislike most about PyObjC.

Ian

On Mar 29, 2009, at 7:41 AM, Ronald Oussoren wrote:

> There are two things that I'd really like to change in PyObjC, and  
> preferably both at the same time because this will probably involve  
> backward-incompatible changes.
>
> The easy one is properties: I'd love to use "someObject.size = 5"  
> instead of "someObject.setSize_(5)". This is fairly easy to  
> implement, although defining custom read-accessors makes live  
> slightly more interesting (you cannot have a property named "foo"  
> and a method named "foo" in the same class in PyObjC).    The  
> largest blob of work for this is generating the right metadata for  
> PyObjC.
>
> The other change I'd like to make is to get rid of the extremely  
> long and ugly method names in Python that are caused by segmented  
> method names in Objective-C.  
> "someObject.loadResource_withType_inDirectory_error_(.........)" is  
> ugly and often results in code that is too wide for a reasonably  
> sized window.   This is were I need help, at the moment I don't know  
> how to get to a nicer API without changing the Python language  
> (which I don't want to do).
>
> There are a number of requirements for a solution to this problem:
>
> * Must not require manual mapping files
>
>  Manually maintained mapping files are bad because they are  
> maintained by persons, which make keeping up with Apple even
>  harder than it is at the moment.
>
> * Should tackle both calling methods as well as defining methods
>
> * Should have a simple description
>
>
> Options I have though of and don't like:
>
> * Define a __call__ method on NSObject that deduces the ObjC method  
> name from keyword arguments:
>
>          someObject(loadResource=1, inDirectory=2, error=None)
>
>   This could work for calling methods, but offers no clear path for  
> cleaning up method definitions. There are also
>   possible issues with calculating the method name, there's no  
> guarantee that there's a unique mapping from
>   keyword arguments to a selector (e.g. -addX:y:z: vs. addX:z:y:),  
> although that's probably not an issue in
>   practice.
>
>   A more significant issue is that this won't work for methods  
> without arguments (not all of which can be modelled
>   as properties).
>
> * Use method-call chaining:
>
>      someObject.loadResource_(1).inDirectory_(2).error_(None)
>
>   This is ugly, has the same problems as the first option and as an  
> additonal problem it is unclear if this can
>   be made to work at all because some ObjC selectors are prefixes of  
> other selectors.
>
> Ronald 
> ------------------------------------------------------------------------------
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

——————————————————
Ian Beck
ia...@on...

Tagamac: simple mac tagging
http://tagamac.com

Re: [Pyobjc-dev] Need design input for method names

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

Interleaving argument names and arguments using strings for the
selector chunks instead of kwargs has a simple mapping (but is not
pretty):
someObject('setSize', 5)
someObject('loadResource', resource, 'withType', someType,
'inDirectory', dir, 'error', err)

with a def __call__ something like this (mapping to current call convention):

def __call__(self, *args):
    sel = ''.join(arg.rstrip(':') + '_' for arg in args[::2])
    arg_vals = args[1::2]
    return getattr(self, sel)(*arg_vals)

2009/3/29 Ronald Oussoren <ron...@ma...>:
> There are two things that I'd really like to change in PyObjC, and
> preferably both at the same time because this will probably involve
> backward-incompatible changes.
>
> The easy one is properties: I'd love to use "someObject.size = 5" instead of
> "someObject.setSize_(5)". This is fairly easy to implement, although
> defining custom read-accessors makes live slightly more interesting (you
> cannot have a property named "foo" and a method named "foo" in the same
> class in PyObjC).    The largest blob of work for this is generating the
> right metadata for PyObjC.
>
> The other change I'd like to make is to get rid of the extremely long and
> ugly method names in Python that are caused by segmented method names in
> Objective-C.
> "someObject.loadResource_withType_inDirectory_error_(.........)" is ugly and
> often results in code that is too wide for a reasonably sized window.   This
> is were I need help, at the moment I don't know how to get to a nicer API
> without changing the Python language (which I don't want to do).
>
> There are a number of requirements for a solution to this problem:
>
> * Must not require manual mapping files
>
>  Manually maintained mapping files are bad because they are maintained by
> persons, which make keeping up with Apple even
>  harder than it is at the moment.
>
> * Should tackle both calling methods as well as defining methods
>
> * Should have a simple description
>
>
> Options I have though of and don't like:
>
> * Define a __call__ method on NSObject that deduces the ObjC method name
> from keyword arguments:
>
>          someObject(loadResource=1, inDirectory=2, error=None)
>
>   This could work for calling methods, but offers no clear path for cleaning
> up method definitions. There are also
>   possible issues with calculating the method name, there's no guarantee
> that there's a unique mapping from
>   keyword arguments to a selector (e.g. -addX:y:z: vs. addX:z:y:), although
> that's probably not an issue in
>   practice.
>
>   A more significant issue is that this won't work for methods without
> arguments (not all of which can be modelled
>   as properties).
>
> * Use method-call chaining:
>
>      someObject.loadResource_(1).inDirectory_(2).error_(None)
>
>   This is ugly, has the same problems as the first option and as an
> additonal problem it is unclear if this can
>   be made to work at all because some ObjC selectors are prefixes of other
> selectors.
>
> Ronald
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>

Re: [Pyobjc-dev] Need design input for method names

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

On 29 Mar, 2009, at 10:00, Bob Ippolito wrote:

> Interleaving argument names and arguments using strings for the
> selector chunks instead of kwargs has a simple mapping (but is not
> pretty):
> someObject('setSize', 5)
> someObject('loadResource', resource, 'withType', someType,
> 'inDirectory', dir, 'error', err)

That's an unstated requirement: the result should be prettier than the  
current solution and should not induce vomitting in hard-core Python  
developers ;-).

This definitely fails that, even with a minor tweak like this:

     someObject("setSize:", 5)
     someObject("loadResource:", resource, "withType:", someType,  
"inDirectory:", dir, "error:", None)

The best solution I've come up with so far requires changing the  
Python language definition (although this could be done using a custom  
import hook), something like this:

     $[someObject setSize: 5]
     rsrc, err =  $[someObject loadResource: resource withType:  
someType inDirectory: directory  error: None ]

     def $[self setSize: size]: pass

This could work, but I definitely don't want to go there because it  
changes the language syntax. And not only that, it changes it in a way  
that has 0 chance of being accepted into the language by Guido.

Ronald

>
> with a def __call__ something like this (mapping to current call  
> convention):
>
> def __call__(self, *args):
>    sel = ''.join(arg.rstrip(':') + '_' for arg in args[::2])
>    arg_vals = args[1::2]
>    return getattr(self, sel)(*arg_vals)
>
> 2009/3/29 Ronald Oussoren <ron...@ma...>:
>> There are two things that I'd really like to change in PyObjC, and
>> preferably both at the same time because this will probably involve
>> backward-incompatible changes.
>>
>> The easy one is properties: I'd love to use "someObject.size = 5"  
>> instead of
>> "someObject.setSize_(5)". This is fairly easy to implement, although
>> defining custom read-accessors makes live slightly more interesting  
>> (you
>> cannot have a property named "foo" and a method named "foo" in the  
>> same
>> class in PyObjC).    The largest blob of work for this is  
>> generating the
>> right metadata for PyObjC.
>>
>> The other change I'd like to make is to get rid of the extremely  
>> long and
>> ugly method names in Python that are caused by segmented method  
>> names in
>> Objective-C.
>> "someObject.loadResource_withType_inDirectory_error_(.........)" is  
>> ugly and
>> often results in code that is too wide for a reasonably sized  
>> window.   This
>> is were I need help, at the moment I don't know how to get to a  
>> nicer API
>> without changing the Python language (which I don't want to do).
>>
>> There are a number of requirements for a solution to this problem:
>>
>> * Must not require manual mapping files
>>
>>  Manually maintained mapping files are bad because they are  
>> maintained by
>> persons, which make keeping up with Apple even
>>  harder than it is at the moment.
>>
>> * Should tackle both calling methods as well as defining methods
>>
>> * Should have a simple description
>>
>>
>> Options I have though of and don't like:
>>
>> * Define a __call__ method on NSObject that deduces the ObjC method  
>> name
>> from keyword arguments:
>>
>>          someObject(loadResource=1, inDirectory=2, error=None)
>>
>>   This could work for calling methods, but offers no clear path for  
>> cleaning
>> up method definitions. There are also
>>   possible issues with calculating the method name, there's no  
>> guarantee
>> that there's a unique mapping from
>>   keyword arguments to a selector (e.g. -addX:y:z: vs. addX:z:y:),  
>> although
>> that's probably not an issue in
>>   practice.
>>
>>   A more significant issue is that this won't work for methods  
>> without
>> arguments (not all of which can be modelled
>>   as properties).
>>
>> * Use method-call chaining:
>>
>>      someObject.loadResource_(1).inDirectory_(2).error_(None)
>>
>>   This is ugly, has the same problems as the first option and as an
>> additonal problem it is unclear if this can
>>   be made to work at all because some ObjC selectors are prefixes  
>> of other
>> selectors.
>>
>> Ronald
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>>
>>