Python 3000 deat !? Is true division ever coming ?

[seb.haase]

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

[seb.haase]

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: 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.

[Steven D'Aprano]

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.

[Terry Reedy]

<se*******@gmai l.com> wrote in message
news:11******** **************@ o13g2000cwo.goo glegroups.com.. .

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

[Dan Bishop]

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?

[Steve Holden]

se*******@gmail .com 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 [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Dave Hansen]

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.pytho n, Steven
D'Aprano <st***@REMOVETH IScyber.com.au> 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.

[Magnus Lycka]

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]

Steve Holden wrote:

se*******@gmail .com 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
"documentat ion" 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.pytho n 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.)