pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] MacUpdate Dev: PyObjC updated

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

the PyObjC team,

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

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

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

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

-Joel Mueller
www.macupdate.com

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

[Pyobjc-dev] Onboardc-project-request--Bachelor's Diploma, Master's, or PhD - No Classes Necessary

[Keisha S. <eye...@ne...>]

spencer eugene illimitable heterosexual northampton brigantine lucian mcginnis cern wanton 
cigarette isothermal seclude carcinoma counterpoise hubbard 
wrapup indissoluble astigmat birdie wait beginning briefcase owe snow 

[Pyobjc-dev] [ pyobjc-Bugs-888270 ] Deployed project fails with "No module named _objc"

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

Bugs item #888270, was opened at 2004-01-31 19:38
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=888270&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Brooksby (rptb1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Deployed project fails with "No module named _objc"

Initial Comment:
I pulled PyObjC down from CVS today (2004-01-31), built 
and installed is using "setup.py".  I also installed the Xcode 
template in "~/Library/Application Support/Apple/
Developer Tools/Project 
Templates/Application".  I can build a new project and run 
it on my machine, but on another without PyObjC installed 
I get this traceback.

Lorikeet:~/tmp/Test Python Application.app/Contents/
MacOS rb$ ./Test\ Python\ Application 
Traceback (most recent call last):
  File "/Users/rb/tmp/Test Python Application.app/
Contents/Resources/__main__.py", line 9, in ?
    from PyObjCTools import AppHelper
  File "/Users/rb/tmp/Test Python Application.app/
Contents/Resources/PyObjCTools/AppHelper.py", line 10, in 
?
    from AppKit import NSApplicationMain, NSApp, 
NSRunAlertPanel
  File "/Users/rb/tmp/Test Python Application.app/
Contents/Resources/AppKit/__init__.py", line 8, in ?
    import Foundation
  File "/Users/rb/tmp/Test Python Application.app/
Contents/Resources/Foundation/__init__.py", line 1, in ?
    import objc as _objc
  File "/Users/rb/tmp/Test Python Application.app/
Contents/Resources/objc/__init__.py", line 18, in ?
    from _objc import *
ImportError: No module named _objc
2004-01-31 19:01:40.870 Test Python Application[546] *** 
Uncaught exception: <NSInternalInconsistencyException> /
Users/rb/tmp/Test Python Application/main-embedded-
interpreter.m:57 pyobjc_main() PyRun_SimpleFile failed 
with file '/Users/rb/tmp/Test Python Application.app/
Contents/Resources/__main__.py'.  See console for errors.
Trace/BPT trap

I see that "_objc.so" has not been copied to the deployed 
application by the build script.  I also tried using 
bundlebuilder.py and see that it does something quite 
different.

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

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

[Pyobjc-dev] Crasher followup

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

Yes -- works perfectly against latest CVS.  Thanks.

 >>> from Foundation import *
 >>> x = NSFileManager.defaultManager()
 >>> y = x.fileAttributesAtPath_traverseLink_("/", 0)
 >>> y.allKeys()
(\n    NSFileCreationDate, \n    NSFileSize, \n    
NSFileOwnerAccountName, \n    NSFileOwnerAccountID, \n    
NSFileGroupOwnerAccountName, \n    NSFileType, \n    
NSFileGroupOwnerAccountID, \n    NSFileExtensionHidden, \n    
NSFileModificationDate, \n    NSFileSystemFileNumber, \n    
NSFilePosixPermissions, \n    NSFileSystemNumber, \n    
NSFileReferenceCount\n)

Re: [Pyobjc-dev] Odd crasher.

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

I cannot reproduce this crash with the latest CVS version.

Ronald

[Pyobjc-dev] Odd crasher.

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

(I'll try to look into this later)

[il0504a-dhcp25:~] bbum% python
Python 2.3 (#1, Sep 13 2003, 00:49:11)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> from Foundation import *
 >>> d = NSFileManager.defaultManager()
 >>> x = d.fileAttributesAtPath_traverseLink_("/", 0)
 >>> x
<NSFileAttributes objective-c instance 0x3a6360>
 >>> x.allKeys()
<NSCFArray objective-c instance 0x315900>
Segmentation fault

[Pyobjc-dev] Announce: OSCON 2004 (Python 12) call for participation - proposal deadline February 9th!

[Kevin A. <al...@se...>]

I realize many of you will have already seen this announcement on c.l.py,
but the deadline is fast approaching and I would like to get some proposals
this year that highlight Python on the Mac. If you have questions, respond
directly to me, there is no need to post back to the list.

ka
---
Kevin Altis
al...@se...
------------------------------------------------------------


2004 O'Reilly Open Source Convention Call for Participation:
Opening the Future: Discover, Develop, Deliver
http://conferences.oreillynet.com/os2004/

The O'Reilly Open Source Convention (OSCON) will be held July 26-30, 2004 at
the Portland Marriott Downtown in Portland, OR.

Proposals Submission Information--Deadline: February 9, 2004
http://conferences.oreillynet.com/cs/os2004/create/e_sess



Sebastopol, CA--"There is an upheaval in the open source landscape,
particularly Linux, and the corporate landscape is changing too," observes
Tim O'Reilly, founder and CEO of O'Reilly & Associates. Economic pressures
and legal battles have combined to push open source topics to the front
burner as companies, institutions, and governments of every size make
technology decisions. O'Reilly, long a vocal open source advocate, brings
together open source influencers, early adopters, technology activists,
developers, and business leaders to evaluate and debate the evolving open
source landscape at OSCON, the annual O'Reilly Open Source Convention.

The 2004 O'Reilly Open Source Convention, to be held in Portland, OR from
July 26-30, is now accepting proposals delving into topics that matter most
to the entire open source community, which includes new--and perhaps
unexpected--players. "OSCON provides an analysis of what's happening now and
what may come--what will affect the future landscape. This convention brings
together projects in a way that other conferences don't. We're able to cover
a broad range of topics in a deep, coherent way," says OSCON program chair
Nathan Torkington. "It's not just about trimming costs at large companies,
it's about collaborating and innovating our way into the next big thing.
This convention is like a radar. It's a mix of what you'll be doing as soon
as you get back to your desk and what you'll be doing differently in six
months."

The keynote speakers for the next OSCON exemplify the event's wide-ranging
mix: Freeman, George, and Esther Dyson, presenting a joint keynote address;
Robert Lefkowitz, who was one of OSCON 2003's most thought-provoking
speakers; Milton Ngan of Weta Digital, the company that created the digital
effects for "The Lord of the Rings" films; and Tim O'Reilly. Other
influential open source leaders will come to OSCON to accept the first Open
Source Awards, produced by the Open Source Institute (OSI) and ZDNet
(winners will be announced in stages during the winter and spring of 2004).

Proposals Submission Information--Deadline: February 9, 2004
  http://conferences.oreillynet.com/cs/os2004/create/e_sess

Individuals and companies interested in making session or tutorial
presentations, or participating in panel discussions, are invited to submit
proposals. Presentations by marketing staff or with a marketing focus will
not be accepted; neither will submissions made by anyone other than the
proposed speaker. Session presentations are 45 or 90 minutes long, and
tutorials are either a half-day (three hours) or a full day (six hours).

The theme for OSCON 2004 is "Opening the Future: Discover, Develop,
Deliver." Proposals for sessions that help attendees discover new open
source projects, develop new relationships, or deliver value to their
employers and coworkers are especially welcome. Proposals that are not
related to the theme are also encouraged, such as case studies showing how
open source software solved thorny problems or replaced expensive closed
source software, best practices for a tool or system, new features or
modules, and fundamental skills.

The tracks and conferences running in parallel at the convention include:

Linux
- Management, security, administration, configuration
- Desktop, server farm, back office, personal productivity tools,
development

PHP Conference 4
- Unix, Windows, Apache, and beyond
- New developments, security, case studies, large-scale applications
development,
best practices

The Python 12 Conference
- Python and Zope
- Using the latest modules, software engineering, case studies

Perl Conference 8
- Perl 5, Perl 6, Parrot, mod_perl
- Useful modules, software development tips, developing for Parrot and Perl
6

MySQL and PostgreSQL
- Configuration, migration, data warehousing, tuning
- Clustering and replication, fallover, backups
- Efficient client-side processing and query design

Apache httpd, Java, and XML projects
- Apache web server: 2.0, modules, configuration, performance tuning,
security
- Apache XML projects: Xerces, Xalan, Cocoon, FOP, SOAP, XML-RPC, XML
Security
- Apache and Open Source Java projects: Jakarta, Jserv, Avalon, Geronimo

XML
- XML Schemas, Transformations, Software, Services, and Standards
- New standards, best practices, web services, IP issues around standards
and schemas

Applications
- System administration tools, servers, back office utilities
- GUI systems, user applications, productivity tools

Ruby
- Introductions to aspects of Ruby for people unfamiliar with the language
- Power user talks for experienced Ruby programmers

OSCON is the one place open source practitioners of every stripe can gather
to learn useful skills, discover what's new, and "cross-fertilize" projects.
Concludes Tim O'Reilly, "OSCON is for anyone interested in open source. It's
the one event that brings together leaders of all the major open source
projects not only with the hacker community but also with commercial
software developers, business leaders, analysts, and even opponents of open
source."

[Pyobjc-dev] beginSheetModalForWindow_modalDelegate_didEndSelector_contextInfo_ problem

[Mathieu L. <ze...@ne...>]

i've got some trouble with alert sheet.
here is my code :

     def foo_(self,alert,code,context):
         print "bar"

     def boxDelete_(self,sender):
         alert = NSAlert.alloc().init()
         alert.addButtonWithTitle_("OK")
         alert.addButtonWithTitle_("Cancel")
         alert.setMessageText_("Delete")
         alert.setInformativeText_("wanna delete?")
         alert.setAlertStyle_(NSWarningAlertStyle)
         #q = alert.runModal()
         s = AppHelper.endSheetMethod(self.popo_)
          
alert.beginSheetModalForWindow_modalDelegate_didEndSelector_contextInfo_ 
(self.window(),self,s,0)

And here is my error :
alert.beginSheetModalForWindow_modalDelegate_didEndSelector_contextInfo_ 
(self.window(),self,s,0)
TypeError: Need 6 arguments, got 4

in the official documentation for  
beginSheetModalForWindow:modalDelegate:didEndSelector:contextInfo: at
http://developer.apple.com/documentation/Cocoa/Conceptual/Sheets/Tasks/ 
UsingAlertSheets.html#//apple_ref/doc/uid/20001045/BABFIBIA , there is  
only 4 arguments?

it was working (a bit) with pyobjc from the 1.0 dmg, but with the CVS  
version, there is this 6 arguments error.

Where is the mistake?

M.

[Pyobjc-dev] Re: debugging pyobjc

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

Ronald Oussoren <ous...@ci...> writes:

> On 22 jan 2004, at 17:21, Michael Hudson wrote:
>
>> Michael Hudson <mw...@py...> writes:
>>
>>> I'm vaguely trying to track down a bug in recent versions of pygame on
>>> MacOS X, which now uses PyObjC.  So, after much wailing and gnashing
>>> of teeth (see pythonmac-sig) I have a debugging framework install of
>>> Python, and seem to have built pyobjc against it.
>>>
>>> 1) PyObjC's setup.py seems to unconditionally pass -O3 to the
>>>    compiler.  This is, um, contrary to the spirit of a debug build.
>>>    What's wrong with the value of CFLAGS you get by default (from
>>>    $(prefix)/lib/python$(VERSION)/config/Makefile)?
>
> I'll change those, the defaults should be good enough.

Ta.

>>>
>>> 2) Stuff like this isn't encouraging:
>>>

[snippety]

>>>
>>> Am I in new territory here?
>>
>> Actually I'm seeing runPyObjCtests (or whatever that script's called)
>> dump core when run against today's CVS built against a release Python.
>> So I think there may be real problems here.
>
> Do you by any change have a machine without a G4 processor? 

Yes...

> The setup.py also sets some flags for G4 specific compilation. Those
> will also be removed.

Thanks.  I thought I'd hacked them out too, but maybe not.  I did get
some "Illegal Instruction" crashes as well, which was perhaps a
clue...

> I'm currently rebuilding PyObjC to check for problems. One thing you
> might try is removing the existing PyObjC installation before
> installing a new one (if you have one installed). In my quest (sp?)
> for  faster loading times I've moved some of the extensions.

I think I may have made this mistake as well yesterday.

Last night I built a fresh PyObjC and actually used it successfully,
so the problems can't be that severe.  I didn't dare run the tests,
though :-) (I had a bad day wrt computers yesterday).

Cheers,
mwh

-- 
40. There are two ways to write error-free programs; only the third
    one works.
  -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html

Re: [Pyobjc-dev] Re: debugging pyobjc

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

>> Actually I'm seeing runPyObjCtests (or whatever that script's called)
>> dump core when run against today's CVS built against a release Python.
>> So I think there may be real problems here.
>>

The pyobjc repository is affected by the problem described in the SF 
status update titled 'Project CVS Service - 2004-01-22 13:34:40'. 
Basically our CVS repository contains some old files.

I noticed this why trying to update my local tree and have filed a 
support request.

Ronald

Re: [Pyobjc-dev] Re: debugging pyobjc

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

On 22 jan 2004, at 17:21, Michael Hudson wrote:

> Michael Hudson <mw...@py...> writes:
>
>> I'm vaguely trying to track down a bug in recent versions of pygame on
>> MacOS X, which now uses PyObjC.  So, after much wailing and gnashing
>> of teeth (see pythonmac-sig) I have a debugging framework install of
>> Python, and seem to have built pyobjc against it.
>>
>> 1) PyObjC's setup.py seems to unconditionally pass -O3 to the
>>    compiler.  This is, um, contrary to the spirit of a debug build.
>>    What's wrong with the value of CFLAGS you get by default (from
>>    $(prefix)/lib/python$(VERSION)/config/Makefile)?

I'll change those, the defaults should be good enough.

>>
>> 2) Stuff like this isn't encouraging:
>>
>> [mwh@pc150 mwh]$  
>> /Library/Frameworks/DbgPython.framework/Versions/Current/bin/ 
>> python2.3
>> Python 2.3.3 (#1, Jan 22 2004, 14:18:14)
>> [GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>> import Foundation
>> [54592 refs]
>>>>>
>> [54592 refs]
>> Debug memory block at address p=0x44ead0:
>>     40834 bytes originally requested
>>     The 4 pad bytes at p-4 are not all FORBIDDENBYTE (0xfb):
>>         at p-4: 0x00 *** OUCH
>>         at p-3: 0x44 *** OUCH
>>         at p-2: 0x00 *** OUCH
>>         at p-1: 0x01 *** OUCH
>>     Because memory is corrupted at the start, the count of bytes  
>> requested
>>        may be bogus, and checking the trailing pad bytes may segfault.
>>     The 4 pad bytes at tail=0x458a52 are not all FORBIDDENBYTE (0xfb):
>>         at tail+0: 0x00 *** OUCH
>>         at tail+1: 0x20 *** OUCH
>>         at tail+2: 0x7c *** OUCH
>>         at tail+3: 0x08 *** OUCH
>>     The block was made by call #44482497 to debug malloc/realloc.
>>     Data at p: 40 40 3a 40 00 00 00 00 ... 03 a6 bb c1 ff f8 4e 80
>> Fatal Python error: bad leading pad byte
>>
>> Am I in new territory here?
>
> Actually I'm seeing runPyObjCtests (or whatever that script's called)
> dump core when run against today's CVS built against a release Python.
> So I think there may be real problems here.

Do you by any change have a machine without a G4 processor? The  
setup.py also sets some flags for G4 specific compilation. Those will  
also be removed.

I'm currently rebuilding PyObjC to check for problems. One thing you  
might try is removing the existing PyObjC installation before  
installing a new one (if you have one installed). In my quest (sp?) for  
faster loading times I've moved some of the extensions.

Ronald

[Pyobjc-dev] Re: debugging pyobjc

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

Michael Hudson <mw...@py...> writes:

> I'm vaguely trying to track down a bug in recent versions of pygame on
> MacOS X, which now uses PyObjC.  So, after much wailing and gnashing
> of teeth (see pythonmac-sig) I have a debugging framework install of
> Python, and seem to have built pyobjc against it.
>
> 1) PyObjC's setup.py seems to unconditionally pass -O3 to the
>    compiler.  This is, um, contrary to the spirit of a debug build.
>    What's wrong with the value of CFLAGS you get by default (from
>    $(prefix)/lib/python$(VERSION)/config/Makefile)?
>
> 2) Stuff like this isn't encouraging:
>
> [mwh@pc150 mwh]$ /Library/Frameworks/DbgPython.framework/Versions/Current/bin/python2.3 
> Python 2.3.3 (#1, Jan 22 2004, 14:18:14) 
> [GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import Foundation
> [54592 refs]
>>>> 
> [54592 refs]
> Debug memory block at address p=0x44ead0:
>     40834 bytes originally requested
>     The 4 pad bytes at p-4 are not all FORBIDDENBYTE (0xfb):
>         at p-4: 0x00 *** OUCH
>         at p-3: 0x44 *** OUCH
>         at p-2: 0x00 *** OUCH
>         at p-1: 0x01 *** OUCH
>     Because memory is corrupted at the start, the count of bytes requested
>        may be bogus, and checking the trailing pad bytes may segfault.
>     The 4 pad bytes at tail=0x458a52 are not all FORBIDDENBYTE (0xfb):
>         at tail+0: 0x00 *** OUCH
>         at tail+1: 0x20 *** OUCH
>         at tail+2: 0x7c *** OUCH
>         at tail+3: 0x08 *** OUCH
>     The block was made by call #44482497 to debug malloc/realloc.
>     Data at p: 40 40 3a 40 00 00 00 00 ... 03 a6 bb c1 ff f8 4e 80
> Fatal Python error: bad leading pad byte
>
> Am I in new territory here?

Actually I'm seeing runPyObjCtests (or whatever that script's called)
dump core when run against today's CVS built against a release Python.
So I think there may be real problems here.

Cheers,
mwh

-- 
  Enlightenment is probably antithetical to impatience.
                                        -- Erik Naggum, comp.lang.lisp

[Pyobjc-dev] debugging pyobjc

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

I'm vaguely trying to track down a bug in recent versions of pygame on
MacOS X, which now uses PyObjC.  So, after much wailing and gnashing
of teeth (see pythonmac-sig) I have a debugging framework install of
Python, and seem to have built pyobjc against it.

1) PyObjC's setup.py seems to unconditionally pass -O3 to the
   compiler.  This is, um, contrary to the spirit of a debug build.
   What's wrong with the value of CFLAGS you get by default (from
   $(prefix)/lib/python$(VERSION)/config/Makefile)?

2) Stuff like this isn't encouraging:

[mwh@pc150 mwh]$ /Library/Frameworks/DbgPython.framework/Versions/Current/bin/python2.3 
Python 2.3.3 (#1, Jan 22 2004, 14:18:14) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import Foundation
[54592 refs]
>>> 
[54592 refs]
Debug memory block at address p=0x44ead0:
    40834 bytes originally requested
    The 4 pad bytes at p-4 are not all FORBIDDENBYTE (0xfb):
        at p-4: 0x00 *** OUCH
        at p-3: 0x44 *** OUCH
        at p-2: 0x00 *** OUCH
        at p-1: 0x01 *** OUCH
    Because memory is corrupted at the start, the count of bytes requested
       may be bogus, and checking the trailing pad bytes may segfault.
    The 4 pad bytes at tail=0x458a52 are not all FORBIDDENBYTE (0xfb):
        at tail+0: 0x00 *** OUCH
        at tail+1: 0x20 *** OUCH
        at tail+2: 0x7c *** OUCH
        at tail+3: 0x08 *** OUCH
    The block was made by call #44482497 to debug malloc/realloc.
    Data at p: 40 40 3a 40 00 00 00 00 ... 03 a6 bb c1 ff f8 4e 80
Fatal Python error: bad leading pad byte

Am I in new territory here?

Cheers,
mwh

-- 
   This proposal, if accepted, will probably mean a heck of a lot of
   work for somebody.  But since I don't want it accepted, I don't
   care.                                   -- Laura Creighton, PEP 666

[Pyobjc-dev] NSBundle doesn't set attributes with loadNibNamed_owner_

[Frederik De B. <fre...@pa...>]

Hi,

I wanted to add some additional options to the save panel in PyObjC. I 
discovered that I should use  setAccessoryView_ on a NSSavePanel. The 
TextEdit sources show how to do that: you load an NSBundle, and then 
set a certain box to the accessorryView of the save panel. The file's 
owner of the NIB is changed to my own subclass of NSDocument, and I 
added two additionational outlets: pageCount (an NSTextField) and 
pageCountAccessory (an NSBox).

The problem I have is that NSBundle.loadNibNamed_owner_ doesn't seem to 
set the attributes I defined on the file's owner ("self"). Therefore, 
I'm not able to access any of the outlets.

Here's the code. Python gives an error the moment I try to access 
self.pageCount ("object has no attribute pageCount")

     def saveMultipleDocumentsAsPDF_(self):
		savePanel = NSSavePanel.savePanel()
		if not NSBundle.loadNibNamed_owner_("PageCounterAccessory", self):
			NSLog("Error -- could not load PageCounterAccessory.")
		self.pageCount.setIntValue_(1)
		savePanel.setAccessoryView_(self.pageCountAccessory)

Any help on how this problem might be solved is appreciated.

Regards,

Frederik De Bleser
<fre...@pa...>

[Pyobjc-dev] Re: depythonify_c_value rejects non-ascii, non-unicode strings

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

Ronald Oussoren <ous...@ci...> writes:

> On 21 jan 2004, at 20:38, Marc-Antoine Parent wrote:
>
>>>> Too bad that sitecustomize.py cannot in the same directory as a
>>>> script (dirname(sys.argv[0] is added after site.py
>>>> finishes). BTW. does anyone know why sys.setdefaultencoding is
>>>> removed in site.py? E.g. why is it good that users cannot change
>>>> the default encoding after the interpreter has initialized?
>>>
>>> sys.setdefaultencoding is probably removed in site.py for the same
>>> reason you don't like global switches.. someone could
>>> sys.setdefaultencoding in a module that you use, for example.
>>
>> The fact that setdefaultencoding can only be set at startup is a
>> major limitation, and the reason that I argue for a separate value
>> in the bridge.
>>
>
> And the fact that setdefaultencoding exists and is removed early
> during startup is an important reason for not adding a simular
> function to PyObjC.
>
> If you really want to change the encoding after startup you should
> probably file a bugreport for Python, or ask around on
> comp.lang.python.

Or not.  Asking on comp.lang.python will perhaps lead to more
enlightenment; filing a bug report will get it closed.

Cheers,
mwh
(confused about the question but sure about the answer :-)

-- 
  If design space weren't so vast, and the good solutions so small a
  portion of it, programming would be a lot easier.
                                            -- maney, comp.lang.python

Re: [Pyobjc-dev] depythonify_c_value rejects non-ascii, non-unicode strings

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

>>> BTW. If you build .app bundles you can completely replace the 
>>> site.py inside your application
>>
>> Ah? How, out of curiosity?
>
> http://pythonmac.org/wiki/BundleBuilder
>
> The bootstrap script sets your PYTHONPATH to the Resources folder, so 
> you can put a sitecustomize.py there and it will just work

OK, I did not realize this. I had tried in one case, but the Python had 
been segregated in a subfolder, so it failed for me. I should have 
tried harder.
Thanks

Re: [Pyobjc-dev] depythonify_c_value rejects non-ascii, non-unicode strings

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

On Jan 21, 2004, at 3:17 PM, Marc-Antoine Parent wrote:

>> I think I understand your problem now, you have a console program=20
>> that is interacting with a GUI application  via a pipe.  This GUI=20
>> application is trying to display the output of your program, but=20
>> since it does not know the encoding of your text it is passing on=20
>> NSString and crossing its fingers.
>
> That is indeed my case.
> I was trying to make a more general argument, about third-party=20
> non-unicode libraries in general, but I will admit it is theoretical.=20=

> I still feel that the fact that there is a single point of conversion=20=

> in the PyObjC bridge makes it a very practical point of control. But I=20=

> will now try to restrain myself to my current problem.

Encodings are serialization formats, beyond that you need to be using=20
unicode.  This is by far one of the worst things about Python: we have=20=

this AWESOME unicode support, but we forget to use it most of the time=20=

because it requires us to put a u in front of our text.  Hopefully=20
someday, Python str will be crippled to the point where nobody will=20
want to use it for anything but raw data.

>>  The correct solution is, of course, to fix the GUI application; the=20=

>> way it is handling text is broken.
>>
>> Solution:
>> Possibly use a configuration panel for the GUI to choose the encoding=20=

>> of incoming pipes
>> Use codecs.getreader(your_encoding) on the pipe, and use that to=20
>> create NSStrings....
>
> Yes, in this case, we can ask Glen about it (I have) and/or do the=20
> change (I may.)
> If the application were closed source, I would be in more trouble.=20
> Hence my request.

The truth of the matter is that the application is broken, whether it's=20=

open source or closed.

<offtopic>
Because it's open source, and you're a developer, you have this=20
wonderful i-can-fix-it-if-i-have-to power over your software.  That's=20
what I really like about open source.  I don't particularly care for=20
the rest of it (especially annoyances like the GPL and even LGPL).  If=20=

everyone just used Python/BSD/MIT-style licenses, then we could all=20
share code and not have to hire a lawyer to see if we can reuse=20
something in another open source project with a different license.
</offtopic>

> Le 04-01-21, =E0 14:57, Ronald Oussoren a =E9crit :
>
>>> The fact that setdefaultencoding can only be set at startup is a=20
>>> major limitation, and the reason that I argue for a separate value=20=

>>> in the bridge.
>>
>> And the fact that setdefaultencoding exists and is removed early=20
>> during startup is an important reason for not adding a simular=20
>> function to PyObjC.
>
> I am arguing it is not similar, as it controls a single point of=20
> conversion (communication with the Cocoa code) as opposed to Python=20
> behaviour as a whole.
> I assume it makes sense, in that (in my limited experience) the Cocoa=20=

> interface is mostly used to talk with the UI, which is a well-defined=20=

> subset of the API.
> Though I admit that this would also affect other parts of the Cocoa=20
> bridge, if used, which is as bad as changing Python as a whole.
>
>> If you really want to change the encoding after startup you should=20
>> probably file a bugreport for Python, or ask around on=20
>> comp.lang.python.
>
> Fair, but I still think that my case is slightly different.
>
>> BTW. If you build .app bundles you can completely replace the site.py=20=

>> inside your application
>
> Ah? How, out of curiosity?

http://pythonmac.org/wiki/BundleBuilder

The bootstrap script sets your PYTHONPATH to the Resources folder, so=20
you can put a sitecustomize.py there and it will just work

-bob

Re: [Pyobjc-dev] depythonify_c_value rejects non-ascii, non-unicode strings

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

> I think I understand your problem now, you have a console program that=20=

> is interacting with a GUI application  via a pipe.  This GUI=20
> application is trying to display the output of your program, but since=20=

> it does not know the encoding of your text it is passing on NSString=20=

> and crossing its fingers.

That is indeed my case.
I was trying to make a more general argument, about third-party=20
non-unicode libraries in general, but I will admit it is theoretical. I=20=

still feel that the fact that there is a single point of conversion in=20=

the PyObjC bridge makes it a very practical point of control. But I=20
will now try to restrain myself to my current problem.

>  The correct solution is, of course, to fix the GUI application; the=20=

> way it is handling text is broken.
>
> Solution:
> Possibly use a configuration panel for the GUI to choose the encoding=20=

> of incoming pipes
> Use codecs.getreader(your_encoding) on the pipe, and use that to=20
> create NSStrings....

Yes, in this case, we can ask Glen about it (I have) and/or do the=20
change (I may.)
If the application were closed source, I would be in more trouble.=20
Hence my request.

Le 04-01-21, =E0 14:57, Ronald Oussoren a =E9crit :

>> The fact that setdefaultencoding can only be set at startup is a=20
>> major limitation, and the reason that I argue for a separate value in=20=

>> the bridge.
>
> And the fact that setdefaultencoding exists and is removed early=20
> during startup is an important reason for not adding a simular=20
> function to PyObjC.

I am arguing it is not similar, as it controls a single point of=20
conversion (communication with the Cocoa code) as opposed to Python=20
behaviour as a whole.
I assume it makes sense, in that (in my limited experience) the Cocoa=20
interface is mostly used to talk with the UI, which is a well-defined=20
subset of the API.
Though I admit that this would also affect other parts of the Cocoa=20
bridge, if used, which is as bad as changing Python as a whole.

> If you really want to change the encoding after startup you should=20
> probably file a bugreport for Python, or ask around on=20
> comp.lang.python.

Fair, but I still think that my case is slightly different.

> BTW. If you build .app bundles you can completely replace the site.py=20=

> inside your application

Ah? How, out of curiosity?

Marc-Antoine

Re: [Pyobjc-dev] depythonify_c_value rejects non-ascii, non-unicode strings

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

On 21 jan 2004, at 20:38, Marc-Antoine Parent wrote:

>>> Too bad that sitecustomize.py cannot in the same directory as a 
>>> script (dirname(sys.argv[0] is added after site.py finishes). BTW. 
>>> does anyone know why sys.setdefaultencoding is removed in site.py? 
>>> E.g. why is it good that users cannot change the default encoding 
>>> after the interpreter has initialized?
>>
>> sys.setdefaultencoding is probably removed in site.py for the same 
>> reason you don't like global switches.. someone could 
>> sys.setdefaultencoding in a module that you use, for example.
>
> The fact that setdefaultencoding can only be set at startup is a major 
> limitation, and the reason that I argue for a separate value in the 
> bridge.
>

And the fact that setdefaultencoding exists and is removed early during 
startup is an important reason for not adding a simular function to 
PyObjC.

If you really want to change the encoding after startup you should 
probably file a bugreport for Python, or ask around on 
comp.lang.python.

BTW. If you build .app bundles you can completely replace the site.py 
inside your application

Ronald

Re: [Pyobjc-dev] depythonify_c_value rejects non-ascii, non-unicode strings

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

On Jan 21, 2004, at 2:27 PM, Marc-Antoine Parent wrote:

>>> That sentence agrees with my point the second time: What if I _do_=20=

>>> know the encoding, and I want to tell the bridge about it?
>>> Your point is that I should convert strings to unicode before the=20
>>> bridge; my point is that I may be calling the bridge in quite a few=20=

>>> places, and converting there may not be practical.
>>> Whereas if the bridge had a simple API, viz.
>>> PyObjC.setStringEncoding(str)
>>> PyObjC.getStringEncoding()
>>> getting and setting a variable which defaults to the system's=20
>>> default encoding,
>>> then it would be easy to still use (single-byte) strings in Python=20=

>>> if so desired (again, do realize that one is often dealing with=20
>>> someone else's code, and reengineering it is not always practical.)
>>
>> The problem with this proposal is that you want a function to change=20=

>> the encoding related to *your* code, the proposed API changes the=20
>> encoding for *all* code that uses the bridge.
>
> Do you mean that this global would be shared by two different python=20=

> programs using the bridge? (i.e. in different processes...)
> That would be indeed very dangerous and fully justify your reluctance.=20=

> Otherwise, see my point in another post about uniqueness of GUI.
>
>>  If you had control over all of the code then it would be fine, but=20=

>> in that case you would also be able to just change Python's default=20=

>> encoding.
>
> Remember that I cannot do it after startup,
>
>>>> If you want/need to exchange arbitrary data you're going to have to=20=

>>>> explicitly put it in NSData.
>>>
>>> That would be valid for arbitrary data; but strings of a _known_=20
>>> encoding are not arbitrary data.
>>
>> Yeah they are, they're arbitrary data until they're combined with the=20=

>> encoding metadata -- which is the unicode type.
>
> My point was to allow for more than one way to combine them. Unicode=20=

> is one solution, and my favoured solution in most cases, but not=20
> always the best solution, and sometimes not practically available.

I think I understand your problem now, you have a console program that=20=

is interacting with a GUI application  via a pipe.  This GUI=20
application is trying to display the output of your program, but since=20=

it does not know the encoding of your text it is passing on NSString=20
and crossing its fingers.  The correct solution is, of course, to fix=20
the GUI application; the way it is handling text is broken.

Solution:
Possibly use a configuration panel for the GUI to choose the encoding=20
of incoming pipes
Use codecs.getreader(your_encoding) on the pipe, and use that to create=20=

NSStrings.

 >>> import sys
 >>> import codecs
 >>> input =3D codecs.getreader('utf8')(sys.stdin)
 >>> input.readline()
=8E=F0
u'\xe9\uf8ff\n'

-bob

Fwd: [Pyobjc-dev] depythonify_c_value rejects non-ascii, non-unicode strings

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

I just referred to this message, and realized I had not Cc'd it to the=20=

list.

De: Marc-Antoine Parent <map...@ac...>
Date: 21 janvier 2004 12:56:57 GMT-05:00
=C0: Ronald Oussoren <ous...@ci...>
Objet: R=E9p : [Pyobjc-dev] depythonify_c_value rejects non-ascii,=20
non-unicode strings

> I don't like introducing global switches like this, libraries may=20
> modify the switch and change the behaviour of other code.

I agree with you in principle, but I would contend that the case where=20=

two distinct libraries would be using the PyObjC simultaneously should=20=

be comparatively rare. The user should only see one UI, no? (As opposed=20=

to non-UI libraries, which may be many.)
Of course, you may counter me with widget libraries; I would contend=20
that setting the encoding should only be done by the main application,=20=

for obvious reasons.
And a widget library that _needed_ to set that switch for whatever=20
reasons could save the current value in a local variable during its=20
operation, like any well-behaved piece of code.

>> Too bad that sitecustomize.py cannot in the same directory as a=20
>> script (dirname(sys.argv[0] is added after site.py finishes). BTW.=20
>> does anyone know why sys.setdefaultencoding is removed in site.py?=20
>> E.g. why is it good that users cannot change the default encoding=20
>> after the interpreter has initialized?
>
> sys.setdefaultencoding is probably removed in site.py for the same=20
> reason you don't like global switches.. someone could=20
> sys.setdefaultencoding in a module that you use, for example.

The fact that setdefaultencoding can only be set at startup is a major=20=

limitation, and the reason that I argue for a separate value in the=20
bridge.

Marc-Antoine Parent

Re: [Pyobjc-dev] depythonify_c_value rejects non-ascii, non-unicode strings

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

>> That sentence agrees with my point the second time: What if I _do_ 
>> know the encoding, and I want to tell the bridge about it?
>> Your point is that I should convert strings to unicode before the 
>> bridge; my point is that I may be calling the bridge in quite a few 
>> places, and converting there may not be practical.
>> Whereas if the bridge had a simple API, viz.
>> PyObjC.setStringEncoding(str)
>> PyObjC.getStringEncoding()
>> getting and setting a variable which defaults to the system's default 
>> encoding,
>> then it would be easy to still use (single-byte) strings in Python if 
>> so desired (again, do realize that one is often dealing with someone 
>> else's code, and reengineering it is not always practical.)
>
> The problem with this proposal is that you want a function to change 
> the encoding related to *your* code, the proposed API changes the 
> encoding for *all* code that uses the bridge.

Do you mean that this global would be shared by two different python 
programs using the bridge? (i.e. in different processes...)
That would be indeed very dangerous and fully justify your reluctance. 
Otherwise, see my point in another post about uniqueness of GUI.

>  If you had control over all of the code then it would be fine, but in 
> that case you would also be able to just change Python's default 
> encoding.

Remember that I cannot do it after startup,

>>> If you want/need to exchange arbitrary data you're going to have to 
>>> explicitly put it in NSData.
>>
>> That would be valid for arbitrary data; but strings of a _known_ 
>> encoding are not arbitrary data.
>
> Yeah they are, they're arbitrary data until they're combined with the 
> encoding metadata -- which is the unicode type.

My point was to allow for more than one way to combine them. Unicode is 
one solution, and my favoured solution in most cases, but not always 
the best solution, and sometimes not practically available.

> In any case, this really just isn't going to happen.  There's too many 
> extremely good reasons not to do it.

Well, I will stop here, it is clear you do not find my arguments 
compelling, and that is unfortunately that.
We still disagree, but thank you for taking the time to give me your 
reasons.

Regards,

Marc-Antoine Parent

Re: [Pyobjc-dev] depythonify_c_value rejects non-ascii, non-unicode strings

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

On Jan 21, 2004, at 12:57 PM, Glenn Andreas wrote:

> At 12:31 PM -0500 1/21/04, Bob Ippolito wrote:
>> If you want/need to exchange arbitrary data you're going to have to 
>> explicitly put it in NSData.  I would almost vote to *disable* the 
>> str<->NSString bridge in PyObjC, or make it bridge NSData instead, 
>> but that would just be terribly inconvenient for many people.
>
> What about doing both?  If the conversion works, it creates an 
> NSString. This will handle all the current ASCII cases as well as 
> cases where the default encoding is explicitly set (and all the str's 
> are handled accordingly).
>
> If the conversion doesn't work, it creates NSData.  Obviously, this 
> will push the error somewhere else, which may not be able to handle it 
> any better, but at least there is a chance.  (The current problem was 
> doing something like "NSText insertText:", which would then fail with 
> some other error, which might even be more confusing).

Oh god no!  What if you wanted an NSData that happened to not have any 
high bits set?  This sounds more like how I'd imagine unicode support 
to work (or not work) in a Perl ObjC bridge ;)

And yes, at least at this point the error predictably happens exactly 
when you're doing something evil/lazy.

> I suppose a more general solution is to allow for custom conversion 
> handlers that can be installed, but that seems to open another can of 
> worms... (more like a 55 gallon drum)

There are custom conversion handlers, Python's unicode support.  You 
can make file-like-objects that spew unicode and you can convert any 
string of known encoding to a unicode string.  The problem with 
"conversion handlers" is that you don't know where the str came from, 
and without that information you can't register a conversion handler 
that does anything that beyond what sys.defaultencoding can do.

I think that the reason sys.setdefaultencoding is only settable by the 
end user (or any other mechanism for starting the python interpreter) 
is that it's evil for a module to change the system encoding, because 
it can break totally unrelated code, or end user preferences, in a hard 
to debug way.

> Another possibility is to just make the system default encoding be 
> UTF8 instead of ASCII, but I'm guessing if that were a good idea it 
> would have already been done (and would certainly cause other problems 
> with "str is a collection of bytes", "no str is string of characters", 
> "no, it's a desert topping").

setdefaultencoding doesn't ever effect str, it only affects unicode 
(creating unicode and coercing unicode to str).  str is always a 
collection of bytes that happens to be convenient at times to use as a 
collection of characters.  It does, typically, make sense for the 
system default encoding to be UTF8 *on OS X*, but that is a decision 
that effects any Python code and that decision needs to be made by the 
end user (or vendor, I suppose).

-bob

Re: [Pyobjc-dev] depythonify_c_value rejects non-ascii, non-unicode strings

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

On Jan 21, 2004, at 12:50 PM, Marc-Antoine Parent wrote:

>> The simple fact of the matter is that NSString is the equivalent to 
>> python's unicode.  If you unicode('something-with-latin-1') then you 
>> will get an exception.  There is no reason whatsoever to put 
>> arbitrary data in a NSString unless you know its encoding.
>
> That sentence agrees with my point the second time: What if I _do_ 
> know the encoding, and I want to tell the bridge about it?
> Your point is that I should convert strings to unicode before the 
> bridge; my point is that I may be calling the bridge in quite a few 
> places, and converting there may not be practical.
> Whereas if the bridge had a simple API, viz.
> PyObjC.setStringEncoding(str)
> PyObjC.getStringEncoding()
> getting and setting a variable which defaults to the system's default 
> encoding,
> then it would be easy to still use (single-byte) strings in Python if 
> so desired (again, do realize that one is often dealing with someone 
> else's code, and reengineering it is not always practical.)

The problem with this proposal is that you want a function to change 
the encoding related to *your* code, the proposed API changes the 
encoding for *all* code that uses the bridge.  If you had control over 
all of the code then it would be fine, but in that case you would also 
be able to just change Python's default encoding.

>> If you want/need to exchange arbitrary data you're going to have to 
>> explicitly put it in NSData.
>
> That would be valid for arbitrary data; but strings of a _known_ 
> encoding are not arbitrary data.

Yeah they are, they're arbitrary data until they're combined with the 
encoding metadata -- which is the unicode type.

In any case, this really just isn't going to happen.  There's too many 
extremely good reasons not to do it.

-bob

Re: [Pyobjc-dev] depythonify_c_value rejects non-ascii, non-unicode strings

[Glenn A. <gan...@ma...>]

At 12:31 PM -0500 1/21/04, Bob Ippolito wrote:
>If you want/need to exchange arbitrary data you're going to have to 
>explicitly put it in NSData.  I would almost vote to *disable* the 
>str<->NSString bridge in PyObjC, or make it bridge NSData instead, 
>but that would just be terribly inconvenient for many people.

What about doing both?  If the conversion works, it creates an 
NSString. This will handle all the current ASCII cases as well as 
cases where the default encoding is explicitly set (and all the str's 
are handled accordingly).

If the conversion doesn't work, it creates NSData.  Obviously, this 
will push the error somewhere else, which may not be able to handle 
it any better, but at least there is a chance.  (The current problem 
was doing something like "NSText insertText:", which would then fail 
with some other error, which might even be more confusing).

I suppose a more general solution is to allow for custom conversion 
handlers that can be installed, but that seems to open another can of 
worms... (more like a 55 gallon drum)

Another possibility is to just make the system default encoding be 
UTF8 instead of ASCII, but I'm guessing if that were a good idea it 
would have already been done (and would certainly cause other 
problems with "str is a collection of bytes", "no str is string of 
characters", "no, it's a desert topping").


Based on the number of google group hits on "+python 
+setdefaultencodings" these sorts of issues bite those using IDLE, 
etc...

-- 
Glenn Andreas                      gan...@de... 
Theldrow, Blobbo, Cythera, oh my!
Be good, and you will be lonesome