=================================================
PyPy3 2.4 - Snow White
=================================================
We're pleased to announce PyPy3 2.4, which contains significant performance
enhancements and bug fixes.
You can download the PyPy3 2.4.0 release here:
http://pypy.org/download.html
PyPy3 Highlights
================
Issues reported with our previous release were fixed after reports from users on
our new issue tracker at https://bitbucket.org/pypy/pypy/issues or on IRC at
#pypy. Here is a summary of the user-facing PyPy3 specific changes:
* Better Windows compatibility, e.g. the nt module functions _getfinalpathname
& _getfileinformation are now supported (the former is required for the
popular pathlib library for example)
* Various fsencode PEP 383 related fixes to the posix module (readlink, uname,
ttyname and ctermid) and improved locale handling
* Switched default binary name os POSIX distributions to 'pypy3' (which
symlinks to to 'pypy3.2')
* Fixed a couple different crashes related to parsing Python 3 source code
Further Highlights (shared w/ PyPy2)
====================================
Benchmarks improved after internal enhancements in string and
bytearray handling, and a major rewrite of the GIL handling. This means
that external calls are now a lot faster, especially the CFFI ones. It also
means better performance in a lot of corner cases with handling strings or
bytearrays. The main bugfix is handling of many socket objects in your
program which in the long run used to "leak" memory.
We fixed a memory leak in IO in the sandbox_ code
We welcomed more than 12 new contributors, and conducted two Google
Summer of Code projects, as well as other student projects not
directly related to Summer of Code.
* Reduced internal copying of bytearray operations
* Tweak the internal structure of StringBuilder to speed up large string
handling, which becomes advantageous on large programs at the cost of slightly
slower small *benchmark* type programs.
* Boost performance of thread-local variables in both unjitted and jitted code,
this mostly affects errno handling on linux, which makes external calls
faster.
* Move to a mixed polling and mutex GIL model that make mutlithreaded jitted
code run *much* faster
* Optimize errno handling in linux (x86 and x86-64 only)
* Remove ctypes pythonapi and ctypes.PyDLL, which never worked on PyPy
* Classes in the ast module are now distinct from structures used by
the compiler, which simplifies and speeds up translation of our
source code to the PyPy binary interpreter
* Win32 now links statically to zlib, expat, bzip, and openssl-1.0.1i.
No more missing DLLs
* Many issues were resolved_ since the 2.3.1 release in June
.. _`whats-new`: http://doc.pypy.org/en/latest/whatsnew-2.4.0.html
.. _resolved: https://bitbucket.org/pypy/pypy/issues?status=resolved
.. _sandbox: http://doc.pypy.org/en/latest/sandbox.html
We have further improvements on the way: rpython file handling,
numpy linalg compatibility, as well
as improved GC and many smaller improvements.
Please try it out and let us know what you think. We especially welcome
success stories, we know you are using PyPy, please tell us about it!
Cheers
The PyPy Team
Hi all,
https://github.com/python/cpython is now live as a semi-official, *read
only* Github mirror of the CPython Mercurial repository. Let me know if you
have any problems/concerns.
I still haven't decided how often to update it (considering either just N
times a day, or maybe use a Hg hook for batching). Suggestions are welcome.
The methodology I used to create it is via hg-fast-export. I also tried to
pack and gc the git repo as much as possible before the initial Github push
- it went down from almost ~2GB to ~200MB (so this is the size of a fresh
clone right now).
Eli
P.S. thanks Jesse for the keys to https://github.com/python
Hi,
We were working on IDLE related issue [1] , when I noticed that the
review tool does not detect all affected files for the
cfg-ext-34-2.diff patch uploaded by Terry Reedy. Version 1 of the same
patch does not have this issue - the only difference between the two
files being line endings and time stamps. Also see Terry Reedy's
message in the same issue. [3]
Could someone please let me know if this is normal behavior or not?
[1] - http://bugs.python.org/issue3068
[2] - http://bugs.python.org/file36904/cfg-ext-34-2.diff
[3] - http://bugs.python.org/issue3068#msg229315
--
Regards
Saimadhav Heblikar
A big security breach of SSL 3.0 just dropped a little while ago (named POODLE).
With this there is now no ability to securely connect via SSL 3.0. I believe
that we should disable SSL 3.0 in Python similarly to how SSL 2.0 is disabled,
where it is disabled by default unless the user has explicitly re-enabled it.
The new attack essentially allows reading the sensitive data from within a SSL
3.0 connection stream. It takes roughly 256 requests to break a single byte so
the attack is very practical. You can read more about the attack here at the
google announcement [1] or the whitepaper [2].
[1] http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiti…
[2] https://www.openssl.org/~bodo/ssl-poodle.pdf
---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Sat, Oct 11, 2014 at 4:07 AM, Steve Holden <steve(a)holdenweb.com> wrote:
> I found the following code appeared to work without any issues:
>
> %matplotlib inline
> import numpy as np
> import matplotlib.pyplot as plt
>
> import sys
> import time
> from IPython.display import display, clear_output
>
> x=np.linspace(0,6,100)
> for t in np.linspace(0,20,100):
> clear_output(wait=True)
> f=plt.figure(figsize=(10,10))
> plt.plot(np.sin(x)*np.sin(t),'-o')
> plt.gca().set_ylim([-1,1])
> display(f)
> plt.close()
>
> Further queries should be sent to the python-dev list, as this one is being
> phased out.
>
Running this code makes a working animation, but watching the memory
usage of the python2.7 process it is clear there is a memory leak - it
starts around 150 M and climbs to 300 M. Running for longer keeps
this going. I think the figures are being generated, cleared in the
notebook, but still existing somehow in the background. Is there a
way to determine if this is happening? Is there a proper way to write
the animation to avoid this?
thanks!
Brian Blais
-----------------
bblais(a)gmail.com
http://web.bryant.edu/~bblais
Hi all,
I've just updated the PEP to reflect the API suggestions from Nick, and the
fact that the necessary changes to urllib were landed.
I think this is ready for pronouncement, Guido?
Cheers,
Alex
Hi,
Windows is not the primary target of Python developers, probably
because most of them work on Linux. Official Python binaries are
currently built by Microsoft Visual Studio. Even if Python developers
get free licenses thanks for Microsoft, I would prefer to use an open
source compiler if it would be possible. So *anyone* can build Python
from scatch. I don't like the requirement of having a license to build
Python. The free version (Visual Studio Express) only supports 32-bit
and doesn't support PGO build (Profile-Guided Optimizations, which are
disabled if I remember correctly because of compiler bugs).
I know that it's hard to replace Visual Studio. I don't want to do it
right now, but I would like to discuss that with you.
=== Open Watcom
Jeffrey Armstrong is working on the Python support of OpenWatcom(v2), see:
http://lightningpython.org/https://bitbucket.org/ArmstrongJ/lightning-python
This compiler was initially written on MS-DOS in 32-bit, but it now
supports Windows and Linux as well. The 64-bit mode is new and
experimental. The Open Watcom "v2" project is actively developed at:
https://github.com/open-watcom/open-watcom-v2/
On Linux, Open Watcom don't support dynamic linking. On Windows, it
uses its own C library. I'm not sure that Open Watcom is the best
choice to build Python on Windows.
=== MinGW
Some people tried to compile Python. See for example:
https://bitbucket.org/puqing/python-mingw
We even got some patches:
http://bugs.python.org/issue3871 (rejected)
See also:
https://stackoverflow.com/questions/15365249/build-python-with-mingw-and-gcc
MinGW reuses the Microsoft C library and it is based on GCC which is
very stable, actively developed, supports a lot of archiectures, etc.
I guess that it should be possible to reuse third party GCC tools like
the famous GDB debugger?
=== Cywin
Cygwin was written compile POSIX applications on Windows and it
provides a DLL for that. Python doesn't need that, it uses directly
the Windows native API. I don't think that we should use Cygwin.
=== Clang
I have no idea of the support of Clang on Windows. Which C library is
used? I found some pages:
http://clang.llvm.org/docs/MSVCCompatibility.htmlhttp://blog.llvm.org/2014/07/clangllvm-on-windows-update.html
This article starts with "It’s time for an update on Clang’s support
for building native Windows programs, compatible with Visual C++!".
Good.
I see binaries for Windows.
=== Other compilers?
Do you know other C compiler which can be used to build Python?
=== Requirements
A compiler alone is not enough. To develop, we need tools to automate
the compilation, we need a good debugger, and other similar tools.
(Personally, I don't need an IDE. I mostly write code on Linux and
only run Windows to ensure that my code works on Windows before
pushing it.)
IMO 64-bit support is simply required (we currently provide 64-bit
binaries on Windows). Supporting ARM can be interesting for Windows 8
and Windows 9.
Some parts of Python are low-level like ctypes with libffi. The
_decimal module uses libmpdec which is highly optimized. In short, the
goal is to have a full working standard Python library.
It's probably better to reuse the Microsoft C library instead of
having to embed a different C library. What do you think?
What about the Python stable ABI? Would it be broken if we use a
different compiler?
What about third party Python extensions?
What about external dependencies like gzip, bz2, Tk, Tcl, OpenSSL, etc.?
Victor
