[Python-Dev] PyPI offline, status is ok
http://status.python.org/ shows all green https://pypi.python.org/pypi/gazest shows Error 503 backend read error backend read error Guru Meditation: XID: 2792709923 Varnish cache server https://pypi.python.org/pypi/ shows XID: 4199593736 -- anatoly t. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPI offline, status is ok
On Mon, Feb 10, 2014 at 5:23 PM, anatoly techtonik techto...@gmail.com wrote: http://status.python.org/ shows all green https://pypi.python.org/pypi/gazest shows Error 503 backend read error backend read error Guru Meditation: XID: 2792709923 Working for me. But then, your email only just came through, and it's dated four hours ago, so maybe python-dev was also having trouble. Or maybe your ISP was having trouble. Hard to say now. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPI offline, status is ok
On Mon, Feb 10, 2014 at 1:42 PM, Chris Angelico ros...@gmail.com wrote: On Mon, Feb 10, 2014 at 5:23 PM, anatoly techtonik techto...@gmail.com wrote: http://status.python.org/ shows all green https://pypi.python.org/pypi/gazest shows Error 503 backend read error backend read error Guru Meditation: XID: 2792709923 Working for me. But then, your email only just came through, and it's dated four hours ago, so maybe python-dev was also having trouble. Or maybe your ISP was having trouble. Hard to say now. ISP for sure won't run Varnish, which is enabled for Python Warehouse here: https://github.com/python/psf-chef/blob/14bbebdbbc4f7ccc65e0478458cab433594f2cfa/cookbooks/psf-pypi/recipes/warehouse.rb ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: [python-tulip] Need help to finish asyncio documentation
In article cap7+vjkmbpyu_e+4tyc3x6ofc_ydmd9k9pxk8atoll6oj_8...@mail.gmail.com, Guido van Rossum gu...@python.org wrote: We could really use more help reviewing and finishing asyncio's docs! ... http://docs.python.org/dev/library/asyncio.html I think the documentation desperately needs an overview. I find it very confusing without one. I guess the links to PEPs are intended to be that, but it would be much more helpful to include the overview in the documentation. I think a bit of re-ordering of topics could also help: - One of the first things presented is a discussion of event loop policy, even though most users will never need to change the policy. Couldn't this go at the end? - It tells how to create and set event loops, with no hint as to why one would want to do that. Is it common to have multiple event loops? A related oddity: what is the point of BaseEventLoop.run_until_complete(future)? It sounds interesting but obscure (unless it applies to one of many event loops). In other words: if it was possible to show basic usage of event loops early, then discuss how to do the fancy stuff (new event loops, new even loop policies later) that might help. BaseEventLoop.stop() says: Every callback scheduled before stop() is called will run. but it does not say WHEN it will run -- immediately due to the stop, or normally as if stop was never called? That said, I am very excited to have this functionality. I have been sticking with Python 2 for now, but this feature may entice me to make the switch. -- Russell -- Forwarded message -- From: Victor Stinner victor.stin...@gmail.com Date: Sat, Feb 8, 2014 at 2:38 PM Subject: [python-tulip] Need help to finish asyncio documentation To: python-tulip python-tu...@googlegroups.com Hi, I wrote most parts of the documentation of the asyncio module, but I'm not sure that anyone already read it yet. Can you please at least take at look? http://docs.python.org/dev/library/asyncio.html Tell me if the documentation needs more examples. I don't want to add whole applications, only very short examples to explain one feature or concept, or show how to use one specific API. I just realized that add/remove_reader/writer() methods of the event loop were not documented, sock_recv/sendall/accept/connect() methods neither. I documented them. There are still many functions which only have XXX for documentation. If you would like to contribute, send patches on .rst files. The source of the documentation is in the Doc/library/ directory of CPython repository: http://hg.python.org/cpython/ Files asyncio-*.rst: http://hg.python.org/cpython/file/default/Doc/library Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASED] Python 3.3.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Python development team, I'm very happy to announce the release of Python 3.3.4. Python 3.3.4 includes several security fixes and over 120 bug fixes compared to the Python 3.3.3 release. This release fully supports OS X 10.9 Mavericks. In particular, this release fixes an issue that could cause previous versions of Python to crash when typing in interactive mode on OS X 10.9. Python 3.3 includes a range of improvements of the 3.x series, as well as easier porting between 2.x and 3.x. In total, almost 500 API items are new or improved in Python 3.3. For a more extensive list of changes in the 3.3 series, see http://docs.python.org/3.3/whatsnew/3.3.html To download Python 3.3.4 visit: http://www.python.org/download/releases/3.3.4/ This is a production release, please report any bugs to http://bugs.python.org/ Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.3's contributors) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlL5PMwACgkQN9GcIYhpnLCv4wCePNVqwsOYCHdJBix2bKk4PNpK GBoAnRML2x6obCssnUJe5xwuUZYw8ZSY =+/Nz -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: [python-tulip] Need help to finish asyncio documentation
On Mon, Feb 10, 2014 at 12:47 PM, Russell E. Owen ro...@uw.edu wrote: In article cap7+vjkmbpyu_e+4tyc3x6ofc_ydmd9k9pxk8atoll6oj_8...@mail.gmail.com, Guido van Rossum gu...@python.org wrote: We could really use more help reviewing and finishing asyncio's docs! ... http://docs.python.org/dev/library/asyncio.html I think the documentation desperately needs an overview. I find it very confusing without one. I guess the links to PEPs are intended to be that, but it would be much more helpful to include the overview in the documentation. Thanks very much -- this is the kind of thing that's hard to notice as the author (of either the code or the docs :-). I think a bit of re-ordering of topics could also help: - One of the first things presented is a discussion of event loop policy, even though most users will never need to change the policy. Couldn't this go at the end? Indeed. - It tells how to create and set event loops, with no hint as to why one would want to do that. Is it common to have multiple event loops? Shouldn't be that common (but more common than creating or even using the policy). A related oddity: what is the point of BaseEventLoop.run_until_complete(future)? It sounds interesting but obscure (unless it applies to one of many event loops). That's actually pretty common in a main() program. See several examples in the Tulip repo, e.g. http://code.google.com/p/tulip/source/browse/examples/crawl.py#851 In other words: if it was possible to show basic usage of event loops early, then discuss how to do the fancy stuff (new event loops, new even loop policies later) that might help. BaseEventLoop.stop() says: Every callback scheduled before stop() is called will run. but it does not say WHEN it will run -- immediately due to the stop, or normally as if stop was never called? Yeah, this is confusing -- it only applies to callbacks scheduled with call_soon(), not for those scheduled with call_later() or call_at() (and for those scheduled with call_soon_threadsafe() all bets are off, of course). it may not even be such a good idea to make this promise (though it's also in PEP 3156) -- the promise constrains the behavior of stop(). The implementation is kind of cute though: call_soon() adds things to a FIFO and the event loop picks items to run off this FIFO -- and stop() just adds a sentinel item to the FIFO. The FIFO behavior implements the promise. Also notice that if a callback schedules a further callback using call_soon(), the latter will end up in the FIFO *after* the sentinel item, so it won't run. It's also important to understand that a stopped loop can always be resumed with no ill effects -- the sentinel having been popped off the FIFO, the loop will continue to run until it is stopped again. (But there's also a bit if an issue here if you stop it twice in a row -- the second stop() call will remain in the FIFO.) Finally, scheduling something with call_later(0, cb) is *not* the same as call_soon(cb). call_later() *always* creates a scheduler item which will require a separate tick of the loop before it gets moved to the above-mentioned FIFO (a.k.a. the ready queue). Perhaps the following is helpful (though it gives more implementation detail than we should probably put in the docs). The event loop repeats the following steps forever: 1. Wait for I/O ready with a deadline equal to the earliest scheduled item (zero if the ready queue is non-empty, infinity if nothing is scheduled) 2. Add I/O handlers that should be called to the ready queue 3. Move scheduled items that are now dueue to the ready queue 4. Run everything that is *currently* in the ready queue When the sentinel from stop() is found in the ready queue, the loop stops, leaving any remaining items in the ready queue. When the loop is restarted, we start from the top, with a deadline equal to zero. The other useful thing to understand is the data structures used by the event loop: - a ready queue (the aforementioned FIFO) - a heapq of scheduled items, sorted by the time they are due - a data structure to keep track of I/O callbacks (typically a selector, except when using IOCP on Windows) Much hand-wringing went into deciding what to do with callbacks put into the ready queue by call_soon() while step 4 above is running. The decision was *not* to run these immediately but to loop back to the top, using a deadline of zero for the I/O wait. This favors responding to I/O over running callbacks, but still runs the first wave of callbacks immediately without checking back for more I/O. That said, I am very excited to have this functionality. I have been sticking with Python 2 for now, but this feature may entice me to make the switch. That was part of the point. :-) -- Russell -- Forwarded message -- From: Victor Stinner victor.stin...@gmail.com Date: Sat, Feb 8, 2014 at 2:38 PM Subject: [python-tulip] Need help to finish asyncio documentation
[Python-Dev] [RELEASED] Python 3.4.0 release candidate 1
On behalf of the Python development team, I'm delighted to announce the first release candidate of Python 3.4. This is a preview release, and its use is not recommended for production settings. Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes. Major new features and changes in the 3.4 release series include: * PEP 428, a pathlib module providing object-oriented filesystem paths * PEP 435, a standardized enum module * PEP 436, a build enhancement that will help generate introspection information for builtins * PEP 442, improved semantics for object finalization * PEP 443, adding single-dispatch generic functions to the standard library * PEP 445, a new C API for implementing custom memory allocators * PEP 446, changing file descriptors to not be inherited by default in subprocesses * PEP 450, a new statistics module * PEP 451, standardizing module metadata for Python's module import system * PEP 453, a bundled installer for the *pip* package manager * PEP 454, a new tracemalloc module for tracing Python memory allocations * PEP 456, a new hash algorithm for Python strings and binary data * PEP 3154, a new and improved protocol for pickled objects * PEP 3156, a new asyncio module, a new framework for asynchronous I/O Python 3.4 is now in feature freeze, meaning that no new features will be added. The final release is projected for mid-March 2014. To download Python 3.4.0rc1 visit: http://www.python.org/download/releases/3.4.0/ Please consider trying Python 3.4.0rc1 with your code and reporting any new issues you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings, Release Manager larry at hastings.org (on behalf of the entire python-dev team and 3.4's contributors) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
