When run in Python 3 followed script:

print('first')
#coding=iso8859-1
print('second')

it prints the 'first' string twice.

Besides this weird behavior I think PEP-0263 should specify that if a magic comment is second line in the file then first line should be a comment too.

> I think PEP-0263 should specify that if a magic comment is
> second line in the file then first line should be a comment too.

+1

I thought that that was the specification*: the encoding comment should be the first line unless it has to be the second line to allow for an executable comment. Executing a non-comment first line twice is definitely contrary to the intent of the PEP.

* I have not read it recently ;-).

When running that snippet from 3.3.2 Idle editor, 'first' is only printed once. I consider this to be correct and I would not want to change Idle to match the buggy behavior.

On 13.09.2013 19:24, Terry J. Reedy wrote:
> 
> Terry J. Reedy added the comment:
> 
> I thought that that was the specification*: the encoding comment should be the first line unless it has to be the second line to allow for an executable comment. Executing a non-comment first line twice is definitely contrary to the intent of the PEP.
> 
> * I have not read it recently ;-).
> 
> When running that snippet from 3.3.2 Idle editor, 'first' is only printed once. I consider this to be correct and I would not want to change Idle to match the buggy behavior.

Agreed. The PEP never intended to allow executable first lines in
a Python code file.

It also makes non-working a common idiom for running Python files on Windows. When add first line "@python -x", it will be interpreted by Python and will cause SyntaxError.

Here is a patch which fixes this issue (and related issues).

* Encoding declaration now detected in second line only if first line is spaces-only (this is needed for support -x option) or comment-only (needed for she-bang).

* Fixed support for -x option.

* PyTokenizer_FromString() no longer check encoding declaration in second line if it was found in first line.

* Fixed encoding detection in the tokenize module, in IDLE, in 2to3 and in the findnocoding script.

Oh, I had not compiled the code after last change, so first patch is wrong. Here is fixed patch.

Benjamin, current version (without switch) looks more clean to me. Are you insist?

Yeah, I'm okay now.

New changeset 1bdcaf6c0eb5 by Serhiy Storchaka in branch '3.3':
Issue #18960: Fix bugs with Python source code encoding in the second line.
http://hg.python.org/cpython/rev/1bdcaf6c0eb5

New changeset 04c05e408cbd by Serhiy Storchaka in branch 'default':
Issue #18960: Fix bugs with Python source code encoding in the second line.
http://hg.python.org/cpython/rev/04c05e408cbd

Now traceback test is failed.

http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%203.3/builds/1358/steps/test/logs/stdio
======================================================================
FAIL: test_encoded_file (test.test_traceback.SyntaxTracebackCases)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/python/3.3.langa-ubuntu/build/Lib/test/test_traceback.py", line 146, in test_encoded_file
    text, charset, 4)
  File "/opt/python/3.3.langa-ubuntu/build/Lib/test/test_traceback.py", line 129, in do_test
    stdout[1], lineno))
AssertionError: 'line 4' not found in '  File "@test_6376_tmp", line 3, in <module>' : Invalid line number: '  File "@test_6376_tmp", line 3, in <module>' instead of 4

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

New changeset 875a514671dd by Serhiy Storchaka in branch '3.3':
Do not reset the line number because we already set file position to correct
http://hg.python.org/cpython/rev/875a514671dd

New changeset 2af308f79727 by Serhiy Storchaka in branch 'default':
Do not reset the line number because we already set file position to correct
http://hg.python.org/cpython/rev/2af308f79727

New changeset dd1e21f17b1c by Serhiy Storchaka in branch '2.7':
Issue #22221: Backported fixes from Python 3 (issue #18960).
http://hg.python.org/cpython/rev/dd1e21f17b1c