Python 3000 deat !? Is true division ever coming ?

[seb.haase at gmail.com]

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:
> seb.haase at gmail.com 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.