I'm an advocate of getting users and projects to move to modern Python
versions. I believe dropping support for end-of-lifed Python versions is
important for the health of the Python community. If you've done any
amount of Python 3 porting work, you know things get much harder the
more 2.x legacy versions you need to support.
I led the successful charge to drop support for Python 2.6 and below
from Firefox's build system. I failed to win the argument that Mercurial
should drop 2.4 and 2.5 [1]. A few years ago, I started a similar
conversation with the LLVM project [2]. I wrote a blog post on the
subject [3] that even got Slashdotted [4] (although I don't think that's
the honor it was a decade ago).
While much of the opposition to dropping Python <2.7 stems from the RHEL
community (they still have 2.4 in extended support and 2.7 wasn't in a
release until a few weeks ago), a common objection from the users is "I
can't install a different Python" or "it's too difficult to install a
different Python." The former is a legit complaint - if you are on
shared hosting and don't have root, as easy as it is to add an alternate
package repository that provides 2.7 (or newer), you don't have the
permissions so you can't do it.
This leaves users with attempting a userland install of Python.
Personally, I think installing Python in userland is relatively simple.
Tools like pyenv make this turnkey. Worst case you fall back to
configure + make. But I'm an experienced developer and have a compiler
toolchain and library dependencies on my machine. What about less
experienced users or people that don't have the necessary build
dependencies? And, even if they do manage to find or build a Python
distribution, we all know that there's enough finicky behavior with
things like site-packages default paths to cause many headaches, even
for experienced Python hackers.
I'd like to propose a solution to this problem: a pre-built distribution
of CPython for Linux available via www.python.org in the list of
downloads for a particular release [5]. This distribution could be
downloaded and unarchived into the user's home directory and users could
start running it immediately by setting an environment variable or two,
creating a symlink, or even running a basic installer script. This would
hopefully remove the hurdles of obtaining a (sane) Python distribution
on Linux. This would allow projects to more easily drop end-of-life
Python versions and would speed adoption of modern Python, including
Python 3 (because porting is much easier if you only have to target 2.7).
I understand there may be technical challenges with doing this for some
distributions and with producing a universal binary distribution. I
would settle for a binary distribution that was targeted towards RHEL
users and variant distros, as that is the user population that I
perceive to be the most conservative and responsible for holding modern
Python adoption back.
[1]
http://permalink.gmane.org/gmane.comp.version-control.mercurial.devel/68902
[2] http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/056545.html
[3]
http://gregoryszorc.com/blog/2014/01/08/why-do-projects-support-old-python-…
[4]
http://developers.slashdot.org/story/14/01/09/1940232/why-do-projects-conti…
[5] https://www.python.org/download/releases/2.7.7/
Hello python devs,
I was recently in need of some faster caching and thought this would be a
good opportunity to familiarize myself with the Python/C api so I wrote a C
extension for the lru_cache in functools. The source is at
https://github.com/pbrady/fastcache.git and I've posted it as a package on
PyPI (fastcache). There are some simple benchmarks on the github page
showing about 9x speedup. I would like to submit this for incorporation
into the standard library. Is there any interest in this? I suspect it
probably requires some changes/cleanup especially since I haven't addressed
thread-safety at all.
Thanks,
Peter.
P.S. This was the motivation for the faster caching
https://github.com/sympy/sympy/pull/7464.
In article <3gz1lK1lYkz7Lk0(a)mail.python.org>,
jesus.cea <python-checkins(a)python.org> wrote:
> http://hg.python.org/cpython/rev/cf156cfb12e7
> changeset: 91398:cf156cfb12e7
> branch: 3.3
> parent: 91384:92d691c3ca00
> user: Jesus Cea <jcea(a)jcea.es>
> date: Wed Jun 25 13:05:31 2014 +0200
> summary:
> Closes #20872: dbm/gdbm/ndbm close methods are not documented
The 3.3 branch is open only to security fixes. Please don't backport
other patches to there.
https://docs.python.org/devguide/devcycle.html#summary
--
Ned Deily,
nad(a)acm.org
With PEP 466 and the constant flow of OpenSSL security fixes
which are currently being handled via Python patch level releases,
we will soon reach 2.7.10 and quickly go beyond that (also see
http://bugs.python.org/issue21308).
This opens up a potential backwards incompatibility with existing
tools that assume the Python release version number to use the
"x.y.z" single digit approach, e.g. code that uses sys.version[:5]
for the Python version or relies on the lexicographic ordering
of the version string (sys.version > '2.7.2').
Some questions we should probably ask ourselves (I've added my
thoughts inline):
* Is it a good strategy to ship to Python releases for every
single OpenSSL security release or is there a better way to
handle these 3rd party issues ?
I think we should link to the OpenSSL libs dynamically rather
than statically in Python 2.7 for Windows so that it's possible
to provide drop-in updates for such issues.
* Should we try to avoid two digit patch level release numbers
by using some other mechanism such as e.g. a release date
after 2.7.9 ?
Grepping through our code, this will introduce some breakage,
but not much. Most older code branches on minor versions,
not patch levels. More recent code uses sys.python_info so
is not affected.
* Should we make use of the potential breakage with 2.7.10
to introduce a new Windows compiler version for Python 2.7 ?
I think this would be a good chance to update the compiler
to whatever we use for Python 3 at the time.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jun 21 2014)
>>> Python Projects, Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
2014-06-17: Released eGenix PyRun 2.0.0 ... http://egenix.com/go58
2014-06-09: Released eGenix pyOpenSSL 0.13.3 ... http://egenix.com/go57
2014-07-02: Python Meeting Duesseldorf ... 11 days to go
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
I am banned from tracker, so I post the bug here:
Normal Windows behavior:
>hg status --rev ".^1"
M mercurial\commands.py
? pysptest.py
>hg status --rev .^1
abort: unknown revision '.1'!
So, ^ is an escape character. See
http://www.tomshardware.co.uk/forum/35565-45-when-special-command-line
But subprocess doesn't escape it, making cross-platform command fail on
Windows.
---[cut pysptest.py]--
import subprocess as sp
# this fails with
# abort: unknown revision '.1'!
cmd = ['hg', 'status', '--rev', '.^1']
# this works
#cmd = 'hg status --rev ".^1"'
# this works too
#cmd = ['hg', 'status', '--rev', '.^^1']
try:
print sp.check_output(cmd, stderr=sp.STDOUT, shell=True)
except Exception as e:
print e.output
------------------------------
--
anatoly t.
=====================
PyPy3 2.3.1 - Fulcrum
=====================
We're pleased to announce the first stable release of PyPy3. PyPy3
targets Python 3 (3.2.5) compatibility.
We would like to thank all of the people who donated_ to the `py3k proposal`_
for supporting the work that went into this.
You can download the PyPy3 2.3.1 release here:
http://pypy.org/download.html#pypy3-2-3-1
Highlights
==========
* The first stable release of PyPy3: support for Python 3!
* The stdlib has been updated to Python 3.2.5
* Additional support for the u'unicode' syntax (`PEP 414`_) from Python 3.3
* Updates from the default branch, such as incremental GC and various JIT
improvements
* Resolved some notable JIT performance regressions from PyPy2:
- Re-enabled the previously disabled collection (list/dict/set) strategies
- Resolved performance of iteration over range objects
- Resolved handling of Python 3's exception __context__ unnecessarily forcing
frame object overhead
.. _`PEP 414`: http://legacy.python.org/dev/peps/pep-0414/
What is PyPy?
==============
PyPy is a very compliant Python interpreter, almost a drop-in replacement for
CPython 2.7.6 or 3.2.5. It's fast due to its integrated tracing JIT compiler.
This release supports x86 machines running Linux 32/64, Mac OS X 64, Windows,
and OpenBSD,
as well as newer ARM hardware (ARMv6 or ARMv7, with VFPv3) running Linux.
While we support 32 bit python on Windows, work on the native Windows 64
bit python is still stalling, we would welcome a volunteer
to `handle that`_.
.. _`handle that`: http://doc.pypy.org/en/latest/windows.html#what-is-missing-for-a-full-64-bi…
How to use PyPy?
=================
We suggest using PyPy from a `virtualenv`_. Once you have a virtualenv
installed, you can follow instructions from `pypy documentation`_ on how
to proceed. This document also covers other `installation schemes`_.
.. _donated: http://morepypy.blogspot.com/2012/01/py3k-and-numpy-first-stage-thanks-to.h…
.. _`py3k proposal`: http://pypy.org/py3donate.html
.. _`pypy documentation`: http://doc.pypy.org/en/latest/getting-started.html#installing-using-virtual…
.. _`virtualenv`: http://www.virtualenv.org/en/latest/
.. _`installation schemes`: http://doc.pypy.org/en/latest/getting-started.html#installing-pypy
Cheers,
the PyPy team
--
Philip Jenvey
Hello,
I was pleasantly surprised with the response to recent post about
MicroPython implementation details
(https://mail.python.org/pipermail/python-dev/2014-June/134718.html). I
hope that discussion means that posts about alternative implementations
are not unwelcome here, so I would like to bring up another (of many)
issues we faced while implementing MicroPython.
execfile() builtin function was removed in 3.0. This brings few
problems:
1. It hampers interactive mode - instead of short and easy to type
execfile("file.py") one needs to use exec(open("file.py").read()). I'm
sure that's not going to bother a lot of people - after all, the
easiest way to execute a Python file is to drop back to shell and
restart python with file name, using all wonders of tab completion. But
now imagine that Python interpreter runs on bare hardware, and its REPL
is the only shell. That's exactly what we have with MicroPython's
Cortex-M port. But it's not really MicroPython-specific, there's
CPython port to baremetal either - http://www.pycorn.org/ .
2. Ok, assuming that exec(open().read()) idiom is still a way to go,
there's a problem - it requires to load entire file to memory. But
there can be not enough memory. Consider 1Mb file with 900Kb comments
(autogenerated, for example). execfile() could easily parse it, using
small buffer. But exec() requires to slurp entire file into memory, and
1Mb is much more than heap sizes that we target.
Comments, suggestions? Just to set a productive direction, please
kindly don't consider the problems above as MicroPython's. I very much
liked how last discussion went: I was pointed that
https://docs.python.org/3/reference/index.html is not really a CPython
reference, it's a *Python* reference, and there were even motion to
clarify in it some points which came out from MicroPython discussion.
So, what about https://docs.python.org/3/library/index.html - is it
CPython, or Python standard library specification? Assuming the latter,
what we have is that, by removal of previously available feature,
*Python* became less friendly for interactive usage and less scalable.
Thanks,
Paul mailto:pmiscml@gmail.com
Python Dev,
Andy here. I have a Windows product based on Python and I'm getting hammered to release a version that includes the fix in OpenSSL 1.0.1h. My product is built on a Windows system using Python installed from the standard Python installer at Python.org. I would be grateful if I could get some advice on my options. Will Python.org be releasing a Windows installer with the fix any time soon or will it be at the next scheduled release in November? If it is November, there's no way I can wait that long. Now what? Would it be best to build my own Python? Is it possible to drop in new OpenSSL versions on Windows without rebuilding Python? Looking for some guidance on how to handle these OpenSSL issues on Windows.
Thanks!
Andy Yates