Fred> There is the python-numerics mailing list on SourceForge; find it Fred> from the Python project page there: Fred> http://sourceforge.net/projects/python/ I don't suppose there's any chance those three sourceforge-hosted mailing lists could be mentioned on mail.python.org, could they? Seems to me that those three mailing lists are sponsored by the same organization as those hosted on mail.python.org. Skip

Skip Montanaro writes:

I don't suppose there's any chance those three sourceforge-hosted mailing lists could be mentioned on mail.python.org, could they? Seems to me that those three mailing lists are sponsored by the same organization as those hosted on mail.python.org.

I don't know any way to do that. If we could more easily create new lists on python.org (i.e., not have to wait for Barry), they never would have been created on SourceForge. Guido van Rossum writes:

I think they should be mentioned there. Fred, can you edit the MailingLists.ht file?

Done. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations

Damn... Are the archives of the python-numeric list available somewhere as a single mbox file or something? Looks like geocrawler is going to make me wade through the archives message-by-message on their website. Skip

Fred> There is the python-numerics mailing list on SourceForge; find it Fred> from the Python project page there: Fred> http://sourceforge.net/projects/python/ BAW> Ah. Shouldn't this page BAW> http://www.python.org/sigs/ BAW> point to this page BAW> http://sourceforge.net/mail/?group_id=5470 BAW> ??? Looks like we have at least three pages that list related info: http://www.python.org/sigs/ http://mail.python.org/ http://sourceforge.net/mail/?group_id=5470 Can they be unified? Skip

>> Looks like we have at least three pages that list related info: >> >> http://www.python.org/sigs/ >> http://mail.python.org/ >> http://sourceforge.net/mail/?group_id=5470 >> >> Can they be unified? Guido> I don't see how. Perhaps they can at least be made to point incestuously to one another (though I imagine the sf page is completely out of our control and thus immune to such incest)... Skip

...

...

...

...

"SM" == Skip Montanaro writes:

>> Looks like we have at least three pages that list related info: >> http://www.python.org/sigs/ http://mail.python.org/ >> http://sourceforge.net/mail/?group_id=5470 Can they be unified? Guido> I don't see how. SM> Perhaps they can at least be made to point incestuously to one SM> another (though I imagine the sf page is completely out of our SM> control and thus immune to such incest)... Only the /sigs/ page is statically generated, so only it is easy to change. -Barry

...

...

...

...

...

"SM" == Skip Montanaro writes:

SM> Today I took a look at http://mail.python.org/mailman/listinfo SM> and could find no math-sig or number-sig mailing list. If SM> Python's number system is going to change in one or more SM> backwards-incompatible I think there may only be one chance to SM> get it right. I think a number-sig mailing list would be a SM> worthwhile forum to discuss these issues.

+1. If others agree, I'll create the sig.

-Barry

Sounds like a good plan, but please wait until we have a SIG owner/moderator and a charter. Without both of these a SIG will be a failure. --Guido van Rossum (home page: http://www.python.org/~guido/)

Briefly: [Skip Montanaro]

... I realize there is no obviously right numeric model.

There are many that are reasonable, though -- and that's the other half of the problem.

If there was, most programming languages would use it and we wouldn't need bots like Tim to help guide us through minefields like IEEE 754.

You've never seen a language that supports 754 properly (== as the committee intended). Certainly not Python, C or Java. It's far less a minefield when properly supported, and was designed to be much saner than previous binary f.p. systems. One problem is that languages only support the *corner* of 754 that intersects with 1950's Fortran; the other is that very few chips other than Pentium support the 754 80-bit extended format that's key to making binary f.p. much safer for non-experts. OTOH, the "proper 754 support" in the C99 Annex is a minefield of its own.

By "right" I mean that we can arrive at a long-term stable numeric model that will be accepted by both the Python community as a whole *and* by the decision makers who will vote thumbs up or down on adopting Python in their organizations.

The danger I see here is that Scheme's "numeric tower" is almost obviously a reasonable numeric model, but in practice is so vague that you can't really count on anything beyond simple small-int arithmetic working the same way across Scheme implementations. Guido appears to have come to an appreciation of that model in the abstract, but hoping that there's not much difference between floats and rationals in practice "because they represent the same mathematical values" just isn't going to pan out (IMO). 1/49*49 equals 1 or it doesn't; it doesn't using IEEE doubles, it does using rationals, and the difference will be significant to programs. Certainly better to switch from floats to rationals someday than to move in the other direction, though. I've come to suspect the issues *may& be complicated <wink>.

By "right" I mean that we can arrive at a long-term stable numeric model that will be accepted by both the Python community as a whole *and* by the decision makers who will vote thumbs up or down on adopting Python in their organizations. One of the most vocal opponents to PEP 238 (I won't mention his name, but his initials are S.H. ;-) lamented loudly that he'd be a laughing stock in his company because of that "division thing". He mentioned something about being a "right arse" I think.

I'm not so worried. While many of the opponents tried to explain their position by arguing that int division was "right", their real worry was backwards compatibility. PEP 238 represents the *only* serious backwards incompatibility in the transition to a new numeric model that I can imagine. The transition plan that I hope to be checking into PEP 238 deals with the fears of the opponents by putting the sea change off until Python 3.0.

By having a well-considered overall plan for Python's numeric behavior, if you have to make an incompatible change today, another next year and a third two years after that, you can point to the plan that shows people where you're headed, how you plan to get there, and how they can write their programs in the meantime so as to be as resilient as possible. Without such a plan -- or with several potentially competing plans as you proposed -- every change proposed or made will simply fuel the fires of those people who dismiss Python because "it's unstable". The funny thing is, Python's semantics changed so little for so long that by comparison the rate of change does seem pretty high, but it's still much better than many applications or application libraries (such as the relatively recent glibc upheaval or the API changes Gtk is undergoing now). And let's not even mention the folks in Redmond...

Any additional serious incompatibilities will also be put off till Python 3.0. But I repeat, I don't expect any. Let me review: Int/long unification: - This "breaks" code that counts on the OverflowError. - This changes the meaning of left shift (the only operation that silently throws away bits rather than raising OverflowError). - This changes the meaning of octal and hex constants that set the sign bit in short integers -- 0xffffffff is currently a fancy way of writing -1 on a 32-bit machine, but after unification it will be the same as 0xffffffffL (i.e., 2**32-1). None of these is a big deal I think. Rationals: - The introduction of a new rational type in itself doesn't break anything. - Making 1/2 return a rational instead of a float could break some things but not at the scale of PEP 238. - Making 0.5 be a rational instead of a float will break more; we'll have to discuss this. I should note that the inclusion of rationals in the new numeric model is far from certain. There are potential problems with rationals that may require them to remain a separate type forever. This is about the extent of the changes to the numeric model that I'm contemplating; I don't think that the new numeric model should change much else. (I don't care much for some of the details of PEP 228, but I have to think more about it.) In other words, while the plan isn't spelled out yet, the only disruption is PEP 238. --Guido van Rossum (home page: http://www.python.org/~guido/)