4 ms·
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 charact
by bootload 19y ago
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 http://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?
[0] BDFL made this as a design choice to default to ascii.
[1] http://www.python.org/dev/peps/pep-3131/ http://www.python.org/dev/peps/pep-3131/
[2] http://www.python.org/dev/peps/ http://www.python.org/dev/peps/
- anewaccountname 19y agoSince 'cat > foo.py' erases foo.py, you are obviously lying about that error message.
- bayareaguy 19y agoHmm... I guess that makes me a liar too. powerbook.local 104> cat > foo.py # -*- coding: <utf-8> -*- def ô(): return "ô" powerbook.local 105> python foo.py File "foo.py", line 2 SyntaxError: Non-ASCII character '\xc3' in file foo.py on line 2, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details powerbook.local 106> Now if you actually go look at the web page in the error message, you should notice that the encoding doesn't include the < >. But even when the encoding is set properly python still complains: powerbook.local 106> cat > foo.py # -*- coding: utf-8 -*- def ô(): return "ô" powerbook.local 107> python foo.py File "foo.py", line 2 def ô(): ^ SyntaxError: invalid syntax powerbook.local 108>
- anewaccountname 19y agoAre you sure you don't mean 'cat foo.py' or maybe 'cat - < foo.py'?
- bayareaguy 19y agoYes, I'm sure. cat > foo.py copies standard input into the file foo.py. The rest of the characters you're seeing in the message are what I typed in. The only character you don't see is the Ctrl-D I type to indicate EOF. This is a quick and easy way of creating foo.py without using an editor.
- anewaccountname 19y agoAh, now I see.
- bootload 19y ago"... 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? "... Some time later ..." 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. ..." [0] 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. [0] http://www.wlug.org.nz/bash%281%29Part5 http://www.wlug.org.nz/bash%281%29Part5