myths about python 3

sjdevnull at yahoo.com sjdevnull at yahoo.com
Wed Jan 27 22:14:23 CET 2010


On Jan 27, 9:22 am, Daniel Fetchinson <fetchin... at googlemail.com>
wrote:
> >> Hi folks,
>
> >> I was going to write this post for a while because all sorts of myths
> >> periodically come up on this list about python 3. I don't think the
> >> posters mean to spread false information on purpose, they simply are
> >> not aware of the facts.
>
> >> My list is surely incomplete, please feel free to post your favorite
> >> misconception about python 3 that people periodically state, claim or
> >> ask about.
>
> >> 1. Print statement/function creates incompatibility between 2.x and 3.x!
>
> >> Certainly false or misleading, if one uses 2.6 and 3.x the
> >> incompatibility is not there. Print as a function works in 2.6:
>
> >> Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
> >> [GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
> >> Type "help", "copyright", "credits" or "license" for more information.
> >>>>> print( 'hello' )
> >> hello
> >>>>> print 'hello'
> >> hello
>
> >> 2. Integer division creates incompatibility between 2.x and 3.x!
>
> >> Again false or misleading, because one can get the 3.x behavior with 2.6:
>
> >> Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
> >> [GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
> >> Type "help", "copyright", "credits" or "license" for more information.
> >>>>> 6/5
> >> 1
> >>>>> from __future__ import division
> >>>>> 6/5
> >> 1.2
>
> >> Please feel free to post your favorite false or misleading claim about
> >> python 3!
>
> > Well, I see two false or misleading claims just above - namely that
> > the two claims above are false or misleading. They tell just half of
> > the story, and that half is indeed easy. A Python 3 program can be
> > unchanged (in the case of print) or with only trivial modifications
> > (in the case of integer division) be made to run on Python 2.6.
>
> Okay, so we agree that as long as print and integer division is
> concerned, a program can easily be written that runs on both 2.6 and
> 3.x.
>
> My statements are exactly this, so I don't understand why you disagree.
>
> > The other way around this is _not_ the case.
>
> What do you mean?
>
> > To say that two things are
> > compatible if one can be used for the other, but the other not for the
> > first, is false or misleading.
>
> I'm not sure what you mean here. Maybe I didn't make myself clear
> enough, but what I mean is this: as long as print and integer division
> is concerned, it is trivial to write code that runs on both 2.6 and
> 3.x. Hence if someone wants to highlight incompatibility (which surely
> exists) between 2.6 and 3.x he/she has to look elsewhere.

I think you're misunderstanding what "compatibility" means in a
programming language context.  Python 3 and Python 2 are not mutually
compatible, as arbitrary programs written in one will not run in the
other.  The most important fallout of that is that Python 3 is not
backwards compatible, in that existing Python 2 programs won't run
unaltered in Python 3--while it's easy to write a new program in a
subset of the languages that runs on both Python 2 and 3, the huge
existing codebase of Python 2 code won't run under Python 3.

That there exists an intersection of the two languages that is
compatible with both doesn't make the two languages compatible with
each other--although it being a fairly large subset does help mitigate
a sizable chunk of the problems caused by incompatibility (as do tools
like 2to3).

In your example, a python2 program that uses print and division will
fail in python3.  The print problem is less significant, since the
failure will probably be a syntax error or a rapid exception raised.
The division problem is more problematic, since a program may appear
to run fine but silently misbehave; such errors are much more likely
to result in significant damage to data or other long-term badness.



More information about the Python-list mailing list