Bgen should generate 7-bit clean code by using hex escapes for non-ascii characters. This should circumvene the problem with MacRoman vs. Latin-1 conversion for files under CVS. The bad news is that this means bgen may need to parse the constant declarations, but maybe we can get away by just escaping all non-ascii chars (as they should only occur within either strings or comments in C header files anyway).

The same probably holds for gensuitemodule.

Logged In: YES 
user_id=21627

Can you give an example of code where it doesn't work
properly in this respect?

Logged In: YES 
user_id=92689

It's not a question of "doesn't work" but more a question of brittleness: 
Mac CVS clients optionally do text file encoding conversion, but this 
means that everyone involved _have_ to use the same settings or things 
go wrong. It helps to keep source files 7-bit clean. Some .py files in the 
Mac subdirectory are currently not 7-bit clean, and some of these are 
generated by bgen. Hence this "bug".

Logged In: YES 
user_id=21627

I think I understand the issue of using 7-bit clean source
code. I'm still trying to understand the bgen issue: why
would it ever produce output that is not 7-bit-clean?
(again, with examples please).

I would assume that the input is already in error, in such a
case.

Logged In: YES 
user_id=92689

*sigh* Do you know what bgen does? It parses C header files. For 
certain constant definitions it translates C to Python in a fairly simplistic 
way. Any 8-bit char in the C source was passed directly to the .py files. 
And yes, some Mac headers contain 8 bit chars in string constants. 
Revision 1.28 of Tools/bgen/bgen/scantools.py,v fixes this. I'll leave the 
bug open until it's more thoroughly tested.

Logged In: YES 
user_id=21627

That is precisely my question. Could you pass a copy of a
file that was used as input to bgen and shows this problem
(if for no other reason than to satisfy my curiosity)?

Logged In: YES 
user_id=45365

The problem is mainly with MacOS "OSType" style values. OSType values are 32 bit longs, but they are customarily encoded as 4-char character constants (a rather obscure feature of C). These OSType values are ubiquitous in MacOS: creator and file type for files ('APPL' is the filetype for an executable, 'Pyth' is the creator code for MacPython), resource types ('DLOG' for dialog resources), AppleEvent/Open Scripting event type and subtype (send 'core'/'odoc' to open a document), etc etc etc.

Example of an OSType value that occur within the Python core is 'GUI' (that's a Sigma there) for a resource that influences the I/O behaviour of the GUSI library. And all code that is generated by gensuitemodule or bgen will also contain lots of them.

Especially the Python code generated is error-prone as it may be used both by MacPython and MachoPython. This isn't true for core usage (which is MacPython-only, as far as I am aware).

Logged In: YES 
user_id=21627

I see, thanks for the explanation. I would still maintain
that it is a bug in the header files, then, since this is
implementation-defined behaviour as well, in C.

Logged In: YES 
user_id=45365

This was fixed by Just in June (scantools.py rev 1.28).