Python 3000 deat !? Is true division ever coming ?

Discussion in 'Python' started by seb.haase@gmail.com, Feb 13, 2006.

  1. Guest

    Hi,
    Is it true that that "Python 3000" is dead ?
    Honestly I think that e.g. changing 5/2 to be 2.5 (instead of 2) would
    just break to much code :-(
    On the otherhand I'm using Python as "Matlab replacement" and would
    generally like 5/2 ==2.5

    So, I was contemplating to default all my modules/scripts to start with
    "from __future__ import division"
    but if it is never coming (in this decade, that is) then it would be a
    waste of time just confuse everybody !!

    Thanks,
    Sebastian Haase
     
    , Feb 13, 2006
    #1
    1. Advertising

  2. On 12 Feb 2006 21:53:57 -0800, declaimed the
    following in comp.lang.python:

    > Hi,
    > Is it true that that "Python 3000" is dead ?


    No... But you'll have to live another 993 years to see it -- unlike
    M$, it's bound to be early <G>
    --
    > ============================================================== <
    > | Wulfraed Dennis Lee Bieber KD6MOG <
    > | Bestiaria Support Staff <
    > ============================================================== <
    > Home Page: <http://www.dm.net/~wulfraed/> <
    > Overflow Page: <http://wlfraed.home.netcom.com/> <
     
    Dennis Lee Bieber, Feb 13, 2006
    #2
    1. Advertising

  3. Guest

    wrote:
    > Hi,
    > Is it true that that "Python 3000" is dead ?
    > Honestly I think that e.g. changing 5/2 to be 2.5 (instead of 2) would
    > just break to much code :-(
    > On the otherhand I'm using Python as "Matlab replacement" and would
    > generally like 5/2 ==2.5
    >
    >...


    It's Comp. Sci. 101, based on third grade artithmetic, not Python.
    5/2=2 is integer division, that's the way integer arithmetic works.
    5./2.=2.5 is floating point math, with all the round off errors that
    incorporates.

    If Matlab assumes floating point, then that's what you're paying the
    big bucks for.

    Curtis
     
    , Feb 14, 2006
    #3
  4. On 14 Feb 2006 06:44:02 -0800,

    > 5./2.=2.5 is floating point math, with all the round off errors that
    > incorporates.


    Thanks Curtis, I never knew that trick. I guess for variables do have
    true division you have to make them floats? e.g.
    float(var1)/float(var2)? Or do you know a less typing approach for
    that?

    --
    Gregory Piñero
    Chief Innovation Officer
    Blended Technologies
    (www.blendedtechnologies.com)
     
    =?ISO-8859-1?Q?Gregory_Pi=F1ero?=, Feb 14, 2006
    #4
  5. Gregory Piñero wrote:
    > On 14 Feb 2006 06:44:02 -0800,
    >
    >
    >>5./2.=2.5 is floating point math, with all the round off errors that
    >>incorporates.

    >
    > Thanks Curtis, I never knew that trick. I guess for variables do have
    > true division you have to make them floats? e.g.
    > float(var1)/float(var2)? Or do you know a less typing approach for
    > that?


    Google "python true division" -> I'm feeling lucky:

    http://www.python.org/doc/2.2.3/whatsnew/node7.html

    From the web page:

    """
    * By including a from __future__ import division in a module(*), the /
    operator will be changed to return the result of true division, so 1/2
    is 0.5. Without the __future__ statement, / still means classic
    division. The default meaning of / will not change until Python 3.0.
    """

    *As the first non-docstring/non-comment line.

    Note that that's for a module -- the interactive interpreter won't
    respond the same way to the "from __future__ import" statement.
     
    Rocco Moretti, Feb 14, 2006
    #5
  6. I knew about that approach. I just wanted less typing :-(


    On 2/14/06, Rocco Moretti <> wrote:
    > Gregory Piñero wrote:
    > > On 14 Feb 2006 06:44:02 -0800,
    > >
    > >
    > >>5./2.=2.5 is floating point math, with all the round off errors that
    > >>incorporates.

    > >
    > > Thanks Curtis, I never knew that trick. I guess for variables do have
    > > true division you have to make them floats? e.g.
    > > float(var1)/float(var2)? Or do you know a less typing approach for
    > > that?

    >
    > Google "python true division" -> I'm feeling lucky:
    >
    > http://www.python.org/doc/2.2.3/whatsnew/node7.html
    >
    > From the web page:
    >
    > """
    > * By including a from __future__ import division in a module(*), the /
    > operator will be changed to return the result of true division, so 1/2
    > is 0.5. Without the __future__ statement, / still means classic
    > division. The default meaning of / will not change until Python 3.0.
    > """
    >
    > *As the first non-docstring/non-comment line.
    >
    > Note that that's for a module -- the interactive interpreter won't
    > respond the same way to the "from __future__ import" statement.
    > --
    > http://mail.python.org/mailman/listinfo/python-list
    >



    --
    Gregory Piñero
    Chief Innovation Officer
    Blended Technologies
    (www.blendedtechnologies.com)
     
    =?ISO-8859-1?Q?Gregory_Pi=F1ero?=, Feb 14, 2006
    #6
  7. Guest

    Thanks for the replies,
    But to point out what the subject of this thread is (sorry for the typo
    ;-) :
    There is a PEP (proposal 238) to change Python so that
    5/2 WOULD do the true division -- and obviously break lots of code.

    Just type this in your python interpeter:
    >>> from __future__ import division
    >>> 5/2

    2.5

    I'm not asking why it _doen't_ work like Matlab.
    I'm wondering what the chances are that what Rocco Moretti is
    referring to
    (http://www.python.org/doc/2.2.3/whatsnew/node7.html)
    is really planned to be persued...

    I don't think "Because this change might break code, it's being
    introduced very gradually. Python 2.2 begins the transition, but the
    switch won't be complete until Python 3.0." says enough.

    Should I start using
    "from __future__ import division" in my modules ?
    I fear that it might make my code "unreadable" (people would not expect
    this when reading somewhere in the middle of the module !!!)

    Thanks,
    Sebastian Haase
     
    , Feb 17, 2006
    #7
  8. Magnus Lycka Guest

    Gregory Piñero wrote:
    > I knew about that approach. I just wanted less typing :-(


    It's enough to introduce one float in the mix.
    1.*a/b or float(a)/b if you don't want one more
    multiplication.
     
    Magnus Lycka, Feb 17, 2006
    #8
  9. On Thu, 16 Feb 2006 20:55:42 -0800, seb.haase wrote:

    > I don't think "Because this change might break code, it's being
    > introduced very gradually. Python 2.2 begins the transition, but the
    > switch won't be complete until Python 3.0." says enough.


    I'm not sure what else should be said.

    > Should I start using
    > "from __future__ import division" in my modules ?


    I don't know. Do you use integer or floating point division? Do you like
    writing float(x)/y instead of just x/y?

    > I fear that it might make my code "unreadable" (people would not expect
    > this when reading somewhere in the middle of the module !!!)


    Anybody using Python *should* be aware of the division issue. As soon as
    they see a division, it is their responsibility to *find out what it
    means*. That doesn't require much work: they can scroll up to the
    beginning of the module and look at the first few lines. That's not hard.

    Anybody person who is unwilling to scroll to the start of the module or
    use their text editor to search for "from __future__ import division"
    shouldn't be programming.

    I'll allow for the occasional newbie who somehow has missed out on
    learning about true division, but that's no reason to not implement
    features in the language. The cost of confusing a newbie once in a month
    of Sundays is far less than the benefit of introducing true division.


    --
    Steven.
     
    Steven D'Aprano, Feb 17, 2006
    #9
  10. Magnus Lycka Guest

    wrote:
    > Hi,
    > Is it true that that "Python 3000" is dead ?


    I think you should view Python 3000 as a metaphor for
    "Python as it would look if we didn't have to care about
    backward compatibility".

    Before this name appeared, Guido used to talk about
    Python 3.0 as a version where bad things in Python could
    go away, but it seems many people got worried about that,
    assuming that Python 3.0 would happen soon and cause a lot
    of changes in already written code. Thus the less scary
    label Python 3000. There has never been any concrete plans
    as far as I know to actually release a real software product
    called Python 3000. It's rather a long term design target
    for Python.

    A lot of these language changes can be introduced step
    be step. A new feature can be introduced first as an
    experimental feature, accessible via "from __future__
    import XYZ", in the next minor release, it might be
    enabled by default. If a feature or module is going away,
    the first step is to document it as deprecated. The next
    minor release will issue a PendingDeprecationWarning, and
    the minor release after that will issue a DeprecationWarning
    and the next minor release (2.4 -> 2.5 etc) will remove
    the feature. This will give developers a period of many
    years to adapt from the time the feature is documented as
    deprecated until maintenace ends for the last Python where
    the deprecated feature works.

    For an example of such a transition plan, see
    http://www.python.org/peps/pep-0352.html

    Changing the behaviour of int/int is worse, since there
    is no obvious way for Python to determine whether the
    programmer expects an int result, a float result or either.
    Also, the typical consequence of this change is not that
    code breaks with a big bang, but rather that it produces
    somewhat different results. That means that a bug due to
    this feature change might go unnoticed for a long time,
    and cause a lot of problems. Imagine some kind of system
    that calculates how much pension you'll get when you
    retire, based on your monthly payments. A bug caused by
    changed division behaviour might have serious consequences.

    It seems reasonable to wait until the next major release,
    3.0, before this feature is introduced. In the mean time
    it seems that the strategy should be to encourage people
    to adopt the new behaviour in all new code, i.e. to use
    "from __future__ import division" and to explicitly use
    interger division a//b when this is needed.

    In the same way, people should be encouraged to always
    use new style classes, "class X(object):" in new code,
    since old style classes are going away, and they behave
    differently in some ways.

    A problem as I see it today, is that this behaviour is
    not actively encouraged. The tutorial, which is maintained
    and updated, still describes old style classes, and the
    old division behaviour.

    http://docs.python.org/dev/tut/node5.html#SECTION005110000000000000000
    http://docs.python.org/dev/tut/node11.html#SECTION0011300000000000000000

    I don't see any reason to use old style classes in new code,
    so I think all "class X:" should be changed to
    "class X(object):", but I can understand that it would be
    confusing to explain the use of "from __future__ import division"
    before we introduce simple arithmetics. Still, we should
    get this message through!

    As it is now, when people aren't actively moving their code
    towards this expected change, the impact of such a change
    would be almost as strong as if this "from __future_..."
    feature didn't exist.

    So, if I finally try to answer your question: Float division
    will hardly be enabled by default until most Python programmers
    have adopted the feature, i.e. enabled it through the
    __future__ switch and started to use // when they want floor
    division.

    This will hardly happen until it's documented as the way people
    should do it. Perhaps a start could be a FutureProofPython page
    in the Python wiki, with suggested coding guidelines.
     
    Magnus Lycka, Feb 17, 2006
    #10
  11. Steven D'Aprano wrote:

    > Anybody using Python *should* be aware of the division issue. As soon as
    > they see a division, it is their responsibility to *find out what it
    > means*. That doesn't require much work: they can scroll up to the
    > beginning of the module and look at the first few lines. That's not hard.


    And anyone wanting strict integer division semantics,(and not needing
    pre-2.2 compatability) should be using the '//' floor division operator
    anyway.
     
    Rocco Moretti, Feb 17, 2006
    #11
  12. Guest

    Thank you very much, Magnus !
    This is the answer I had been waiting for:
    > A problem as I see it today, is that this behaviour is
    > not actively encouraged. The tutorial, which is maintained
    > and updated, still describes old style classes, and the
    > old division behaviour.


    My main point was/is: why is there not more discussion about "true
    division" !!?
    Just like the second answer to my posting clearly showed:
    PEOPLE THINK TRUE DIVISION IS "ONLY IN MATLAB" !!

    As you pointed out: the "true division" part of "Python3000" might be
    one of the "scariest" and should therefore be pointed out already in
    the tutorial !! (It would look quite ugly to newcomers, though)

    Having said that: I would vote against EVER introducing true division
    as default - because it will just PISS too many (long time python)
    people OFF. ;-)

    Thanks,
    Sebastian Haase


    Magnus Lycka wrote:
    > wrote:
    > > Hi,
    > > Is it true that that "Python 3000" is dead ?

    >
    > I think you should view Python 3000 as a metaphor for
    > "Python as it would look if we didn't have to care about
    > backward compatibility".
    >
    > Before this name appeared, Guido used to talk about
    > Python 3.0 as a version where bad things in Python could
    > go away, but it seems many people got worried about that,
    > assuming that Python 3.0 would happen soon and cause a lot
    > of changes in already written code. Thus the less scary
    > label Python 3000. There has never been any concrete plans
    > as far as I know to actually release a real software product
    > called Python 3000. It's rather a long term design target
    > for Python.
    >
    > A lot of these language changes can be introduced step
    > be step. A new feature can be introduced first as an
    > experimental feature, accessible via "from __future__
    > import XYZ", in the next minor release, it might be
    > enabled by default. If a feature or module is going away,
    > the first step is to document it as deprecated. The next
    > minor release will issue a PendingDeprecationWarning, and
    > the minor release after that will issue a DeprecationWarning
    > and the next minor release (2.4 -> 2.5 etc) will remove
    > the feature. This will give developers a period of many
    > years to adapt from the time the feature is documented as
    > deprecated until maintenace ends for the last Python where
    > the deprecated feature works.
    >
    > For an example of such a transition plan, see
    > http://www.python.org/peps/pep-0352.html
    >
    > Changing the behaviour of int/int is worse, since there
    > is no obvious way for Python to determine whether the
    > programmer expects an int result, a float result or either.
    > Also, the typical consequence of this change is not that
    > code breaks with a big bang, but rather that it produces
    > somewhat different results. That means that a bug due to
    > this feature change might go unnoticed for a long time,
    > and cause a lot of problems. Imagine some kind of system
    > that calculates how much pension you'll get when you
    > retire, based on your monthly payments. A bug caused by
    > changed division behaviour might have serious consequences.
    >
    > It seems reasonable to wait until the next major release,
    > 3.0, before this feature is introduced. In the mean time
    > it seems that the strategy should be to encourage people
    > to adopt the new behaviour in all new code, i.e. to use
    > "from __future__ import division" and to explicitly use
    > interger division a//b when this is needed.
    >
    > In the same way, people should be encouraged to always
    > use new style classes, "class X(object):" in new code,
    > since old style classes are going away, and they behave
    > differently in some ways.
    >
    > A problem as I see it today, is that this behaviour is
    > not actively encouraged. The tutorial, which is maintained
    > and updated, still describes old style classes, and the
    > old division behaviour.
    >
    > http://docs.python.org/dev/tut/node5.html#SECTION005110000000000000000
    > http://docs.python.org/dev/tut/node11.html#SECTION0011300000000000000000
    >
    > I don't see any reason to use old style classes in new code,
    > so I think all "class X:" should be changed to
    > "class X(object):", but I can understand that it would be
    > confusing to explain the use of "from __future__ import division"
    > before we introduce simple arithmetics. Still, we should
    > get this message through!
    >
    > As it is now, when people aren't actively moving their code
    > towards this expected change, the impact of such a change
    > would be almost as strong as if this "from __future_..."
    > feature didn't exist.
    >
    > So, if I finally try to answer your question: Float division
    > will hardly be enabled by default until most Python programmers
    > have adopted the feature, i.e. enabled it through the
    > __future__ switch and started to use // when they want floor
    > division.
    >
    > This will hardly happen until it's documented as the way people
    > should do it. Perhaps a start could be a FutureProofPython page
    > in the Python wiki, with suggested coding guidelines.
     
    , Feb 17, 2006
    #12
  13. On Fri, 17 Feb 2006 14:01:05 -0800, seb.haase wrote:

    > Thank you very much, Magnus !
    > This is the answer I had been waiting for:
    >> A problem as I see it today, is that this behaviour is
    >> not actively encouraged. The tutorial, which is maintained
    >> and updated, still describes old style classes, and the
    >> old division behaviour.

    >
    > My main point was/is: why is there not more discussion about "true
    > division" !!?


    What is there to discuss?


    > Just like the second answer to my posting clearly showed:
    > PEOPLE THINK TRUE DIVISION IS "ONLY IN MATLAB" !!


    I've never even used Matlab. But I have a calculator. (Actually I have
    about half a dozen calculators.) In every single one of them, 1/2 gives
    0.5 instead of 0. I'm even capable of doing that calculation in my head.
    So I don't think true division is only in Matlab.


    > As you pointed out: the "true division" part of "Python3000" might be
    > one of the "scariest" and should therefore be pointed out already in
    > the tutorial !! (It would look quite ugly to newcomers, though)


    The tutorial shouldn't talk about Python3000 at all. What would be the
    point of that? The tutorial is there to teach about the way Python works
    now, not to make guesses and prediction about how it will work some time
    in the indefinite future.


    > Having said that: I would vote against EVER introducing true division
    > as default - because it will just PISS too many (long time python)
    > people OFF. ;-)


    Do you realise that the reason true division was introduced into Python
    was because many long-time Python programmers requested it? So far from
    annoying them, it is a feature that most Python programmers are waiting
    for.



    --
    Steven.
     
    Steven D'Aprano, Feb 18, 2006
    #13
  14. Terry Reedy Guest

    <> wrote in message
    news:...
    >> not actively encouraged. The tutorial, which is maintained
    >> and updated, still describes old style classes, and the
    >> old division behaviour.


    Perhaps the tutorials needs updating.

    > My main point was/is: why is there not more discussion about "true
    > division" !!?


    It was discussed to death a few years ago with probably 100s of posts.

    > As you pointed out: the "true division" part of "Python3000" might be
    > one of the "scariest" and should therefore be pointed out already in
    > the tutorial !! (It would look quite ugly to newcomers, though)


    The tutorial should say to use // for int (floor) division. There is
    nothing scary about / or the future change of int/int if you only use / for
    float division.

    > Having said that: I would vote against EVER introducing true division
    > as default - because it will just PISS too many (long time python)
    > people OFF. ;-)


    The decision was made years ago. The rationale is summarized in
    http://www.python.org/peps/pep-0238.html

    In a sense, Python 3.0 is actively under development. New features have,
    are, and will be added to 2.X as they are developed. Currently envisioned
    changes and deletions are listed in
    http://www.python.org/peps/pep-3000.html

    I believe Guido's new job at Google gives him more time to work on Python
    development than previously. So I think we will see 3.0 sooner than might
    have been envisioned just a few months ago.

    Terry J. Reedy
     
    Terry Reedy, Feb 18, 2006
    #14
  15. Dan Bishop Guest

    Magnus Lycka wrote:
    > Gregory Piñero wrote:
    > > I knew about that approach. I just wanted less typing :-(

    >
    > It's enough to introduce one float in the mix.
    > 1.*a/b or float(a)/b if you don't want one more
    > multiplication.


    That doesn't work if either a or b is a Decimal. What *could* work is


    def is_integer(num):
    return isinstance(num, (int, long))

    def divide(a, b):
    if is_integer(a) and is_integer(b):
    return 1.0 * a / b
    else:
    return a / b

    But why bother when you could just put "from __future__ import
    division" at the top of the file?
     
    Dan Bishop, Feb 18, 2006
    #15
  16. Steve Holden Guest

    wrote:
    > Thank you very much, Magnus !
    > This is the answer I had been waiting for:
    >
    >>A problem as I see it today, is that this behaviour is
    >>not actively encouraged. The tutorial, which is maintained
    >>and updated, still describes old style classes, and the
    >>old division behaviour.

    >
    >
    > My main point was/is: why is there not more discussion about "true
    > division" !!?


    You are about three years too late for the discussion. It was debated to
    death when Guido proposed that Python should behave more like
    non-programmers expected it to. Despite some fierce opposition this view
    eventually held sway, and now long-time Pythonistas accept it as the way
    forward.

    So basically most people saw your question and probably thought "enough,
    already!".

    > Just like the second answer to my posting clearly showed:
    > PEOPLE THINK TRUE DIVISION IS "ONLY IN MATLAB" !!
    >
    > As you pointed out: the "true division" part of "Python3000" might be
    > one of the "scariest" and should therefore be pointed out already in
    > the tutorial !! (It would look quite ugly to newcomers, though)
    >
    > Having said that: I would vote against EVER introducing true division
    > as default - because it will just PISS too many (long time python)
    > people OFF. ;-)
    >

    I think you underestimate the power of the Python community to adapt to
    change when it's necessary for the long-term benefit of the language.

    > Thanks,
    > Sebastian Haase
    >

    [...]

    regards
    Steve
    --
    Steve Holden +44 150 684 7255 +1 800 494 3119
    Holden Web LLC www.holdenweb.com
    PyCon TX 2006 www.python.org/pycon/
     
    Steve Holden, Feb 18, 2006
    #16
  17. Magnus Lycka Guest

    Steven D'Aprano wrote:
    > The tutorial shouldn't talk about Python3000 at all. What would be the
    > point of that? The tutorial is there to teach about the way Python works
    > now, not to make guesses and prediction about how it will work some time
    > in the indefinite future.


    There is no guessing involved.

    The new division behaviour was implemented years ago, but to
    avoid breaking old code, it's not enabled by default.

    For new code, you ought to use 'from __future__ import division'
    and use // whenever you want floor division, regardless of
    that numeric types you divide. The ordinary / shouldn't truncate
    fractions.

    The problem is that the tutorial doesn't tell python programmers
    to do this.

    I can understand that there is a pedagogical problem here.

    Division is introduced way earlier than the import statement in
    the tutorial, and the "from __future__" thingie might not be the
    first thing you want to expose for a beginner.
     
    Magnus Lycka, Feb 20, 2006
    #17
  18. Dave Hansen Guest

    Caution: bunny trail ahead. Feel free to skip this message, as it
    contains no useful content whatever...

    On Sat, 18 Feb 2006 12:09:02 +1100 in comp.lang.python, Steven
    D'Aprano <> wrote:

    [...]
    >
    >I've never even used Matlab. But I have a calculator. (Actually I have
    >about half a dozen calculators.) In every single one of them, 1/2 gives
    >0.5 instead of 0. I'm even capable of doing that calculation in my head.
    >So I don't think true division is only in Matlab.


    I have three calculators: an HP-48S, and HP-16C, and NeoCal on my
    Palm.

    On the HP-48S: 1 <Enter> 2 / -> 500.000000000E-3
    On the HP-16C: 1 <Enter> 2 / -> 0 h (c)
    On NeoCal: 1 <Enter> 2 / -> 500.e-3

    Note: the (c) on the 16C indicates the "carry" bit was set, which the
    16C does whenever the remainder of a division is nonzero.

    Caveats: The result for each calculator depends on its "mode." In
    "programmer" mode, each calculator performs a truncating integer
    division. The 16C is in programmer mode by default. The 48S is
    almost never in programmer mode since I bought the 16C. NeoCal goes
    into programmer mode about 25% of the time I use it. It was in
    "Statistics" mode when I powered it up just now.

    >
    >
    >> As you pointed out: the "true division" part of "Python3000" might be
    >> one of the "scariest" and should therefore be pointed out already in
    >> the tutorial !! (It would look quite ugly to newcomers, though)


    If you want ugly, consider Pascal. The / operator could not perform
    an integer divide, and a compile-time error was generated if you
    attempted to use it with integer operands. The integer divide
    operator was 'div', e.g. "i = j div k"

    >
    >The tutorial shouldn't talk about Python3000 at all. What would be the
    >point of that? The tutorial is there to teach about the way Python works
    >now, not to make guesses and prediction about how it will work some time
    >in the indefinite future.
    >
    >
    >> Having said that: I would vote against EVER introducing true division
    >> as default - because it will just PISS too many (long time python)
    >> people OFF. ;-)

    >
    >Do you realise that the reason true division was introduced into Python
    >was because many long-time Python programmers requested it? So far from
    >annoying them, it is a feature that most Python programmers are waiting
    >for.


    I am a relatively long-time user (since about 1999) of Python, but I
    mainly program in C. "True" division probably wouldn't p*ss me off
    too bad, and I certainly wouldn't have a problem with new scripts I
    wrote. But if it broke old scripts, I wouldn't be extremely happy.

    FWIW, ISTM that "true" division would be better implemented by the new
    // operator, leaving the behavior of / unchanged. But that's probably
    just me.

    Regards,
    -=Dave

    --
    Change is inevitable, progress is not.
     
    Dave Hansen, Feb 20, 2006
    #18
  19. Magnus Lycka Guest

    Steve Holden wrote:
    > wrote:
    >> My main point was/is: why is there not more discussion about "true
    >> division" !!?

    >
    > You are about three years too late for the discussion. It was debated to
    > death when Guido proposed that Python should behave more like
    > non-programmers expected it to. Despite some fierce opposition this view
    > eventually held sway, and now long-time Pythonistas accept it as the way
    > forward.


    I think you should understand "discussion" as "mentioning" or
    "documentation" here.

    However much it was discussed three years ago, enabling it as
    default in 3.0 will be a bit like the Vogons suddenly appearing
    to demolish Earth, if it hasn't been documented clearly.

    The tutorial shouldn't teach a coding style that will cause
    problems when we reach the next major version of Python. At
    least not if it's easily avoided.

    Python has supported true division for more than four years, and
    it's been decided from the onset that this will be default behaviour
    in 3.0. The Tutorial basically ignores it. Ok, it's mentioned in
    passing in the glossary, but not where it explains how division works!

    > So basically most people saw your question and probably thought "enough,
    > already!".


    Having followed comp.lang.python for several years should not be a
    requirement for programming Python properly. Neither should it be a
    requirement to read all the PEPs or "what's new in Python version
    2.2" when someone starts learning Python with 2.4! I had more or less
    forgotten about this (do you use "from __future__ import division"
    in all your scipts Steve?) so I think it's a good thing that this
    was brought up. Particularly if Guido's Google jobs brings 3.0
    closer to its release...

    I started http://wiki.python.org/moin/FutureProofPython as a place
    to document this, but I doubt that yet-another-wiki-page is the
    perfect solution for this. It might be useful as a placeholder for
    the time being though, and I hope that some of you who are better
    at this than I am improves that page a bit, and more importantly,
    that it gets into the Tutorial.

    I've now inspected more than 1700 python files from a number of
    sources, Twisted being one of them, with 235kLoC, written by scores
    of different developers. I found no "from __future__ import division"
    statement, but almost 7000 lines with '/' that needs to be inspected
    one way or another. (Not all divisions, I'm sure, but still a
    substancial amount of work to check, and plenty of new test cases.)
     
    Magnus Lycka, Feb 20, 2006
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steve Holden

    PyCon is Coming! PyCon is Coming!

    Steve Holden, Jan 5, 2006, in forum: Python
    Replies:
    0
    Views:
    337
    Steve Holden
    Jan 5, 2006
  2. Replies:
    94
    Views:
    4,691
    ¬a\\/b
    Feb 9, 2007
  3. bdb112
    Replies:
    45
    Views:
    1,427
    jazbees
    Apr 29, 2009
  4. Curt Hibbs
    Replies:
    1
    Views:
    263
    olof sivertsson
    Dec 18, 2005
  5. Curt Hibbs
    Replies:
    2
    Views:
    273
    Curt Hibbs
    Dec 18, 2005
Loading...

Share This Page