2008FEB101134
Won't work for me at least till py3k and is a good example of Python not leading.
$ cat > foo.py
# -*- coding: utf-8 -*-
# even with the above character encoding
def ô(): return "ô"
$ python foo.py
File "foo.py", line 3
SyntaxError: Non-ASCII character 'xc3' in file foo.py on line 3, but no
encoding declared; see www.python.org/peps/pep-0263.html
Nothing you can do about this at the moment as python up till 2.5 is ascii only for strings [0] unless source code encoding is added. It gets worse. Support for "non ascii identifiers" (shown with the bug above) outlined in PEP 3131 is SF, not SA. [1], [2]
Q Do people use Unicode identifiers in their source code?
Some time later ....
"... Since 'cat > foo.py' erases foo.py, you are obviously lying about that error message. ..."
True this syntax erases the file. But all I did was cut+paste the example from the original source & added the source code encoding on posting. I knew the example code missed the encoding and I checked the example text for extra unicode characters (another possible source of errors) as I saved to the file & checked with cat. So I tried the example on the CLI before I posted and overlooked the redirection. It's not worth lying, way too many sharp people to pick you up. Just a simple display mistake.
Btw, the inference I'm lying. Does that also apply to the original author as well?
"Checking some bash details ..."
Doing a bit of digging. It appears the 'cat > foo.py' works like this ...
"... Redirection of output causes the file whose name results from the expansion of word to be opened for writing on file descriptor n , or the standard output (file descriptor 1) if n is not specified. If the file does not exist it is created; if it does exist it is truncated to zero size. ..." [3]
So my theory is you have tried this with a full file & it has erased itself. Thanks for the pick-up though. It is a fine distinction and something I've not come across before. We are both right but at different times.
Reference
[0] BDFL made this as a design choice to default to ascii.
[1] http://www.python.org/dev/peps/pep-3131/
[2] http://www.python.org/dev/peps/
[3] www.wlug.org.nz/bash(1)Part5
2008FEB101134
Won't work for me at least till py3k and is a good example of Python not leading.
$ cat > foo.py
# -*- coding: utf-8 -*-
# even with the above character encoding
def ô(): return "ô"
$ python foo.py
File "foo.py", line 3
SyntaxError: Non-ASCII character 'xc3' in file foo.py on line 3, but no
encoding declared; see www.python.org/peps/pep-0263.html
Nothing you can do about this at the moment as python up till 2.5 is ascii only for strings [0] unless source code encoding is added. It gets worse. Support for "non ascii identifiers" (shown with the bug above) outlined in PEP 3131 is SF, not SA. [1], [2]
Q Do people use Unicode identifiers in their source code?
Some time later ....
"... Since 'cat > foo.py' erases foo.py, you are obviously lying about that error message. ..."
True this syntax erases the file. But all I did was cut+paste the example from the original source & added the source code encoding on posting. I knew the example code missed the encoding and I checked the example text for extra unicode characters (another possible source of errors) as I saved to the file & checked with cat. So I tried the example on the CLI before I posted and overlooked the redirection. It's not worth lying, way too many sharp people to pick you up. Just a simple display mistake.
Btw, the inference I'm lying. Does that also apply to the original author as well?
"Checking some bash details ..."
Doing a bit of digging. It appears the 'cat > foo.py' works like this ...
"... Redirection of output causes the file whose name results from the expansion of word to be opened for writing on file descriptor n , or the standard output (file descriptor 1) if n is not specified. If the file does not exist it is created; if it does exist it is truncated to zero size. ..." [3]
So my theory is you have tried this with a full file & it has erased itself. Thanks for the pick-up though. It is a fine distinction and something I've not come across before. We are both right but at different times.
Reference
[0] BDFL made this as a design choice to default to ascii.
[1] http://www.python.org/dev/peps/pep-3131/
[2] http://www.python.org/dev/peps/
[3] www.wlug.org.nz/bash(1)Part5