"python -3" not working as expected

[Thorsten Kampe]

[Python 2.6.1]

Hi,

to test existing Python code, I ran "python -3" ("warn about Python 3.x
incompatibilities") against a test file that only contains "print
'test'".

Unfortunately I saw no warnings about print becoming a function in
Python 3 ("print()"). Where is the problem?

Thorsten

 

[Marc 'BlackJack' Rintsch]

[Python 2.6.1]

Hi,

to test existing Python code, I ran "python -3" ("warn about Python 3.x
incompatibilities") against a test file that only contains "print
'test'".

Unfortunately I saw no warnings about print becoming a function in
Python 3 ("print()"). Where is the problem?

There is no problem. ``print``\s are handled fine by the 2to3.py
script. The option warns about stuff that is not easily automatically
converted.

Ciao,
Marc 'BlackJack' Rintsch

 

[Steve Holden]

[Python 2.6.1]

Hi,

to test existing Python code, I ran "python -3" ("warn about Python 3.x
incompatibilities") against a test file that only contains "print
'test'".

Unfortunately I saw no warnings about print becoming a function in
Python 3 ("print()"). Where is the problem?

I *believe* that's not flagged because 2to3 will fix it automatically.

regards
Steve

 

[Benjamin Peterson]

I *believe* that's not flagged because 2to3 will fix it automatically.

This is correct; there's not much point to adding py3k warning for things that
2to3 can fix easily.

 

[Thorsten Kampe]

* Marc 'BlackJack' Rintsch (8 Jan 2009 16:26:55 GMT)

[Python 2.6.1]

to test existing Python code, I ran "python -3" ("warn about Python 3.x
incompatibilities") against a test file that only contains "print
'test'".

Unfortunately I saw no warnings about print becoming a function in
Python 3 ("print()"). Where is the problem?

There is no problem. ``print``\s are handled fine by the 2to3.py
script. The option warns about stuff that is not easily automatically
converted.

There /is/ obviously a problem: the Python command line help[1] and the
"Porting To Python 3.0" section of "What’s New In Python 3.0" from Guido
van Rossum are misleading (if not to say wrong):

"""
For porting existing [...] code to Python 3.0, the best strategy is the
following:
[...]
2. [...] Turn on the -3 command line switch. This enables warnings about
features that will be removed (or change) in 3.0.[...]
3. Run the 2to3 source-to-source translator [...]
"""

Thorsten
[1] "-3 : warn about Python 3.x incompatibilities"

 

[Terry Reedy]

* Marc 'BlackJack' Rintsch (8 Jan 2009 16:26:55 GMT)

[Python 2.6.1]

to test existing Python code, I ran "python -3" ("warn about Python 3.x
incompatibilities") against a test file that only contains "print
'test'".

Unfortunately I saw no warnings about print becoming a function in
Python 3 ("print()"). Where is the problem?

There is no problem. ``print``\s are handled fine by the 2to3.py
script. The option warns about stuff that is not easily automatically
converted.

There /is/ obviously a problem: the Python command line help[1] and the
"Porting To Python 3.0" section of "What’s New In Python 3.0" from Guido
van Rossum are misleading (if not to say wrong):

"""
For porting existing [...] code to Python 3.0, the best strategy is the
following:
[...]
2. [...] Turn on the -3 command line switch. This enables warnings about
features that will be removed (or change) in 3.0.[...]
3. Run the 2to3 source-to-source translator [...]
"""

Thorsten
[1] "-3 : warn about Python 3.x incompatibilities"
--

Since you are, I believe, at least the second person to report being bit
by this confusion, please open an issue at bugs.python.org and suggest a
couple of revised sentences that you think are more informative.

 

[Thorsten Kampe]

* Terry Reedy (Thu, 08 Jan 2009 17:04:04 -0500)

* Marc 'BlackJack' Rintsch (8 Jan 2009 16:26:55 GMT)

On Thu, 08 Jan 2009 16:38:53 +0100, Thorsten Kampe wrote:
[Python 2.6.1]

to test existing Python code, I ran "python -3" ("warn about Python 3.x
incompatibilities") against a test file that only contains "print
'test'".

Unfortunately I saw no warnings about print becoming a function in
Python 3 ("print()"). Where is the problem?
There is no problem. ``print``\s are handled fine by the 2to3.py
script. The option warns about stuff that is not easily automatically
converted.

There /is/ obviously a problem: the Python command line help[1] and the
"Porting To Python 3.0" section of "What’s New In Python 3.0" from Guido
van Rossum are misleading (if not to say wrong):

"""
For porting existing [...] code to Python 3.0, the best strategy is the
following:
[...]
2. [...] Turn on the -3 command line switch. This enables warnings about
features that will be removed (or change) in 3.0.[...]
3. Run the 2to3 source-to-source translator [...]
"""

Thorsten
[1] "-3 : warn about Python 3.x incompatibilities"
--

Since you are, I believe, at least the second person to report being bit
by this confusion, please open an issue at bugs.python.org and suggest a
couple of revised sentences that you think are more informative.

Will do tomorrow. The revised sentence could be in the line of "warn
about Python 3.x incompatibilities that cannot trivially be fixed by
2to3.py".

Thorsten

 

[Benjamin]

* Terry Reedy (Thu, 08 Jan 2009 17:04:04 -0500)

Will do tomorrow. The revised sentence could be in the line of "warn
about Python 3.x incompatibilities that cannot trivially be fixed by
2to3.py".

Actually, don't bother now; I've fixed it up in the trunk.

 

[John Machin]

Actually, don't bother now; I've fixed it up in the trunk.

Would you mind giving a pointer to where or what your fix is? The
reason for asking is that Thorsten's suggestion is ambiguous: warn
about some? all? 3.x problems that can't be trivially fixed by 2to3?
Can't be "all"; there are in fact a number of problems that can't be
trivially fixed by 2to3 and can't be detected by running 2.6 with the
-3 option.

These include
(a) problems that cause a reasonably informative exception in 3.x
right at the point where the problem exists
(b) problems where the behaviour has changed but no exception is
raised, and your code lurches off down the wrong path, and you need to
work backwards from subsequent exception(s) and/or failing test case
(s) to pin-point the problem.

I'll use string constants to provide an example of each type. When
faced with "abcd", 2to3 has no way of telling whether that should be
str ("abcd") or bytes (b"abcd"). In the vast majority of cases, to
guess it should be str is correct, so there is no change to the source
file, and a warning would almostly always be noise.

Example of problem (a): chunks is a list of slices of bytes read from
a binary file.
In 2.x you write
glued = ''.join(chunks)
In 3.0 you get this:

chunks = [b'x', b'y']
''.join(chunks)

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: sequence item 0: expected str instance, bytes found

Example of problem (b): some_bytes has been read from a file that was
opened in 'rb' mode and contains the 4 ASCII bytes 'abcd'
# 2.x simulationTrue
# 3.0 simulationFalse # because the types are not comparable for equality.

Another type (b) example is the (majority-guessed) 2to3 change from [c]
StringIO.StringIO to io.StringIO ... if you really should feed some
library an io.BytesIO instance instead, it can travel quite a distance
before blowing up.

Perhaps some of this info could be put into
http://docs.python.org/dev/py3k/whatsnew/3.0.html#porting-to-python-3-0
.... or maybe a separate HOWTO or wiki chapter could be set up for
porting to 3.x, including topics like:
(1) maintaining one set of source files (when you are maintaining a
package that must run on e.g. 2.1 through 3.x)
(2) the possibility of a 3to2 kit for those who have the 2.1 to 3.x
support-range issue but would like to have the one set of source
looking like 3.x code instead of the ugliness of version-conditional
stuff like
BYTES_NULL = bytes(0) # 3.x
or
BYTES_NULL = '' # 2.x
and (3) [getting in early] what about a %to{} kit (or a {}to% kit!)?

Cheers,
John

 

[Benjamin]

Would you mind giving a pointer to where or what your fix is? The
reason for asking is that Thorsten's suggestion is ambiguous: warn
about some? all? 3.x problems that can't be trivially fixed by 2to3?
Can't be "all"; there are in fact a number of problems that can't be
trivially fixed by 2to3 and can't be detected by running 2.6 with the
-3 option.

I added "and cannot by trivially fixed by 2to3".

These include
(a) problems that cause a reasonably informative exception in 3.x
right at the point where the problem exists
(b) problems where the behaviour has changed but no exception is
raised, and your code lurches off down the wrong path, and you need to
work backwards from subsequent exception(s) and/or failing test case
(s) to pin-point the problem.

I'll use string constants to provide an example of each type. When
faced with "abcd", 2to3 has no way of telling whether that should be
str ("abcd") or bytes (b"abcd"). In the vast majority of cases, to
guess it should be str is correct, so there is no change to the source
file, and a warning would  almostly always be noise.

Example of problem (a): chunks is a list of slices of bytes read from
a binary file.
In 2.x you write
glued = ''.join(chunks)
In 3.0 you get this:>>> chunks = [b'x', b'y']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: sequence item 0: expected str instance, bytes found

Example of problem (b): some_bytes has been read from a file that was
opened in 'rb' mode and contains the 4 ASCII bytes 'abcd'
# 2.x simulation>> some_bytes == "abcd"

True
# 3.0 simulation>>> type(some_bytes)

False # because the types are not comparable for equality.

Another type (b) example is the (majority-guessed) 2to3 change from [c]
StringIO.StringIO to io.StringIO ... if you really should feed some
library an io.BytesIO instance instead, it can travel quite a distance
before blowing up.

Yes, bytes/str is an excellent example of where the third part of the
porting helpers. We'll need good documentation. Unfortunately, as you
note below, this isn't exactly the case yet.

Perhaps some of this info could be put intohttp://docs.python.org/dev/py3k/whatsnew/3.0.html#porting-to-python-3-0
... or maybe a separate HOWTO or wiki chapter could be set up for
porting to 3.x, including topics like:
(1) maintaining one set of source files (when you are maintaining a
package that must run on e.g. 2.1 through 3.x)
(2) the possibility of a 3to2 kit for those who have the 2.1 to 3.x
support-range issue but would like to have the one set of source
looking like 3.x code instead of the ugliness of version-conditional
stuff like
BYTES_NULL = bytes(0) # 3.x
or
BYTES_NULL = '' # 2.x
and (3) [getting in early] what about a %to{} kit (or a {}to% kit!)?

Cheers,
John

 

[John Machin]

I added "and cannot by trivially fixed by 2to3".

That's what I was afraid of. Please consider changing it so that it
does not give the impression that together -3 and 2to3 cover all the
bases.

Yes, bytes/str is an excellent example of where the third part of the
porting helpers.

I don't understand that. What is/are "the third part of the porting
helpers"? Are there words missing from the end?

We'll need good documentation. Unfortunately, as you
note below, this isn't exactly the case yet.

So is there a plot to remedy this? Where do we sign up?

Perhaps some of this info could be put intohttp://docs.python.org/dev/py3k/whatsnew/3.0.html#porting-to-python-3-0
... or maybe a separate HOWTO or wiki chapter could be set up for
porting to 3.x, including topics like:
(1) maintaining one set of source files (when you are maintaining a
package that must run on e.g. 2.1 through 3.x)
(2) the possibility of a 3to2 kit for those who have the 2.1 to 3.x
support-range issue but would like to have the one set of source
looking like 3.x code instead of the ugliness of version-conditional
stuff like
BYTES_NULL = bytes(0) # 3.x
or
BYTES_NULL = '' # 2.x
and (3) [getting in early] what about a %to{} kit (or a {}to% kit!)?

 

[Benjamin]

So is there a plot to remedy this? Where do we sign up?

Feel free to contribute to the wiki page: http://wiki.python.org/moin/PortingToPy3k