Future watch: how will python division change affect zope?
Hey all, I was wondering if anyone here has given any (rational) thought on what python's PEP238 affects zope, zope coders and zope users. For those of you that don't know, PEP238 which is still be thought about, will change how the division operand ('/') works with integers. Currently the following is what happens in python int/int == int 2/1 == 2 3/2 == 1 3/4 == 0 under PEP238 this will change to int/int == float 2/1 == 2.0 3/2 == 1.5 3/4 == 0.75 to do integer division you would have to use a _new_ operand ('//'). Now first off, this PEP has not been accepted (although Guido is leaning towards it), and there supposedly will be 2 years of warnings before it changes. But I'm not sure how the warnings are going to appear in dtml calls or the python methods? I just checked and divmod is available so you could do <dtml-var expr="_.divmod[a,b][0]"> to get the same value as <dtml-var expr="a/b">. I'm more concerned with the python methods that are out there or will be going out there. Should we start coding defensively? Maybe I should add a generic div method and have the folks here use that instead of '/'? Thoughts? Opinions? -- Tom Jenkins devIS - Development Infostructure http://www.devis.com
To me this sounds like a huge mistake -- it's a different escalation rule than any other language.
From: Tom Jenkins <tjenkins@devis.com>
For those of you that don't know, PEP238 which is still be thought about, will change how the division operand ('/') works with integers. Currently the following is what happens in python int/int == int 2/1 == 2 3/2 == 1 3/4 == 0
under PEP238 this will change to int/int == float 2/1 == 2.0 3/2 == 1.5 3/4 == 0.75
Chris Withers writes:
marc lindahl wrote:
To me this sounds like a huge mistake -- it's a different escalation rule than any other language.
Go to agree with that. What are the reasons _for_ doing this? Most people without knowledge of "C" derived programming languages are astonished that "1/2" can be "0".
Dieter
From: Dieter Maurer <dieter@handshake.de>
Go to agree with that. What are the reasons _for_ doing this?
Most people without knowledge of "C" derived programming languages are astonished that "1/2" can be "0".
...conversely, most programmers (the hardware independent ones!) are astonished when they find out the overhead involved in the floating point operation....
marc lindahl wrote:
From: Dieter Maurer <dieter@handshake.de>
Go to agree with that. What are the reasons _for_ doing this?
Most people without knowledge of "C" derived programming languages are astonished that "1/2" can be "0".
...conversely, most programmers (the hardware independent ones!) are astonished when they find out the overhead involved in the floating point operation....
Anyone who cares about that can easily RTFM and learn how to get what they want. Python has always excelled at enabling newbies to get the results they want with a minimum of fuss. I think this PEP is entirely consistent with that design goal for the language, and it takes away no power from anyone who is able to read the manual. Anyway, this change has long been in the works; Guido has been talking about it for many years and has probably heard every possible argument by now. -- ................... paul winkler .................... custom calendars & printing: http://www.calendargalaxy.com A member of ARMS: http://www.reacharms.com home page: http://www.slinkp.com
On Wed, 25 Jul 2001, Dieter Maurer wrote:
Chris Withers writes:
marc lindahl wrote:
To me this sounds like a huge mistake -- it's a different escalation rule than any other language.
Go to agree with that. What are the reasons _for_ doing this? Most people without knowledge of "C" derived programming languages are astonished that "1/2" can be "0".
That's not a reason to count like shit those who are ! Jerome Alet
Dieter Maurer wrote:
Go to agree with that. What are the reasons _for_ doing this? Most people without knowledge of "C" derived programming languages are astonished that "1/2" can be "0".
Yes, but I bet there's a _lot_ of code that relies on this fact, and it'll be difficult to find and check every instance of a / :-( cheers, Chris
Chris Withers writes:
marc lindahl wrote:
To me this sounds like a huge mistake -- it's a different
escalation rule
than any other language.
Go to agree with that. What are the reasons _for_ doing this? Most people without knowledge of "C" derived programming languages are astonished that "1/2" can be "0".
Marc & Chris are wrong here. Every 3rd grader in the US knows that 1/2 is not 0. So I would say that (american) english agrees with the proposed new division rules in python.
On Thu, Jul 26, 2001 at 08:55:36AM -0500, Steve Drees wrote:
Chris Withers writes:
marc lindahl wrote:
To me this sounds like a huge mistake -- it's a different
escalation rule
than any other language.
Go to agree with that. What are the reasons _for_ doing this? Most people without knowledge of "C" derived programming languages are astonished that "1/2" can be "0".
Marc & Chris are wrong here. Every 3rd grader in the US knows that 1/2 is not 0. So I would say that (american) english agrees with the proposed new division rules in python.
This is not the place to discuss this. But the integer operation is 'gazinta', not divide. As in, 8 gazinta 59 7 times with remainder 3. If you really want to improve integer division, it should return a tuple, (dividend, remainder), especially since almost all hardware finds both simultaneously. That would break too much code also. But at least it is sound mathematically (both grade school and graduate school) and far less expensive computationally. For those who are too young to remember their gazintas (or not American enough), that was what the phrase 'goes in to' degenerates into after a bunch of grade schoolers are chanting it. That is, divide is defined differently over the group of integers, than over the field of rationals or of real numbers. It is a notational confusion that the integer 1 and the rational 1/1 have the same notation. It happens to be a useful confusion in most contexts. This is not one of them. Jim Penny BTW: I thought that last I saw Guido was leaning against this PEP.
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
participants (8)
-
Chris Withers -
Dieter Maurer -
Jerome Alet -
Jim Penny -
marc lindahl -
Paul Winkler -
Steve Drees -
Tom Jenkins