Re: [Python-Dev] RELEASED Python 2.4 (final)
On Tue, 30 Nov 2004 23:31:34 +1100, Anthony Baxter <[EMAIL PROTECTED]> wrote: > On behalf of the Python development team and the Python community, I'm > happy to announce the release of Python 2.4. Anthony, congratulations with this smooth release! Thanks for all the hard work. Enjoy your beer, I'm celebrating with you in spirit. Thanks also to all the other developers who contributed to this release, and to the many thousands of users who helped with the the beta testing. Let's hope for record downloads, -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: How to kill a SocketServer?
[Skip Montanaro] > I stumbled on a somewhat cleaner way to do this using socket timeouts: > > class Server(SocketServer.ThreadingMixIn, SocketServer.TCPServer): > pause = 0.25 > allow_reuse_address = True > > def __init__(self, server_address, RequestHandlerClass): > SocketServer.TCPServer.__init__(self, server_address, > RequestHandlerClass) > self.socket.settimeout(self.pause) > self.serving = 1 > ... > > def serve_forever(self): > while self.serving: > self.handle_request() > > As far as my simple testing went (a trivial little xmlrpc server exposing > only "noop" and "exit" methods), the above worked fine. I was mildly > surprised that I didn't have to catch socket.timeout exceptions. I think this would cause timeouts in the middle of handling request whenever a client is slow. -- --Guido van Rossum (home page: http://www.python.org/~guido/) -- http://mail.python.org/mailman/listinfo/python-list
For review: PEP 343: Anonymous Block Redux and Generator Enhancements
After many rounds of discussion on python-dev, I'm inviting public comments for PEP 343. Rather than posting the entire PEP text here, I'm inviting everyone to read it on line (http://www.python.org/peps/pep-0343.html) and then post comments on a Wiki page I've created for this purpose (http://wiki.python.org/moin/WithStatement). I think this is a good one; I hope people agree. Its acceptance will obsolete about 4 other PEPs! (A sign that it fulfills a need and that the proposed solution is powerful.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-3000] bug in modulus?
This is way above my head. :-) The only requirement *I* would like to see is that for floats that exactly represent ints (or longs for that matter) the result ought of x%y ought to have the same value as the same operation on the corresponding ints (except if the result can't be represented exactly as a float -- I don't know what's best then). We're fixing this for / in Py3k, so passing an int into an algorithm written for floats won't be harmful and won't require defensiev float() casting everywhere. It would be a shame if we *introduced* a new difference between ints and floats for %. --Guido On 5/2/06, Tim Peters <[EMAIL PROTECTED]> wrote: > [Andrew Koenig, on the counter intuitive -1e-050 % 2.0 == 2.0 example] > >> I disagree. For any two floating-point numbers a and b, with b != 0, it > >> is always possible to represent the exact value of a mod b as a > >> floating-point number--at least on every floating-point system I have ever > >> encountered. The implementation is not even that difficult. > > [also Andrew] > > Oops... This statement is true for the Fortran definition of modulus (result > > has the sign of the dividend) but not the Python definition (result has the > > sign of the divisor). In the Python world, it's true only when the dividend > > and divisor have the same sign. > > Note that you can have it in Python too, by using math.fmod(a, b) > instead of "a % b". > > IMO, it was a mistake (and partly my fault cuz I didn't whine early) > for Python to try to define % the same way for ints and floats. The > hardware realities are too different, and so are the pragmatics. For > floats, it's actually most useful most often to have both that a % b > is exact and that 0.0 <= abs(a % b) <= abs(b/2). Then the sign of a%b > bears no relationship to the signs of a and b, but for purposes of > modular reduction it yields the result with the smallest possible > absolute value. That's often valuable for floats (e.g., think of > argument reduction feeding into a series expansion, where time to > convergence typically depends on the magnitude of the input and > couldn't care less about the input's sign), but rarely useful for > ints. > > I'd like to see this change in Python 3000. Note that IBM's proposed > standard for decimal arithmetic (which Python's "decimal" module > implements) requires two operations here, one that works like > math.fmod(a, b) (exact and sign of a), and the other as described > above (exact and |a%b| <= |b/2|). Those are really the only sane > definitions for a floating point modulo/remainder. > _______ > Python-3000 mailing list > Python-3000@python.org > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: > http://mail.python.org/mailman/options/python-3000/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] Python 3000 PEP: Postfix type declarations
ate
> a 3-⒯ of ✎s would be nice. This would change the line in the above
> from "if comp✎ in ('', '.')⒯:" to "if comp✎ in ('', '.')✎✎2⒯:", which
> I think is a nice win in terms of readability, EIBTI and all that.
>
> (Sidebar: I think the PEP should feature a section on how these new
> type declarations will cut down on mailing list volume and
> documentation size.)
>
> In light of this PEP, PEP 3107's function annotations should be
> rejected. All that hippie feel-good crap about "user-defined
> annotations" and "open-ended semantics" and "no rules, man" was just
> going to get us into trouble. This PEP's more modern conception of
> type annotations give the language a power and expressiveness that my
> PEP could never hope to match.
>
> This is clearly a move in the right direction. +4 billion.
>
> Collin Winter
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
--
http://mail.python.org/mailman/listinfo/python-list
