> Speaking for myself, these features are generally useful,
> and are so even without the new integer literal syntax.
I'm curious how these are useful to you in Py2.6 where
they are not invertible. In Py3.0, we can count on
x == int(bin(x), 2)
x == eval(bin(x))
I don't see how these could work in Py2.6 without
changing the parser and changing the int() function.
Why would you ever want to create a string like
'0o144' when there is no way to convert the string
back into a value?
Having both 0123 and 0o123 in the same version of
language will create a confused mess, IMO.
We should draw the line on Py3.0 backports whenever
the two different models would be conflated
(i.e. str/unicode vs bytes/text or 0123 vs 0o123).
On behalf of the Python development team and the Python community, I'm
happy to announce the release of Python 2.5.2 (FINAL).
This is the second bugfix release of Python 2.5. Python 2.5 is now in
bugfix-only mode; no new features are being added. According to the
release notes, over 100 bugs and patches have been addressed since
Python 2.5.1, many of them improving the stability of the interpreter,
and improving its portability.
This is a production release of Python, and should be a painless
upgrade from 2.5.1 or 2.5. Since the release candidate, we have backed
out test cases that were incorrect on 64-bit systems, and fixed
another stability problem. See the release notes for more.
For more information on Python 2.5.2, including download links for
various platforms, release notes, and known issues, please see:
Highlights of this new release include:
Bug fixes. According to the release notes, at least 100 have been fixed.
Highlights of the previous major Python release (2.5) are available
from the Python 2.5 page, at
Enjoy this release,
Martin v. Loewis
Python Release Manager
(on behalf of the entire python-dev team)
I'm trying to extend the base ftplib module to add SSL/TLS support as
described in RFC-4217 (see also issue 2054).
RFC-4217 defines a certain command ("CCC") which permit to return to a
plain text socket state without closing the connection.
That is useful since that, being FTP a port-hopping protocol (i.e.
data channels may use a random port chosen during the communication),
firewalls need to read passing packets to allow the secondary data
I've read through ssl.py but I didn't notice anything useful.
It seems that ssl.SSLSocket class does not provide any method/facility
to switch back to a plain text socket state.
May I chime in? :-)
Gents, the current implementation of Python's memory management
is really fine and most problems it used to have in the past
have been fixed in recent years (at least the ones I know of).
Probably the only one left, indeed, is the potential unbounded
growth of int/float objects' freelists (beyond the shared cache
of small ints). Yet, this seems to be a questionable problem
because any change in the freelists' management will invariably
slow down their allocation. By how much, I don't know, but
whether you fallback to pymalloc above a certain threshold or
use something else, the change will have a generic perf hit.
The explanation is simple: you can't beat the free list scheme
performance when you have frequent short bursts of allocations
and deallocations, which is the typical Python pattern observed
on New() & DECREF() calls.
BTW if you have 2 AMD combos showing speedups noone can explain
in an obvious way, then it's a cache effect.
Optimizing pymalloc for non-standard byte-sizes is a no go, and
although I've seen suggestions for further optimizations tailored
to ints and floats, I haven't seen anyone spelling out what that
optimization of pymalloc would consist of.
MAL's suggestion to preallocate a pymalloc pool cache for certain
object sizes is something I actually implemented in the earliest
versions of pymalloc, but eventually dropped in favor of the
current dynamic, on-request allocation because pre-allocating pools
(and initializing the free lists) costs time and in general leads
to degraded performance in the average case. I can't perf this
now to prove it, but that was very clear at the time when I wrote
the original stuff and applied the regression test on it.
So I would kindly suggest to get down to the only problem (if any)
which is the uncontrolled growth of the specialized freelists, the
shared int cache notwithstanding. If you can limit a degenerative
growth without a noticeable generic perf sacrifice, that would
sound like an improvement to me, but so far I haven't seen any
And, of course, if the int/float freelist scheme was a real issue
we would have probably heard of it by now in a very sound way.
Apologies for the bad formatting. Here's a repost with shorter lines.
I'd like to draw your attention to some of the work that's been going on in
the trunk-math branch. Christian Heimes and I have been working on various
aspects of Python mathematics, and we're hoping to get at least some of this
work into Python 2.6/3.0. Most of the changes are completed or nearly
complete, and 2.6/3.0 isn't very far away, so it seems like a good time to
try to get some feedback from python-dev.
Here's an overview of the changes (overview originally written by Christian,
edited and augmented by me. I hope Christian will step in and correct me if
I misrepresent him or his work here.) Many of the changes were motivated by
Christian's work (already in the trunk) in making infinities and nans more
accessible and portable for Python users. (See issue #1640.)
* Structural reorganization: there are new files Include/pymath.h and
Objects/pymath.c with math-related definitions and replacement functions for
platforms without copysign, log1p, hypot and inverse hyperbolic functions.
* New math functions: inverse hyperbolic functions (acosh, asinh, atanh).
* New float methods: is_finite, is_inf, is_integer and is_nan.
* New cmath functions: phase, polar and rect, isinf and isnan.
* New complex method: is_finite.
* Work on math and cmath functions to make them handle special values
(infinities and nans) and floating-point exceptions according to the C99
standard. The general philosophy follows the ideas put forth by Tim Peters
and co. many moons ago. and repeated in the issue #1640 thread more
recently: where the C99 standard (or IEEE 754) specifies raising 'invalid'
or 'divide-by-zero' Python should raise a ValueError. Where the C99
standard specifies raising 'overflow' Python should raise OverflowError.
'underflow' and 'inexact' flags are ignored. From a user's perspective,
this means that infinities and nans are never produced by math or cmath
operations on finite values (but see below). sqrt(-1) will always raise
ValueError, instead of returning a NaN. See issue #711019 and the resulting
warning at the bottom of the math module documentation. Although
complex_abs doesn't live in cmathmodule.c, it was also fixed up this way.
* The cmath module has been rescued: it's no longer numerically unsound
(see issue #1381). For the majority of functions (sin, cos, tan, sinh,
cosh, tanh, asin, acos, atan, asinh, acosh, atanh, exp, sqrt) the real and
imaginary parts of the results are always within a few ulps of the true
values. (In extensive but non-exhaustive testing I haven't found errors of
more than 5 ulps in either the real or imaginary parts for these functions.)
For log and log10 the errors can be larger when the argument has absolute
value close to 1; this seems pretty much unavoidable without using
multiple-precision arithmetic. pow and two-argument log are less accurate;
again, this is essentially unavoidable without adding hundreds of extra
lines of code.
* Many more tests. In addition to a handful of extra test_* methods in
test_math and test_cmath, there are over 1700 testcases (in a badly-named
file Lib/test/cmath.ctest) for the cmath and math functions, with a testcase
format inspired in no small part by the decimal .decTest file format. Most
of the testcase values were produced independently of Python using MPFR and
interval arithmetic (C code available on request); some were created by
* There's a per-thread state for division operator. In IEEE 754 mode 1./0.
and 1.%0. return INF and 0./0. NAN. The contextlib has a new context
"ieee754" and the math lib set_ieee754/get_ieee754 (XXX better place for the
* We've used the C99 standard (especially Annex F and Annex G) as a
reference for deciding what the math and cmath functions should do, wherever
possible. It seems to make sense to choose to follow some standard,
essentially so that all the hard decisions have been thought through
thoroughly by a group of experts. Two obvious choices are the C99 standard
and IEEE 754(r); for almost all math issues the two say essentially the same
thing. C99 has the advantage that it includes specifications for complex
math, while IEEE 754(r) does not. (Actually, I've been using draft version
N1124 of the C99 standard, not the standard itself, since I'm too cheap to
pay up for a genuine version. Google 'N1124' for a copy.)
* I'm offering to act as long-term maintainer for the cmath module, if
* The most interesting and exciting feature, by far (in my opinion) is the
last one. By way of introduction, here's a snippet from Tim Peters, in a
answering a question from Michael Hudson about 1e300*1e300 and inf/inf.
"I believe Python should raise exceptions in these cases by default,
because, as above, they correspond to the overflow and invalid-operation
signals respectively, and Python should raise exceptions on the overflow,
invalid-operation, and divide-by-0 signals by default. But I also believe
Python _dare not_ do so unless it also supplies sane machinery for disabling
traps on specific signals (along the lines of the relevant standards here).
Many serious numeric programmers would be livid, and justifiably so, if they
couldn't get non-stop mode back. The most likely x-platfrom accident so far
is that they've been getting non-stop mode in Python since its beginning."
Christian has found a simple, elegant and practical way to make it possible
for Python to raise these exceptions by default, while also allowing serious
numeric users access to non-stop mode---i.e., a mode that generates inf from
1/0 instead of raising a Python exception. (I had a much more elaborate
plan in mind, involving a thread-local context similar to Decimal's, with
control over individual traps and flags. Christian's solution is far more
practical.) The idea is that any arithmetic operating under a "with
ieee754:" acts like arithmetic on an IEEE 754 platform with no traps
enabled: invalid operations like sqrt(-1) produce a nan, division by zero
produces an infinity, etc. No Python exceptions related to floating-point
See the thread started by Neal Becker
entitled "Turn off ZeroDivisionError?" for a recent discussion of these
I fear that the per-thread state change seems like something where a PEP
might be necessary; it's also not clear right now that Christian and I have
exactly the same goals here (discussion is ongoing). But I hope that the
rest of the changes are uncontroversial enough to merit consideration for
possible inclusion in 2.6/3.0.
I have prepared a request for enhancement for distutils, together with its
patch that also adds more tests for the package.
This was discussed in catalog-sig, and explained here :
http://wiki.python.org/moin/EnhancedPyPI (see pypirc section). I have
followed Brett Cannon's slides to make the patch on the 2.6 trunk (great doc
I would like to propose this rfe tomorrow at the bug day, amongst other bugs
I can try to work on.
But I don't know if I should propose it here first since it was previously
discussed on catalog-sig,
so here it is :)
View this message in context: http://www.nabble.com/Tomorrow%27s-bug-day-and-issue--1858-tp15634227p15634…
Sent from the Python - python-dev mailing list archive at Nabble.com.
Being a python dev newbie, I look in http://www.python.org/dev/ for
some guide to write unit tests in python and I can't find any.
Specifically, I'd like to know about files managements in tests. Is
every test expected to clean after itself, or is there an automatic
cleanup mechanism in place? Even more specifically, I'd like to create
a test for the proposed patch in http://bugs.python.org/issue2127 so I
need to create a subdir with non-ascii character in it, then connect
to a db in it. So, do I need to do the cleanup in the test? Is there a
special path I can write to that will automatically be cleaned up? If
not, wouldn't it be a good idea to have one?
I guess I could find the answer in regrtest.py, but frankly, this unit
is a little bit overwhelming.
If there is no guide, am I the only one to think it would be a good
idea to have one (Yeah, I could volunteer to write it)?
> I'm going to work on backporting PEP 3127, specifically
>the hex, oct(), and bin() builtins.
IMO, these should not be backported. They are strongly
associated with 3.0's new literal syntax. They don't
don't really fit in with 2.6 and don't make 2.6 any more
> Are you proposing just a list those modules
> or all module objects?
The idea is dead. Guido specified that the
dir() function returns a list of names for
which hasattr() will succeed.
I only brought this up because a colleague was
using dir() on modules to find-out about the API.
He was thrown-off by some of the entries in dir(logging).