pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] Re: Using python classes in objc...

[Jiva D. <ji...@de...>]

Correction: the url I sent should have been:

http://cocoa.mamasam.com/COCOADEV/2004/01/1/81225.php


On Mar 10, 2004, at 10:01 AM, Jiva DeVoe wrote:

> I know I have asked this question before, and I even thought I knew 
> the answer, but apparently I still don't "get it."
>
> If I want to use a python class in my objective-c code, I know I can 
> use it via a nib etc.  But what if I want to use it right in my Obj-C 
> code itself?  ie:
>
> -(void)objCMethod
> {
> 	PythonClass pythonClass = [[PythonClass alloc] init];
> 	[pythonClass somePythonMethod];
> }
>
> I know, runtime is easy, but at compile time, I get an undefined 
> symbol for the python class (unless I compile with zero link, which I 
> don't want to do).
>
> I understand the basics of the naming and whatnot.  It's just the 
> undefined symbol I can't seem to fix.
>
> How do I get around this problem?  BBum has mentioned using a factory 
> method in an abstract superclass.  Ok, that's fine, but even then, the 
> factory method still has to instantiate the python class.  How does it 
> do so without linking the python code?
>
> As shown here (http://cocoa.mamasam.com/COCOADEV/2004/01/1/81235.php) 
> I am not alone in this question.  Anyone have some example code?  If 
> not example code, I'll take any amount of tips or help!
>
> --
> Jiva DeVoe
> jiva at devoesquared.com
> http://www.devoesquared.com
>
>
--
Jiva DeVoe
jiva at devoesquared.com
http://www.devoesquared.com

[Pyobjc-dev] Using python classes in objc...

[Jiva D. <ji...@de...>]

I know I have asked this question before, and I even thought I knew the 
answer, but apparently I still don't "get it."

If I want to use a python class in my objective-c code, I know I can 
use it via a nib etc.  But what if I want to use it right in my Obj-C 
code itself?  ie:

-(void)objCMethod
{
	PythonClass pythonClass = [[PythonClass alloc] init];
	[pythonClass somePythonMethod];
}

I know, runtime is easy, but at compile time, I get an undefined symbol 
for the python class (unless I compile with zero link, which I don't 
want to do).

I understand the basics of the naming and whatnot.  It's just the 
undefined symbol I can't seem to fix.

How do I get around this problem?  BBum has mentioned using a factory 
method in an abstract superclass.  Ok, that's fine, but even then, the 
factory method still has to instantiate the python class.  How does it 
do so without linking the python code?

As shown here (http://cocoa.mamasam.com/COCOADEV/2004/01/1/81235.php) I 
am not alone in this question.  Anyone have some example code?  If not 
example code, I'll take any amount of tips or help!

--
Jiva DeVoe
jiva at devoesquared.com
http://www.devoesquared.com

Re: [Pyobjc-dev] NSDecimalNumber to the next level

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

On Mar 10, 2004, at 9:15 AM, Ronald Oussoren wrote:

>
> On 10-mrt-04, at 17:08, Pierce T.Wetter III wrote:
>
>>>
>>> I completely forgot to mention that the usual numeric operators do 
>>> work correctly, as long as you manually convert floats to NSDecimal, 
>>> e.g. ``NSDecimalNumber.zero() + 4`` is valid code and will do what 
>>> you want.
>>
>> Hmmm.... That must have changed, because I submitted a change which 
>> you accepted awhile back to not implicitly convert. Checking...
>>
>> >>> print type(Foundation.NSDecimalNumber.zero())
>> <type 'float'>
>>
>> Arrgh, its converting again. That works because Python converted it 
>> implicitly to a float. (Which is actually kind of surprising, since I 
>> thought it had stopped doing that. See comment for (Bug #831774) in 
>> objc/objc_support.m)
>
> You're using the wrong version of PyObjC:
>
> >>> type (Foundation.NSDecimalNumber.zero())
> <objective-c class NSDecimalNumber at 0xa0a061f4>

  Doh!

  Pierce

[Pyobjc-dev] Documentation generation, Xcode templates, locating NibClassBuilder

[Donovan P. <ds...@ma...>]

A couple of questions about documentation and environment setup for 
PyObjC 1.1:

1) I started reading the pyobjc documentation in earnest again last 
night, and found myself editing it for spelling. I plan on reading 
every last word and touching the documentation up, but I need to know 
if there is a script I should run to generate the HTML before checking 
in?

2) I would like to update the Xcode templates using Bob's new PyMacApp 
main.m (I don't know if he announced it here, but he announced it on 
the MacPython mailing list). How many varieties of templates should I 
produce? The project builder templates had a bewildering variety of 
project types you could create... Also, should I look into updating the 
Project Builder templates, or is that too much of a can of worms to try 
to open. I don't have 10.2 installed but I suppose I could set up a 
10.2 testing environment.

3) Finally, the tutorial has some very ugly instructions about how to 
locate NibClassBuilder in a variety of situations. Is there any way 
this situation could be simplified? Perhaps the initial tutorial should 
instruct users on how to build an application using an Xcode template, 
and then only later introduce the shell commands for doing the same. I 
know a shell script which invokes NibClassBuilder is installed in the 
python bin directory, but this is not on the $PATH by default. Should 
the installer make a symlink to this script into somewhere that is on 
the $PATH?

In general I would like to see the introductory documentation and 
environment setup situation improved in time for the final 1.1, and I 
am willing to spend the time to make this happen. More 
suggestions/requests for things to be done would also be welcome.

dp

Re: [Pyobjc-dev] NSDecimalNumber to the next level

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

On 10-mrt-04, at 17:08, Pierce T.Wetter III wrote:

>>
>> I completely forgot to mention that the usual numeric operators do 
>> work correctly, as long as you manually convert floats to NSDecimal, 
>> e.g. ``NSDecimalNumber.zero() + 4`` is valid code and will do what 
>> you want.
>
> Hmmm.... That must have changed, because I submitted a change which 
> you accepted awhile back to not implicitly convert. Checking...
>
> >>> print type(Foundation.NSDecimalNumber.zero())
> <type 'float'>
>
> Arrgh, its converting again. That works because Python converted it 
> implicitly to a float. (Which is actually kind of surprising, since I 
> thought it had stopped doing that. See comment for (Bug #831774) in 
> objc/objc_support.m)

You're using the wrong version of PyObjC:

 >>> type (Foundation.NSDecimalNumber.zero())
<objective-c class NSDecimalNumber at 0xa0a061f4>

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

Re: [Pyobjc-dev] NSDecimalNumber to the next level

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

On Mar 10, 2004, at 7:09 AM, Pierce T.Wetter III wrote:
>   Oh, don't get me started on NSDecimalNumber's failings. Here are 
> some:
>
>    [[NSDecimalNumber zero] decimalNumberByAdding: nil]; <--- bus error
>    [[NSDecimalNumber zero] decimalNumberByAdding: [NSNumber 
> numberWithInt:1]]; <-- bus error
>
>   Basically, NSDN dies if you do math with anything but another NSDN, 
> which is irritating
>  because you'd really like NSDN to be a full member of the NSNumber 
> class cluster.

Neat [not!]

If you haven't already, please file bugs/feature requests regarding the 
above at http://bugreport.apple.com/

b.bum

Re: [Pyobjc-dev] NSDecimalNumber to the next level

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

>
> I completely forgot to mention that the usual numeric operators do  
> work correctly, as long as you manually convert floats to NSDecimal,  
> e.g. ``NSDecimalNumber.zero() + 4`` is valid code and will do what you  
> want.

Hmmm.... That must have changed, because I submitted a change which you  
accepted awhile back to not implicitly convert. Checking...

 >>> print type(Foundation.NSDecimalNumber.zero())
<type 'float'>

Arrgh, its converting again. That works because Python converted it  
implicitly to a float. (Which is actually kind of surprising, since I  
thought it had stopped doing that. See comment for (Bug #831774) in  
objc/objc_support.m)

This code doesn't work now though:

 >>> print  
Foundation.NSDecimalNumber.numberWithDouble_(3.3).decimalNumberByAdding_ 
(Foundation.NSDecimalNumber.numberWithDouble_(4.4))Traceback (most  
recent call last):
   File "<stdin>", line 1, in ?
AttributeError: 'float' object has no attribute 'decimalNumberByAdding_'

Again, because of the implicit float conversion, which then can't  
convert back.


> Automaticly converting floats to NSDecimal is easy enough, it is a  
> couple of extra lines in Modules/Foundation/decimal.m (I'm not 100%  
> sure about the filename, but it should be close).

   Ok, I'll poke around and see what I can figure out then. I'll have to  
think about all the use cases anyways, since what I really want is:

case 1:   do math in python with NSDN without having to call  
doubleValue()
      print Foundation.NSDecimalNumber.zero()+4

case 2:   yet be able to call NSDN methods?
print  
Foundation.NSDecimalNumber.numberWithDouble_(3.3).decimalNumberByAdding_ 
(Foundation.NSDecimalNumber.numberWithDouble_(4.4))

case 3:   and pass NSDN back to objc
    object.setDecimalNumberValue_(4.4)   (call objc method that takes an  
NSDN)

    To all work.

    Hmm... You know, really, since NSDN is a superset of NSNumber, if  
PyObjC always passed NSDecimalNumbers back to objc instead of  
NSNumbers, things would mostly work. I couldn't do case 2, but I'm not  
sure I'd care then. Though being able to do:

Foundation.NSDecimalNumber.numberWithDouble(3.3).decimalNumberByMultiply 
ingBy_withBehavior_(3.4, pennyRounding)

Is useful. Hmmm.. Adding all the NSDecimalNumber methods to the Python  
float type would work then.

  Arrgh. Brain hurts now. Need more coffee.

  Pierce

Re: [Pyobjc-dev] NSDecimalNumber to the next level

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

On 10-mrt-04, at 16:09, Pierce T.Wetter III wrote:

>
> On Mar 9, 2004, at 11:55 PM, Ronald Oussoren wrote:
>
>>
>> On 10-mrt-04, at 7:41, Ronald Oussoren wrote:
>>> >>> Foundation.NSDecimalNumber.zero().decimalNumberByAdding_(1.0)
>>> 0
>>>
>>> The last one is a bug, it should raise TypeError just like:
>>
>> The problem seems to be in NSDecimalNumber not PyObjC:
>>
>> >>> Foundation.NSDecimalNumber.zero().decimalNumberByAdding_("a")
>> 0
>
>   Oh, don't get me started on NSDecimalNumber's failings. Here are 
> some:
>
>    [[NSDecimalNumber zero] decimalNumberByAdding: nil]; <--- bus error
>    [[NSDecimalNumber zero] decimalNumberByAdding: [NSNumber 
> numberWithInt:1]]; <-- bus error

Please file some bugs at bugreport.apple.com if you haven't done so 
yet, complaining here won't get these fixed :-)

>
>   Basically, NSDN dies if you do math with anything but another NSDN, 
> which is irritating
>  because you'd really like NSDN to be a full member of the NSNumber 
> class cluster.
>
>   However, I don't get to change NSDN. I can change PyObjC, so I'd 
> like to change it so that it knows how to build an NSDN when it needs 
> one.

I completely forgot to mention that the usual numeric operators do work 
correctly, as long as you manually convert floats to NSDecimal, e.g. 
``NSDecimalNumber.zero() + 4`` is valid code and will do what you want.

> I'm not overly worried about the loss of precision, because if you're 
> doing stuff in Python, then you should know that you're doing it with 
> Python arithmetic, which is based on double. For me (I realize this 
> isn't everyone) I use Python to write mini-tools based on our object 
> model frameworks. So I want convenience more then accuracy.
>
>   So of course, the ideal would be that if you do math in Python, it 
> implicitly converts it. If you don't do the math in python, it 
> doesn't.

I prefer explicit conversion for NSDecimal, because the interface seems 
to be meant for people that do care about loosing information. I will 
however keep an eye on the decimal number PEP, if this gets accepted 
and implemented I will update the NSDecimal support to have a simular 
interface as the decimal type (where appropriate).

>
>   Note that this wouldn't involve any loss of precision for instance:
>
>    Foundation.NSDecimalNumber.zero().decimalNumberByAdding_(1)
>
>   Because the bridge would build the 1 as an NSDecimalNumber.
>
>   This would:
>
>    z=Foundation.NSDecimalNumber.zero()
>    z= z+1
>
>    But that seems OK to me because z is now a python variable, and 
> python variables are
>    doubles.

No, no, no, python numbers need not be numbers. Instances of int() and 
long() are not, and instances of NSDecimal are not either. In your 
example 'z' is still an NSDecimalNumber.

the line 'z = z + 1' is syntactic sugar for 'z = z.__add__(1)', and 
that method is implemented for NSDecimal and NSDecimalNumber and will 
convert integer values (but not floats) to NSDecimal before performing 
the operation. The method returns an NSDecimal or NSDecimalNumber.


> If you don't want the loss of precision when you move to Python, you 
> should
>    use some sort of Python class that supports larger precision and do 
> the math in that.
>
>    Anyways, that's my $.02. (Does "That's my two cents translate to 
> .nl?)

Yes, to EUR 0.01something ;)


>
>    So anyways, is it possible for the bridge to look at the required 
> class for a parameter, and do different conversions? That is, if I'm 
> calling decimalNumberByAdding_(x)
> can the bridge tell that it needs an NSDecimalNumber * and so it needs 
> to do conversions where necessary?

Automaticly converting floats to NSDecimal is easy enough, it is a 
couple of extra lines in Modules/Foundation/decimal.m (I'm not 100% 
sure about the filename, but it should be close).

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

Re: [Pyobjc-dev] NSDecimalNumber to the next level

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

On Mar 9, 2004, at 11:55 PM, Ronald Oussoren wrote:

>
> On 10-mrt-04, at 7:41, Ronald Oussoren wrote:
>> >>> Foundation.NSDecimalNumber.zero().decimalNumberByAdding_(1.0)
>> 0
>>
>> The last one is a bug, it should raise TypeError just like:
>
> The problem seems to be in NSDecimalNumber not PyObjC:
>
> >>> Foundation.NSDecimalNumber.zero().decimalNumberByAdding_("a")
> 0

   Oh, don't get me started on NSDecimalNumber's failings. Here are some:

    [[NSDecimalNumber zero] decimalNumberByAdding: nil]; <--- bus error
    [[NSDecimalNumber zero] decimalNumberByAdding: [NSNumber 
numberWithInt:1]]; <-- bus error

   Basically, NSDN dies if you do math with anything but another NSDN, 
which is irritating
  because you'd really like NSDN to be a full member of the NSNumber 
class cluster.

   However, I don't get to change NSDN. I can change PyObjC, so I'd like 
to change it so that it knows how to build an NSDN when it needs one. 
I'm not overly worried about the loss of precision, because if you're 
doing stuff in Python, then you should know that you're doing it with 
Python arithmetic, which is based on double. For me (I realize this 
isn't everyone) I use Python to write mini-tools based on our object 
model frameworks. So I want convenience more then accuracy.

   So of course, the ideal would be that if you do math in Python, it 
implicitly converts it. If you don't do the math in python, it doesn't.

   Note that this wouldn't involve any loss of precision for instance:

    Foundation.NSDecimalNumber.zero().decimalNumberByAdding_(1)

   Because the bridge would build the 1 as an NSDecimalNumber.

   This would:

    z=Foundation.NSDecimalNumber.zero()
    z= z+1

    But that seems OK to me because z is now a python variable, and 
python variables are
    doubles. If you don't want the loss of precision when you move to 
Python, you should
    use some sort of Python class that supports larger precision and do 
the math in that.

    Anyways, that's my $.02. (Does "That's my two cents translate to 
.nl?)

    So anyways, is it possible for the bridge to look at the required 
class for a parameter, and do different conversions? That is, if I'm 
calling decimalNumberByAdding_(x)
can the bridge tell that it needs an NSDecimalNumber * and so it needs 
to do conversions where necessary?

  Pierce

Re: [Pyobjc-dev] NSDecimalNumber to the next level

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

On 10-mrt-04, at 7:41, Ronald Oussoren wrote:
> >>> Foundation.NSDecimalNumber.zero().decimalNumberByAdding_(1.0)
> 0
>
> The last one is a bug, it should raise TypeError just like:

The problem seems to be in NSDecimalNumber not PyObjC:

 >>> Foundation.NSDecimalNumber.zero().decimalNumberByAdding_("a")
0


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

Re: [Pyobjc-dev] NSDecimalNumber to the next level

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

On 9-mrt-04, at 19:29, Pierce T.Wetter III wrote:

>>>  I want to take NSDecimalNumber to the next level.
>>>
>>>  History:
>>>
>>>   1.0.
>>>
>>>    NSDecimalNumber is wrapped as identical to CFNumber, which turns  
>>> out not work.
>>>
>>>   1.1
>>>
>>>    NSDecimalNumbers are passed through untransformed, you can use:
>>>
>>>   dv=obj.doubleValue() to convert them to Python doubles, then:
>>>
>>>    NSDecimalNumber.numberWithDouble(dv) to convert them back. This  
>>> had to happen because the type information was getting lost, and the  
>>> values passed back to Objective-C were plain CFNumber classes, which  
>>> didn't implement NSDecimalNumber.decimalNumberByAdding_(dv), etc.
>>
>> The type info should not get lost, NSDecimalNumber and NSDecimal (the  
>> C type backing the NSDecimalNumber class) should work correctly as  
>> numbers, including save coercions. I explicitly disabled implicit  
>> coercion from NSDecimal{Number,} to and from float because you might  
>> loose precision that way.
>>
>> If this doesn't work you found a bug that should be fixed.
>
> Call me crazy, but I'd like to get this code to work:
>
> import objc
> import Foundation
> print  
> Foundation.NSDecimalNumber.zero().decimalNumberByAdding_(Foundation.NSD 
> ecimalNumber.zero())
> print Foundation.NSDecimalNumber.zero().decimalNumberByAdding_(1.0)
> That's what I would like to be able to do.

 >>> import Foundation
 >>>  
Foundation.NSDecimalNumber.zero().decimalNumberByAdding_(Foundation.NSDe 
cimalNumber.zero())
0
 >>> type(_)
<objective-c class NSDecimalNumber at 0xa0a061f4>
 >>> Foundation.NSDecimalNumber.zero().decimalNumberByAdding_(1.0)
0

The last one is a bug, it should raise TypeError just like:
 >>> Foundation.NSDecimal(0) + 1.0
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
TypeError: unsupported operand type(s) for +: 'Foundation.NSDecimal'  
and 'float'

 From what I've seen from NSDecimal is simular to the type described in  
PEP 327 and the last time I saw discussion about this they seemed to  
favor explicit conversion from float for various reasons.

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

Re: [Pyobjc-dev] NSDecimalNumber to the next level

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

>>  I want to take NSDecimalNumber to the next level.
>>
>>  History:
>>
>>   1.0.
>>
>>    NSDecimalNumber is wrapped as identical to CFNumber, which turns  
>> out not work.
>>
>>   1.1
>>
>>    NSDecimalNumbers are passed through untransformed, you can use:
>>
>>   dv=obj.doubleValue() to convert them to Python doubles, then:
>>
>>    NSDecimalNumber.numberWithDouble(dv) to convert them back. This  
>> had to happen because the type information was getting lost, and the  
>> values passed back to Objective-C were plain CFNumber classes, which  
>> didn't implement NSDecimalNumber.decimalNumberByAdding_(dv), etc.
>
> The type info should not get lost, NSDecimalNumber and NSDecimal (the  
> C type backing the NSDecimalNumber class) should work correctly as  
> numbers, including save coercions. I explicitly disabled implicit  
> coercion from NSDecimal{Number,} to and from float because you might  
> loose precision that way.
>
> If this doesn't work you found a bug that should be fixed.

Call me crazy, but I'd like to get this code to work:

import objc
import Foundation
print  
Foundation.NSDecimalNumber.zero().decimalNumberByAdding_(Foundation.NSDe 
cimalNumber.zero())
print Foundation.NSDecimalNumber.zero().decimalNumberByAdding_(1.0)
That's what I would like to be able to do.

Perhaps its not possible though, I dunno. Is the bridge able to detect  
when a method is expecting an NSDecimalNumber * for a parameter?

  Pierce

Re: [Pyobjc-dev] NSDecimalNumber to the next level

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

On 9-mrt-04, at 18:02, Pierce T.Wetter III wrote:

>
>
>  I want to take NSDecimalNumber to the next level.
>
>  History:
>
>   1.0.
>
>    NSDecimalNumber is wrapped as identical to CFNumber, which turns 
> out not work.
>
>   1.1
>
>    NSDecimalNumbers are passed through untransformed, you can use:
>
>   dv=obj.doubleValue() to convert them to Python doubles, then:
>
>    NSDecimalNumber.numberWithDouble(dv) to convert them back. This had 
> to happen because the type information was getting lost, and the 
> values passed back to Objective-C were plain CFNumber classes, which 
> didn't implement NSDecimalNumber.decimalNumberByAdding_(dv), etc.

The type info should not get lost, NSDecimalNumber and NSDecimal (the C 
type backing the NSDecimalNumber class) should work correctly as 
numbers, including save coercions. I explicitly disabled implicit 
coercion from NSDecimal{Number,} to and from float because you might 
loose precision that way.

If this doesn't work you found a bug that should be fixed.

Ronald

Re: [Pyobjc-dev] Building an installer package

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

On 9-mrt-04, at 17:51, Pierce T.Wetter III wrote:

>
>  So while no one else really cares about the one small change since 
> 1.1b1, I do!
>
>  So I was wondering if I could get instructions for building an 
> installer package from the latest sources, since there seems to be 
> some automated way to do that, but I couldn't find any obvious script, 
> and "setup.py bdist" only build a tar file.

Scripts/make_distrib.py should do it.

This will create everything, source dist, installer and a binary dist 
for the packman database.

You need docutils and DocArticle (part of the docutil sandbox) to 
rebuild the documentation, the script should function correctly without 
those.

I hope to do a 1.1 release soon, but my weekends are fully booked at 
the moment.

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

[Pyobjc-dev] NSDecimalNumber to the next level

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

  I want to take NSDecimalNumber to the next level.

  History:

   1.0.

    NSDecimalNumber is wrapped as identical to CFNumber, which turns out 
not work.

   1.1

    NSDecimalNumbers are passed through untransformed, you can use:

   dv=obj.doubleValue() to convert them to Python doubles, then:

    NSDecimalNumber.numberWithDouble(dv) to convert them back. This had 
to happen because the type information was getting lost, and the values 
passed back to Objective-C were plain CFNumber classes, which didn't 
implement NSDecimalNumber.decimalNumberByAdding_(dv), etc.

  1.2?

   I want to work on improving this a bit, so that the NSDecimalNumber 
can be more or less transparent to the user so they can do something 
like this:

  Objc:

  + (NSDecimalNumber *) addOne: (NSDecimalNumber *) value
  {
     return [value decimalNumberByAdding: [NSDecimalNumber one]];
  }

  Python:

     value1 = NSDecimalNumber.zero()
     value1 += 1;
     value2 = NSDecimalNumber.addOne(value1)

     if value2 = 2: print "it works!"

    Right now the first one doesn't work, because Python no longer knows 
that NSDecimalNumber can be used as a double, you have to rewrite it 
as:

     value1 = NSDecimalNumber.zero().doubleValue()
     value1 += 1;
     value2 = NSDecimalNumber.addOne(
                  NSDecimalNumber.numberWithDouble(value1))

     if value2.doubleValue() = 2: print "it works!"

    Which gets cumbersome quickly...


  I'll do the work if someone can give me a bit of an outline on what I 
need to do, or perhaps can point me at a class that has been custom 
bridged that I can crib from?

   Pierce

[Pyobjc-dev] Building an installer package

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

  So while no one else really cares about the one small change since 
1.1b1, I do!

  So I was wondering if I could get instructions for building an 
installer package from the latest sources, since there seems to be some 
automated way to do that, but I couldn't find any obvious script, and 
"setup.py bdist" only build a tar file.

  Pierce

[Pyobjc-dev] [ pyobjc-Bugs-911741 ] Mistake in tutorial .nib

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

Bugs item #911741, was opened at 2004-03-07 19:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=911741&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jordan Krushen (furie)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mistake in tutorial .nib

Initial Comment:
In http://pyobjc.sourceforge.net/doc/step3-MainMenu.nib.zip, the 
tutorial (CurrencyConverter) nib, there are two 'Convert' buttons 
placed.  One may accidentally connect to the wrong button, causing 
some confusion.

Plus, it looks odd ;P

Not sure if this is the same file used in the new distribution or not.

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

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

[Pyobjc-dev] Getting -O into python via buildapp

[Andrew P. L. Jr. <bs...@al...>]

How do I get the "-O" flag to go active when using an application built
via the buildapp.py method?

The need for this is that I have a lot of asserts for debugging which turn
off when passed the "-O" flag.

Thanks,
-a

Re: [Pyobjc-dev] NGPython

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

On 01.03.2004, at 18:08, b.bum wrote:
> Please read the rather long thread on python-dev.  All of the points 
> you raise have been addressed in that thread.

Well, I think I have very well understood your point on that.

The reason why I still like the approach is that we have the experience 
that it works just great in practice, has little to no maintenance 
issues and is much easier to understand for non-Objective-C people. So 
you may or may not follow on that, your decision ;-)
Really no point in discussing that.

> This is a subject that has come up every 18 months to two years for 
> the history of the PyObjC project (since 1994/1995) and the change has 
> not been made yet.

Well, at least I can provide code for getting started, I guess that 
validates bringing up the topic yet another time ;-)

> A mapping based solution attemps to "port" the Objective-C API into 
> Python in a "Pythonic" fashion.  The end result is an API that is 
> neither Objective-C nor Python.   It sort of looks like Python, but 
> there will be all kinds of weird little special cases resulting from 
> the underlying C nature of Objective-C.

Actually this is less a problem with Python since you can override all 
the Pythonic stuff (for iterators, attributes access etc) and make 
Objective-C objects look like regular Python ones.

> A mapped solution ensures that the developer cannot look in either of 
> these places to find canonical information as to what they should 
> implement.

Only if the mapping is unnatural and difficult to understand. Which it 
isn't.

Besides that its not a big deal at all to write a small Python script 
which generates new index files into Objective-C documentation which 
takes mappings into account.

> Furthermore, the Objective-C method names are meaningful.   
> -setObject:forKey: says more than just "this is a method named 
> 'setObject:forKey:', it also gives information about the arguments and 
> their order (and, no, they are not named arguments).   A mapping based 
> solution loses all of that.

I don't see why. You can of course map the selector setObject:forKey: 
to a method named setObjectForKey in case you want to do that. After 
all thats the whole point - making better user-level method names which 
are natural in the host language.

Note: the pybridget tool also supports matching based on positional 
parameters, not only on keywords.

> This was one of the primary complaints about bridged Java (and WO 
> 5.x).   The Java APIs were a mutated Foundation.   It was less 
> approachable to new developers because the API was not as 
> self-descriptive.

If you say so. I think its more a problem of having various different 
collection classes and few ways to mix their usage (say List vs NSArray 
vs Collection.Array vs JGL vs ...).
But, no point (and interest ;-) in discussing that.

This isn't so much a problem with Python where Foundation collections 
can act like regular Python collections.

>> Anyway, we can let the thread stop here, my posting wasn't really 
>> meant to start a flamewar but to offer some code in case someone is 
>> interested ;-)
>
> No flamewar -- I don't think you understand how much thought, effort, 
> and engineering has gone into the current implementation, including a 
> lot of thinking as to how to make a mapping based solution work.

OK. I can ackknowledge that, in case you also understand how much 
thought, effort, and engineering were done in the NGPython 
implementation, including a lot of thinking as to how to make a mapping 
based solution work ;-)

I did not want to start a discussion, if PyObjC people have decided not 
to do any mapping, its their choice, no discussion about that. I *only* 
offered some code which could help getting started with that and 
mentioned, that the approach worked just fine for us.

>> BTW: your post fails to list the really interesting parts, like the 
>> required reverse mapping of selectors for subclassing Objective-C 
>> objects in Python.
> Subclassing works fine.

Yes, of course, but its more interesting (difficult) with a mapping 
framework in place ;-)

> Go read the python-dev thread, there is a lot more info there....

Sorry, not enough sparetime.

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

Re: [Pyobjc-dev] NGPython

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

Please read the rather long thread on python-dev.  All of the points 
you raise have been addressed in that thread.

This is a subject that has come up every 18 months to two years for the 
history of the PyObjC project (since 1994/1995) and the change has not 
been made yet.   None of us are attached to the '_' based notation, but 
it remains because it is brain-dead simple and has no exceptions beyond 
those necessary to support the idiosyncrasies of mapping C to Python.

> Good points, yet the "usual" mapping rule is pretty easy to explain 
> and understand and just makes sense. Like if you have an Objective-C 
> method with "With", the "With" denotes keyword arguments 
> (initWithSet:, NSSet(set=)).
> I don't think this is much more difficult for the regular developer to 
> remember.

Except that there are exceptions.... and exceptions to the exceptions...

End result developer has to remember:  "This is the mapping, except 
this special case and that special case and this other special case and 
that inconsistency and, oh wait, this is a new framework, it hasn't 
been mapped yet and oops, Apple released a new version, those haven't 
been mapped yet but will be..."

On Mar 1, 2004, at 2:02 AM, Helge Hess wrote:
> On 01.03.2004, at 07:26, b.bum wrote:
>>> 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.
>
> Could you elaborate? What do you mean by "can be expressed as a single 
> rule"?  Do you care about speed?
> Of course the mapping "can" be expressed as a single rule as long as 
> it is unique.

Speed is just a matter of caching and optimizations.

The last sentence of your statement is exactly why mappings are a 
nightmare.   There will always be special cases, including dealing with 
situations where the default "mapping" is not unique.

>> There will be special cases and the end result will be a new language 
>> that is effectively a hybrid between Python and Objective-C.
>
> Absolutely not, this is just regular Python - a function which does 
> different things depending on the input parameters. Of course the 
> developer need to know about the used libraries in any case.

A language is a combination of its syntax and the APIs of the base 
libraries.   To effectively use Python, you need to know Python and you 
need to know some limited subset of the python library.  The same is 
true of Cocoa or GNUStep based Objective-C.

A mapping based solution attemps to "port" the Objective-C API into 
Python in a "Pythonic" fashion.  The end result is an API that is 
neither Objective-C nor Python.   It sort of looks like Python, but 
there will be all kinds of weird little special cases resulting from 
the underlying C nature of 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.
>
> I can't see why. Indeed he does need to know much less about 
> Objective-C than before if he doesn't do exotic things.

That is incorrect.  The developer still has to know that there is API 
to be called and still  has to find that API.   As it stands, the 
developer can find the API by looking directly in the Python library or 
finding the API by looking directly in the Objective-C header files 
[API].

A mapped solution ensures that the developer cannot look in either of 
these places to find canonical information as to what they should 
implement.

Furthermore, the Objective-C method names are meaningful.   
-setObject:forKey: says more than just "this is a method named 
'setObject:forKey:', it also gives information about the arguments and 
their order (and, no, they are not named arguments).   A mapping based 
solution loses all of that.

This was one of the primary complaints about bridged Java (and WO 5.x). 
   The Java APIs were a mutated Foundation.   It was less approachable 
to new developers because the API was not as self-descriptive.

>> 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.
>
> There are obviously situations where and explicit factory makes a lot 
> more sense, yet, in the case of NSSet its awkward and unintuitive for 
> Python developers (and even Objective-C developers will get into 
> difficulties to know what syntax to use in what situation).

If Objective-C developers have difficulty and that difficulty is still 
found in bridged Obj-C on the python side, why go through such pains to 
hide it?

Again, unless the PyObjC project were to specifically document each and 
every mapping, there is nowhere that the developer could look up 
NSSet(array=myArray) to understand what is being invoked on the ObjC 
side.

> Anyway, we can let the thread stop here, my posting wasn't really 
> meant to start a flamewar but to offer some code in case someone is 
> interested ;-)

No flamewar -- I don't think you understand how much thought, effort, 
and engineering has gone into the current implementation, including a 
lot of thinking as to how to make a mapping based solution work.

I think I can safely speak for the entire pyobjc-dev community in 
saying that we all think the '_' based notation isn't pretty.   But the 
lack of 'pythonic syntax' is a disadvantage that pales in comparison to 
having a solution that "just works" across releases of the OS and with 
any Objective-C API available, including those that we have never 
"mapped".

> BTW: your post fails to list the really interesting parts, like the 
> required reverse mapping of selectors for subclassing Objective-C 
> objects in Python.

Subclassing works fine.

Go read the python-dev thread, there is a lot more info there....

b.bum

Re: [Pyobjc-dev] NGPython

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

On 01.03.2004, at 10:19, Ronald Oussoren wrote:
> IMHO the major problems are documentation and effort. If we would 
> rename methods we would basically render most existing Cocoa 
> documentation useless for Python users, using the current scheme it is 
> easy to use the existing documentation and translate Objective-C code 
> snippets into Python. Maintaining a seperate set of documentation for 
> PyObjC would be a lot of work.

Good points, yet the "usual" mapping rule is pretty easy to explain and 
understand and just makes sense. Like if you have an Objective-C method 
with "With", the "With" denotes keyword arguments (initWithSet:, 
NSSet(set=)).
I don't think this is much more difficult for the regular developer to 
remember.

> Maintaining the mapping would also be a lot of work (and the 
> development would be even more work).

No, not at all. Told from experience ;-)

> PyObjC development is done by a very small group in their spare time, 
> there just isn't enough room to do the additional work that would be 
> required for maintaining the mapping.

Well, I would volunteer to do that. Should be some 2h per MacOSX 
release (= per year) ;-)
Don't forget that you do *not* need to map every single selector from 
every single class. You only need to map additional selectors and even 
with those, there can be default mappings.

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

Re: [Pyobjc-dev] NGPython

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

On 01.03.2004, at 09:14, Dinu Gherman wrote:
> I think, we've talked to each other some two years ago on the
> Wocoa People meeting in Berlin, and I tried to pull something
> out of you at that time, but in vain...

Hu? I'm pretty sure I sent you the stuff after the Wocoa! (though I 
never got any feedback, maybe it really went to /dev/null ;-) Its just 
that this was only for the GNU runtime which probably was uninteresting 
for you.

> Apart from that, it's obviously too late to change the mapping
> rules without having some *real* advantage... ;-)

Well, I consider that a real advantage for Python focused developers 
which do not care about Objective-C but only for AppKit. Maybe it even 
could be an option (beautifulMappingsOn=YES ;-).

Anyway, I don't complain. Personally I would love to see the pybridget 
syntax, but unless someone else with sparetime does as well, we won't 
see that anyway ;-)

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

Re: [Pyobjc-dev] NGPython

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

On 01.03.2004, at 07:26, b.bum wrote:
>> 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.

Could you elaborate? What do you mean by "can be expressed as a single 
rule"?  Do you care about speed?
Of course the mapping "can" be expressed as a single rule as long as it 
is unique.

> There will be special cases and the end result will be a new language 
> that is effectively a hybrid between Python and Objective-C.

Absolutely not, this is just regular Python - a function which does 
different things depending on the input parameters. Of course the 
developer need to know about the used libraries in any case.

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

I can't see why. Indeed he does need to know much less about 
Objective-C than before if he doesn't do exotic things.

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

Well, all Python developers I know can perfectly deal with that. Its 
just regular style, eg extensively used in Zope.

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

There are obviously situations where and explicit factory makes a lot 
more sense, yet, in the case of NSSet its awkward and unintuitive for 
Python developers (and even Objective-C developers will get into 
difficulties to know what syntax to use in what situation).

> Relevant post here:
> http://www.pycs.net/bbum/2003/11/29.html

OK, your position understood ;-) We had none of your issues listed 
(neither speed nor maintenance) and used the stuff in real world 
applications for some two years or so. Writing .jobs files is a 
no-brainer and there is nothing which prevents you from falling back to 
"ugly" syntax in case there is no mapping.

Anyway, we can let the thread stop here, my posting wasn't really meant 
to start a flamewar but to offer some code in case someone is 
interested ;-)

BTW: your post fails to list the really interesting parts, like the 
required reverse mapping of selectors for subclassing Objective-C 
objects in Python.

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

Re: [Pyobjc-dev] NGPython

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

On 1-mrt-04, at 9:14, Dinu Gherman wrote:

> Helge Hess:
>
>> 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. [...]
>>
>> 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 ...
>
> Hi Helge,
>
> I think, we've talked to each other some two years ago on the
> Wocoa People meeting in Berlin, and I tried to pull something
> out of you at that time, but in vain...
>
> Apart from that, it's obviously too late to change the mapping
> rules without having some *real* advantage... ;-)

Like Bill pointed out the mapping stuff has some real disadvantages, 
even though they would allow for a nicer API (e.g. without those 
irritating underscores).

IMHO the major problems are documentation and effort. If we would 
rename methods we would basically render most existing Cocoa 
documentation useless for Python users, using the current scheme it is 
easy to use the existing documentation and translate Objective-C code 
snippets into Python. Maintaining a seperate set of documentation for 
PyObjC would be a lot of work.

Maintaining the mapping would also be a lot of work (and the 
development would be even more work). PyObjC development is done by a 
very small group in their spare time, there just isn't enough room to 
do the additional work that would be required for maintaining the 
mapping.

If someone does have a lot of time to spend on improving the Cocoa <-> 
Python mapping I'd spend it on trying to find a way to add (an 
emultation of) segmented method names to Python.

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

Re: [Pyobjc-dev] NGPython

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

Helge Hess:

> 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. [...]
>
> 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 ...

Hi Helge,

I think, we've talked to each other some two years ago on the
Wocoa People meeting in Berlin, and I tried to pull something
out of you at that time, but in vain...

Apart from that, it's obviously too late to change the mapping
rules without having some *real* advantage... ;-)

Regards,

Dinu

--
Dinu C. Gherman - http://python.net/~gherman
......................................................................
"The best way to predict the future is to invent it." (Alan Kay)