[EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
