Hello everybody! I hope you all had as great a time at Pycon 2010 as I did. No time to begin recovering though, we're on to Python 2.6.5 rc 1, which I would like to release on Monday. We have one showstopper still open, and I'll try to respond to that asap.
If there is anything else that absolutely should go into 2.6.5, now's the time to let me know. If there are no patches ready to be reviewed and landed though, you're probably running out of time. I will be very conservative about landing patches after rc1.
So far, Python timezone handling is far from "pythonic". There is no
function to get current UTC offset, intuitive API to get DST of
current time zone and whenever it is active, no functions to work with
internet timestamps (RFC 3339). In my case  it took about one month
and five people to get the right solution for a valid RFC 3339
timestamp. One of the reasons I see is that date/time functions are
implemented in C, they expose C API, and there are not many people who
can help and patch them.
I am sure many current Python users will appreciate UTC functions and
improved date/time API more than any new language features. That's why
I would like to propose this enhancements for a coding spring on
forthcoming PyCon. I am located in Europe and can't attend PyCon, but
I summarized date/time issues related to UTC below.
More open UTC-related Python issues:
http://bugs.python.org/issue1647654 No obvious and correct way to get
the time zone offset
http://bugs.python.org/issue1667546 Time zone-capable variant of time.localtime
http://bugs.python.org/issue7229 [PATCH] Manual entry for
time.daylight can be misleading
http://bugs.python.org/issue5094 datetime lacks concrete tzinfo
impl. for UTC
http://bugs.python.org/issue7584 datetime.rfcformat() for Date and
Time on the Internet (support RFC 3339, ISO 8601 datetime format)
http://bugs.python.org/issue665194 datetime-RFC2822 roundtripping
http://bugs.python.org/issue6280 calendar.timegm() belongs in time
module, next to time.gmtime()
All solutions require C expertise. If it will be impossible to find
experts able to modify current implementation, then perhaps it could
be real to create Python stub for coding solution in Python later?
FWIW, this proposal is from my other issue about problems with Python
date/time in separate tracker on Google Code .
 http://bugs.python.org/issue7582 [patch] diff.py to use iso timestamp
 http://code.google.com/p/rainforce/issues/detail?id=10 python:
date/time is a mess
Named tuples have compatibility code to enable them to work on
IronPython without frame support, but unfortunately this doesn't allow
pickling / unpickling of named tuples.
One fix is to manually set __module__ on the named tuples once created,
but I wonder if it would be possible to change the API to better support
this - perhaps a default __module__ or providing an optional argument to
specify it at creation time?
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
I am a semi-regular contributor for Python: I have contributed many patches
since end of last year, some of them were reviewed by Antoine.
Lately, he suggested that I should apply for commit rights.
Some of the accepted patches:
- Fix refleaks in py3k branch (#5596)
- Extend stringlib fastsearch for various methods of bytes, bytearray
and unicode objects (#7462 and #7622)
- Various documentation patches, including FAQ
Recently, I worked with Ezio to fix some tests and to silence py3k warnings
in the test suite (#7092). And I am in touch with Fredrik to release
ElementTree 1.3 and port it to Python 2.7 (#6472).
As a final note, I would like to highlight a small script in the same spirit
as Pyflakes: pep8.py
I've contributed few patches for the version 0.5, released a week ago:
On Feb 03, 2010, at 01:07 PM, Antoine Pitrou wrote:
>Well, I don't think we need another transition... Just keep __file__ for the
>source file, and add a __cache__ or __compiled__ attribute for the compiled
>Since there might be several compiled files for a single source file (for
>example, a .pyc along with a JITted native .so), __cache__ should probably be
>a tuple rather than a string.
I'm going to call the attribute __cached__ and leave its contents
implementation defined. For CPython it will be the path to the pyc file if it
exists (or was written), or the path to where the pyc file /would/ exist if
the source lives on a read-only file system or -B/$PYTHONDONTWRITEBYTECODE is
For alternative implementations of Python that compose modules from multiple
sources, __cached__ can be a tuple.
We've recently run into an issue with subprocess on Solaris, as
described (by an earlier reporter) in issue #7242. The patch there
solves our problem, and has been verified to work by other users as
well. What's the status of the ticket? Is there anything I can do to
help move it forward to be included in a patch release for 2.6?
I would like to have a feature on platform module (or sys or
somewhere) that can tell distutils or distutils2 that this platform
(be it PyPy or Jython) is not able to compile any C module. The
purpose of this is to make distutils bail out in more reasonable
manner than a compilation error in case this module is not going to
work on anything but CPython.
What do you think?
Would there be any interest in accepting IronPython's in-house benchmarks into this repository as well? Internally we run the usual suspects (PyStone, PyBench, etc), but we also have a plethora of custom benchmarks we've written that also happen to run under CPython.
Date: Mon, 22 Feb 2010 15:17:09 -0500
From: Collin Winter <collinwinter(a)google.com>
To: Daniel Stutzbach <daniel(a)stutzbachenterprises.com>
Cc: Dirkjan Ochtman <djc.ochtman(a)gmail.com>, Python Dev
Subject: Re: [Python-Dev] Mercurial repository for Python benchmarks
Content-Type: text/plain; charset=ISO-8859-1
On Sun, Feb 21, 2010 at 9:43 PM, Collin Winter <collinwinter(a)google.com> wrote:
> Hey Daniel,
> On Sun, Feb 21, 2010 at 4:51 PM, Daniel Stutzbach
> <daniel(a)stutzbachenterprises.com> wrote:
>> On Sun, Feb 21, 2010 at 2:28 PM, Collin Winter <collinwinter(a)google.com>
>>> Would it be possible for us to get a Mercurial repository on
>>> python.org for the Unladen Swallow benchmarks? Maciej and I would like
>>> to move the benchmark suite out of Unladen Swallow and into
>>> python.org, where all implementations can share it and contribute to
>>> it. PyPy has been adding some benchmarks to their copy of the Unladen
>>> benchmarks, and we'd like to have as well, and Mercurial seems to be
>>> an ideal solution to this.
>> If and when you have a benchmark repository set up, could you announce it
>> via a reply to this thread?? I'd like to check it out.
> Will do.
The benchmarks repository is now available at
http://hg.python.org/benchmarks/. It contains all the benchmarks that
the Unladen Swallow svn repository contains, including the beginnings
of a README.txt that describes the available benchmarks and a
quick-start guide for running perf.py (the main interface to the
benchmarks). This will eventually contain all the information from
http://code.google.com/p/unladen-swallow/wiki/Benchmarks, as well as
guidelines on how to write good benchmarks.
If you have svn commit access, you should be able to run `hg clone
ssh://email@example.com/repos/benchmarks`. I'm not sure how to get
read-only access; Dirkjan can comment on that.
- Replace the static snapshots of 2to3, Mercurial and other hg-based
projects with clones of the respective repositories.
- Fix the 2to3 and nbody benchmarks to work with Python 2.5 for Jython and PyPy.
- Import some of the benchmarks PyPy has been using.
Any access problems with the hg repo should be directed to Dirkjan.
Thanks so much for getting the repo set up so fast!
http://bugs.python.org/issue7094 proposes adding "alternate" formatting
 to floating point new-style formatting (float.__format__ and
probably Decimal.__format__). I'd like to add this to make automated
translation from %-formatting strings to str.format strings easier.
Would this be allowed under the moratorium? I think it falls under the
Case-by-Case Exemptions section, but let me know what you think.
 Alternate formatting for floats modifies how trailing zeros and
decimal points are treated. See