se*******@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 PendingDeprecat ionWarning, and
the minor release after that will issue a DeprecationWarn ing
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...00000000000000 http://docs.python.org/dev/tut/node1...00000000000000
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 FutureProofPyth on page
in the Python wiki, with suggested coding guidelines.
