On Mac OS X with python 2.5.1, I get

>>> open(chr(212),'w')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: invalid mode: w

The error should be more like "filename contains nonprintable characters."

Thanks,
Geoffrey

I've tried the example with Python 2.6 + 3.0 on Linux and Windows. No
errors here.

I can confirm on the trunk with Mac OSX 10.4.

It works fine for me on Linux as well, and on FreeBSD.  I expect it's
a mac specific bug.

Geoffrey

On Thu, Feb 21, 2008 at 12:00 PM, Christian Heimes
<report@bugs.python.org> wrote:
> Christian Heimes added the comment:
>
>  I've tried the example with Python 2.6 + 3.0 on Linux and Windows. No
>  errors here.
>
>  ----------
>  nosy: +tiran
>  priority:  -> normal
>
>
>
>  __________________________________
>  Tracker <report@bugs.python.org>
>  <http://bugs.python.org/issue2158>
>  __________________________________
>

The problem appears to be that Mac's strerror doesn't return a good
error message. We could try to detect this sort of thing, but I'm not
sure how.

I cannot reproduce the problem on Intel OSX 10.5.2 (Leopard) with either 
the built-in 2.5.1 or with the MacPython 2.5.1:
$ /usr/bin/python
Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> open(chr(212),'w')
<open file '?', mode 'w' at 0x7b2a8>

However, I can reproduce it on a 10.4.11 system (PPC) with the built-in 
2.3.5 or an earlier MacPython 2.4.4.

Further investigation with a simple C program shows similar behavior.

#include <stdio.h>
#include <fcntl.h>
#include <stdarg.h>
#include <stdlib.h>
#define PMODE 0644

int main(argc, argv)
int argc;
char *argv[];
{
    int f1;
    if ((f1 = creat(argv[1], PMODE))  == -1) {
        printf("can't create %s \n", argv[1]);
        exit(1);
    }
    printf("OK\n");
    exit(0);
}

On the 10.4.11 system, a creat fails with a similar file name:

$ cc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 
5367)
...
$ ./Testtest a
OK
pbg3:~ nad$ ./Testtest $'\xd4'
can't create ? 
pbg3:~ nad$

but on 10.5.2, it works:
$ cc --version
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5465)
...
$ ./Testtest a
OK
fimt:d nad$ ./Testtest $'\xd4'
OK

So perhaps this issue should be closed?

AFAIK this is fixed in the trunk, you'll get a message that the filename 
or mode is incorrect (but not which one).

That's the best open() can do because the underlying C API doesn't give 
enough information to decide which argument is unacceptable.

(I'm changing this to the library component instead of the Macintosh one 
because this was a buglet in the platform-independent stdlib).

The trunk was fixed in r61468, that might be a backport candidate, 
adding gregory.p.smith to the nosy list because he commited that 
revision.

backported r61468 to release25-maint in r62659.