Changes between Version 1 and Version 2 of Python3Issues


Ignore:
Timestamp:
Aug 7, 2009, 2:26:11 PM (10 years ago)
Author:
flip
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Python3Issues

    v1 v2  
    1 = Python 3 Changes Of Which To Be Aware ==
     1= Python 3 Changes Of Which To Be Aware =
    22
    33Python 3 is the first Python release ever which introduced
    44backwards-incompatible changes. There's a pretty complete list of those
    5 changes here:[BR]
     5changes here: 
    66http://docs.python.org/dev/3.0/whatsnew/3.0.html
    77
     
    1111 * The division operator changes.
    1212 
    13    Python 3 concludes a long-standing debate in the Python community by
    14    changing the '/' operator to return a float even if its arguments are int.
    15    In other words, in Python 2, 3/2 == 1. In Python 3, 3/2 == 1.5.
     13 Python 3 concludes a long-standing debate in the Python community by
     14 changing the '/' operator to return a float even if its arguments are int.
     15 In other words, in Python 2, 3/2 == 1. In Python 3, 3/2 == 1.5.
    1616   
    17    We can get "true" division now in Python 2 by adding this at the top of
    18    a file:
    19    
    20    from __future__ import division
     17 We can get "true" division now in Python 2 by adding this at the top of
     18 a file:
     19   `from __future__ import division`
    2120
    22    Here's an example of the difference:
     21 Here's an example of the difference:
     22{{{
     23#!python
    2324    >>> 3/2
    2425    1
     
    2728    1.5
    2829    >>>
    29 
    30    Our code involves lots of math, so this is a potentially big change for
    31    us. However, we're well positioned to handle it if we take action now.
    32    It's pretty simple -- we'll have to retest any modules affected by this
    33    change, and I think that means most of them. We'll have a lot more
    34    modules in the future than we have now, so making this change will
    35    only get more expensive as time goes on.
     30}}}
     31 Our code involves lots of math, so this is a potentially big change for
     32 us. However, we're well positioned to handle it if we take action now.
     33 It's pretty simple -- we'll have to retest any modules affected by this
     34 change, and I think that means most of them. We'll have a lot more
     35 modules in the future than we have now, so making this change will
     36 only get more expensive as time goes on.
    3637   
    37    For that reason, *I recommend
    38    that we immediately begin using "true" division in all our new code, and
    39    that we change our existing code to use "true" division as we get the
    40    opportunity to do so.*
     38 For that reason, '''I recommend
     39 that we immediately begin using "true" division in all our new code, and
     40 that we change our existing code to use "true" division as we get the
     41 opportunity to do so.'''
    4142   
    42    Last but not least, note that in both Python 2 & 3, the // operator always
    43    gives the truncating
    44    behavior. 3//2 == 1  and  11//3 == 3. (Note that the latter doesn't round
    45    up to 4.)
     43 Last but not least, note that in both Python 2 & 3, the // operator always
     44 gives the truncating
     45 behavior. 3//2 == 1  and  11//3 == 3. (Note that the latter doesn't round
     46 up to 4.)
    4647   
    4748
    4849 * The different between Python ints and longs disappears.
    4950 
    50    In Python 2, ints are represented with C longs, so their minimum range
    51    is +/- 2147483647. Python 2 longs are effectively unlimited. (If you create
    52    a number big enough, eventually your computer will run out of memory or
    53    Python will die, but I've created a number with > 78,000 digits and Python
    54    was fine with it.)
     51 In Python 2, ints are represented with C longs, so their minimum range
     52 is +/- 2147483647. Python 2 longs are effectively unlimited. (If you create
     53 a number big enough, eventually your computer will run out of memory or
     54 Python will die, but I've created a number with > 78,000 digits and Python
     55 was fine with it.)
    5556   
    56    In Python 3, longs go away and ints are effectively unlimited.
     57 In Python 3, longs go away and ints are effectively unlimited.
    5758   
    5859
    5960 * Absolute imports become the default.
    6061 
    61    This change will only affect code inside packages, and I debated even
    62    mentioning it here. Suffice it to say that if we need to change our
    63    import statements for Python 3, the changes will be minor,
    64    straightforward, and easy to find (since import statements are almost
    65    always confined to the first pages of modules).
     62 This change will only affect code inside packages, and I debated even
     63 mentioning it here. Suffice it to say that if we need to change our
     64 import statements for Python 3, the changes will be minor,
     65 straightforward, and easy to find (since import statements are almost
     66 always confined to the first pages of modules).
    6667
    6768 * "Everything you thought you knew about binary data and Unicode has
    68     changed."
     69 changed."
    6970   
    70     Fortunately for us we're not manipulating too much text, so the effect
    71     on us will be relatively minor. In addition, there's not much we can
    72     do now to future-proof our code. (It's hard to write code of much
    73     significance that's compatible with both Python 2 & 3.)
     71 Fortunately for us we're not manipulating too much text, so the effect
     72 on us will be relatively minor. In addition, there's not much we can
     73 do now to future-proof our code. (It's hard to write code of much
     74 significance that's compatible with both Python 2 & 3.)
    7475   
    75  * The builtin file() constructor is gone. The Python 2 documentation
    76    says, "When opening a file, it's preferable to use open() instead of
    77    invoking this constructor directly." Despite this, I often used the
    78    file() constructor because it allowed me to read in a file in one line
    79    like so:
    80    s = file("foo.txt", "rb").read()
    81    
     76 * The builtin `file()` constructor is gone. The Python 2 documentation
     77 says, "When opening a file, it's preferable to use open() instead of
     78 invoking this constructor directly." Despite this, I often used the
     79 `file()` constructor because it allowed me to read in a file in one line
     80 like so:
     81   `s = file("foo.txt", "rb").read()`