Mailman 3 September 2001 - Python-Dev

-Dwarn, long->double overflow (was RE: [Python-checkins] CVS: python/dist/src/Misc NEWS,1.219,1.220)
by Tim Peters Sept. 4, 2001

Sept. 4, 2001

[Guido] > + + A new command line option, -D<arg>, is added to control run-time > + warnings for the use of classic division. > ... > + Using -Dwarn issues a run-time warning about all uses of classic > + division for int, long, float and complex arguments. I'm unclear on why we warn about classic division when a float or complex is involved: C:\Code\python\PCbuild>python -Dwarn Python 2.2a2+ (#22, Aug 31 2001, 14:36:57) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> 2./3. __main__:1: DeprecationWarning: classic float division 0.66666666666666663 >>> Given that this is going to return the same result even in Python 3.0, what is it warning me about? That is, as an end user, I'm being warned about behavior I can't do anything about, and behavior that Python isn't going to change anyway. Different issue: I would like to add OverflowError when coercion of long to float yields a senseless result. PEP 238 mentions this as a possibility, and >>> from __future__ import division >>> x = 1L << 3000 >>> x/(2*x) -1.#IND >>> really sucks. For that matter, >>> float(1L << 3000) 1.#INF >>> has always sucked; future division just makes it suck harder <wink>. Any objections to raising OverflowError here? Note this is a bit painful for a bogus reason: PyFloat_AsDouble returns a double, and nothing in the codebase now checks it for a -1.0 error return (despite that it can already produce one). So half the effort would be repairing code currently ignoring the possibility of error. Third issue: I don't see a *good* reason for the future-division x/(2*x) above not to return 0.5. long_true_divide could be made smart enough to do that (more generally, to return a good float approximation whenever the true result is representable as a float).

6 14

Python
by Martin v. Loewis Sept. 3, 2001

Sept. 3, 2001

[I just filled out the form at the URL; if they get multiple registrations, they probably have to pick one of them]. Liebes c't-Shareware-Team, Das klingt ja verdammt nach einer automatischen Email; mit ein wenig Recherche wäre wohl auch die Email-Adresse des Python-Erfinders rausgesprungen... Auf jeden Fall habe ich jetzt Euer Formular ausgefüllt, ich habe dabei *nicht* den Namen des Python-Erfinders angegeben; als zu veröffentlichende Adresse habe ich python-list(a)python.org angegeben. Diese Adresse ist ebenfalls mit einer grossen Email-Liste verbunden sowie mit comp.lang.python; ein Nutzer, der also an diese Adresse schreibt, sendet an viele Leser. MfG, Martin

1 0

CVS tree doesn't build currently
by Jack Jansen Sept. 3, 2001

Sept. 3, 2001

I can't build from the CVS tree right now (confirmed on Irix and OSX): setup.py crashes. Here's the stacktrace: CC='cc' LDSHARED='ld -shared -all' ./python -E ./setup.py build Traceback (most recent call last): File "./setup.py", line 708, in ? main() File "./setup.py", line 702, in main scripts = ['Tools/scripts/pydoc'] File "/ufs/jack/src/python/Lib/distutils/core.py", line 101, in setup _setup_distribution = dist = klass(attrs) File "/ufs/jack/src/python/Lib/distutils/dist.py", line 129, in __init__ setattr(self, method_name, getattr(self.metadata, method_name)) AttributeError: DistributionMetadata instance has no attribute 'get___doc__' -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

3 2

CVS tags, unix Python and MacPython
by Martin v. Loewis Sept. 3, 2001

Sept. 3, 2001

> Things will get worse with the 2.2a2 release, as there are a couple > of things that I definitely want in there that aren't finished yet, > so it'll be at least another week until I'm done, and moreover I'll > have to be making a few (minor) mods to files outside the Mac > subtree. From a procedural, quality-guaranteeing point of view, I think you shouldn't release anything as "MacPython 2.2a2" which does not come from the 2.2a2 tag (and, as Guido explains, you should never move a tag). There is no such thing as the "Unix release" of Python 2.2a2; there is the source distribution, and there happens to be a Windows binary (which I trust came from the tagged source); everything coordinated by the release manager. IOW, if your changes missed the release date by a few days, tough luck - PEP 251 is there precisely for the purpose to align your changes with the rest of the tree, and to enable you to get a consistent, if not perfect, code base included in the alpha release. In theory, all you have to do is to compile this to get a binary distribution, perhaps with any add-on modules that you also want to distribute. It seems that nobody else is making much fuss about this, so I'll shut up now... Regards, Martin

3 2

Re: [Python-Dev] CVS tags, unix Python and MacPython
by Jack Jansen Sept. 3, 2001

Sept. 3, 2001

> Jack doesn't have that kind of intimate access to (and veto power over!) the > release process, so there's going to be some kind of compromise somewhere. > I think it should be limited to post-release changes in the Mac subtree > alone, and that he should tag the whole tree with mac-rIJAK for easy > reproducibility later. Yes, I think I'll do just that. I don't like the proliferation of tags, but in general there's no way I can be sure to keep up with the unix/windows release process, there being other things needing my time too:-) Although for 2.2a3 this weeks things look pretty good, -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Python
by c't-Shareware-Team Sept. 3, 2001

Sept. 3, 2001

English version at the end of this e-mail Sehr geehrter Programmautor, wir betreiben unter http://www.heise.de/ct/shareware/ ein gut besuchtes Verzeichnis von Free- und Shareware- Programmen. Einer unserer Besucher hat uns auf Ihr Programm Python aufmerksam gemacht. Gerne würden wir Ihr Programm in unser Verzeichnis aufnehmen. Daher möchte ich Sie bitten Ihr Programm unter http://www.heise.de/ct/shareware/default.shtml?ad=af&v=13 einzutragen. Mit freundlichen Grüßen, Ihr c't-Shareware-Team *** Dear Program Author, At http://www.heise.de/ct/shareware/, we keep a popular Free and Shareware archive. One of our visitors has recommended your program Python. In order to be able to include your program in our archive, we would like to ask you to provide further details to your program at http://www.heise.de/ct/shareware/default.shtml?ad=af&v=13&lang=e Yours, c't Shareware Team

1 0

3-arg float pow()
by Tim Peters Sept. 3, 2001

Sept. 3, 2001

Python's builtin 3-argument pow() exists because, e.g., >>> pow(3L, 500, 7) 2L >>> can be done very much faster, and with much less memory, than >>> 3L**500 % 7 2L >>> There isn't any compelling use I know of for 3-arg pow() given float arguments, though, and what you get back is a platform-dependent accident: >>> pow(3., 500., 7.) 4.0 >>> You may get some other integer there, or an Infinity or a NaN, depending on the Python release, and the compiler used to build Python, and the configuration of your libm. That example was done under CVS 2.2a2+ on Windows; here's the same thing but under 2.2.1: >>> pow(3., 500., 7.) 0.0 >>> Since 3-argument float pow() *appears* to be at best useless, I'm taking it away in 2.2a3, unless someone can testify to a reasonable use case that's actually used. more-trouble-than-it's-worth-if-it-isn't-worth-anything-ly y'rs - tim

1 0

Change from "config.h" to "pyconfig.h" may be a ticking #include bomb
by Martin v. Loewis Sept. 2, 2001

Sept. 2, 2001

> To pick up this sort of bug, perhaps "make install" should attempt > to remove config.h if it exists in the target include directory? I don't think so. Once Python 2.2 is released, it will install its headers into <prefix>/include/python2.2, which will be empty since it is the first usage ever of this directory; the previous *release* installed its files into a different location. Giving the advice to people to remove their <prefix>/include/python2.2, and (most of) <prefix>/lib/python2.2 if they update from an earlier alpha release might be a good idea, though: there might be other removed or renamed files whose absence they would not notice. Regards, Martin

1 0

Would it make sense to issue an extra alpha next week?
by Guido van Rossum Sept. 1, 2001

Sept. 1, 2001

When I was updating the NEWS file this morning, I realized that we've already added a truckload of nifty stuff in the 9 days since 2.2a2 was released: int overflows return longs, classic division warnings, subclassing builtins, super, getset, two fixes to float literals, the new GC API, and PyString_FromFormat[V]. I expect that I'll be concentrating on documentation for the type/class unification next. While writing the first piece of documentation, I realized that, sadly, several more advanced things aren't available in 2.2a2 yet. The next alpha is planned for Sept. 19, almost three weeks off still. Does anybody object against the release of an extra release, 2.2a3, around Sept. 5? We could do 2.2a4 on Sept. 19, or a week later if the schedule gets too crowded. --Guido van Rossum (home page: http://www.python.org/~guido/)

3 2