Re: [Python-Dev] cpython: Issue #23752: When built from an existing file descriptor, io.FileIO() now only
Hi, 2015-03-30 8:06 GMT+02:00 Serhiy Storchaka : >> +What's New in Python 3.5.0 alpha 4? >> +=== > > Return time machine back Victor. Current version is 3.5.0a2+. Larry Hastings and Ned Deily told me that Larry is releasing Python 3.5 alpha 3. You can see their repository at: https://hg.python.org/releasing/3.5/ According to the PEP 478 - Python 3.5 Release Schedule, we are in time: 3.5.0 alpha 3: March 29, 2015 Maybe Misc/NEWS was not updated when the alpha 2 was released? It's always a mess to maintain this file... We should generate it from Mercurial changelogs instead. So is it correct to use "alpha 4" in Misc/NEWS? Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #23752: When built from an existing file descriptor, io.FileIO() now only
On 03/30/2015 12:30 AM, Victor Stinner wrote: So is it correct to use "alpha 4" in Misc/NEWS? It's the release manager's responsibility to update the version number in Misc/NEWS. As I finish up 3.5.0a3, I will be changing it to say "What's New in Python 3.5.0 alpha 4?". And I will change the release number in patchlevel.h to say "3.5.0a3+". I don't know why it is this way, but that's the way it is, and I assume there's a good reason for it. Since you don't have the 3.5.0a3 changes yet, no, it's not correct for you to put "alpha 4" into Misc/NEWS. Doing so would trip me up a little. The release process is mostly automated, although there are manual steps where the RM is guided through the process. Fixing up the heading in Misc/NEWS is one such manual step. FWIW, I have in the past bungled a release so badly that I missed making this change. I was happy to discover someone else had fixed it for me. So I'm not saying "nobody but the RM should ever touch it". But maybe you should wait a day or two after the release comes out before you start up your text editor. Cheers, //arry/ ___ Python-Dev mailing list [email protected] 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.5.0a3 is now available
On behalf of the Python development community and the Python 3.5 release team, I'm thrilled to announce the availability of Python 3.5.0a3. Python 3.5.0a3 is the third alpha release of Python 3.5, which will be the next major release of Python. Python 3.5 is still under heavy development, and is far from complete. This is a preview release, and its use is not recommended for production settings. Two important notes for Windows users about Python 3.5.0a3: * If you have previously installed Python 3.5.0a1, you may need to manually uninstall it before installing Python 3.5.0a3 (issue23612). * If installing Python 3.5.0a3 as a non-privileged user, you may need to escalate to administrator privileges to install an update to your C runtime libraries. You can find Python 3.5.0a3 here: https://www.python.org/downloads/release/python-350a3/ Happy hacking, //arry/ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] [RELEASED] Python 3.5.0a3 is now available
Hi, 2015-03-30 10:46 GMT+02:00 Larry Hastings : > On behalf of the Python development community and the Python 3.5 release > team, I'm thrilled to announce the availability of Python 3.5.0a3. Python > 3.5.0a3 is the third alpha release of Python 3.5, which will be the next > major release of Python. Python 3.5 is still under heavy development, and > is far from complete. Between alpha2 and alpha3, the implementation of the PEP 471 (os.scandir) and 475 (EINTR) made progress. For scandir, os.walk() now uses os.scandir() internally instead of os.listdir() and so should be (much) faster. These PEPs are very dependent on the platform, so I'm interested of feedback if you get any bug related to these PEPs. For example, Robert Collins told me that fixtures test started to hang. The reason is that time.sleep() was modified to restart on EINTR and fixtures test used an exception handler which expected time.sleep() to return on signal. The signal handler only modified a flag without raising an exception. Robert quickly fixed his test. I started to document EINTR changes in the documentation of each function, and I added a note in the "Porting to Python 3.5" section of What's New in Python 3.5: https://docs.python.org/dev/whatsnew/3.5.html#porting-to-python-3-5 By the way, Python now always requires a 64-bit signed integer type to work. Python internal functions now store timestamps as a number of nanoseconds in a 64-bit integer. It looks to be the case on all buildbots. Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: PEP 490 - Chain exceptions at C level
On 26 March 2015 at 22:30, Victor Stinner wrote: > Hi, > > Here is the first draft of my PEP to chain automatically exceptions at > C level in Python 3.5. Plain text version of the PEP below. HTML > version of the PEP: > >https://www.python.org/dev/peps/pep-0490/ > > It has already an implementation, the pyerr_chain.patch file attached to > http://bugs.python.org/issue23763 > > The patch is very short. I like the idea, but I think it would raise the priority of the proposed change to the display of chained exceptions in http://bugs.python.org/issue12535 That proposal suggests adding the line "" to the start of earlier tracebacks in the chain so you get an up front hint that a chained exception will be shown after the initial traceback. > Backward compatibility > == > > A side effect of chaining exceptions is that exceptions store > traceback objects which store frame objects which store local > variables. Local variables are kept alive by exceptions. A common > issue is a reference cycle between local variables and exceptions: an > exception is stored in a local variable and the frame indirectly > stored in the exception. The cycle only impacts applications storing > exceptions. > > The reference cycle can now be fixed with the new > ``traceback.TracebackException`` object introduced in Python 3.5. It > stores informations required to format a full textual traceback without > storing local variables. Also potentially worth noting here is "traceback.clear_frames()", introduced in 3.4 to explicitly clear local variables from a traceback: https://docs.python.org/3/library/traceback.html#traceback.clear_frames PEP 442 also makes it more likely that cycles will be cleared properly, even if some of the objects involved have __del__ methods: https://www.python.org/dev/peps/pep-0442/ However, I'll grant that neither of those can be backported the way that traceback.TracebackException can be. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
