I've already formatted the documentation for Python 2.3b1; please
don't touch the Doc directory until the final release has been
Fred L. Drake, Jr. <fdrake at acm.org>
PythonLabs at Zope Corporation
A while ago Paul Rubin proposed adding a Rijndael/AES module to 2.3.
(AES = Advanced Encryption Standard, a block cipher that's likely to
be around for a long time). Rubin wanted to come up with a nice
interface for the module, and has posted some notes toward it. I have
an existing implementation that's 2212 lines of code; I like the
interface, but opinions may vary. :)
Do we want to do anything about this for 2.3? A benefit is that AES
is useful, and likely to remain so for the next 20 years; a drawback
is that it might entangle the PSF in export-control legalities. I
vaguely recall the PSF getting some legal advice on this point; am I
misremembering? What was the outcome?
If AES gets added, rotor can be deprecated to encourage people to use
something better; patch is at <URL:http://www.python.org/sf/679505>.
Cerebral circuits in order. Physiognomy dubious.
-- K9 assesses the Doctor's condition, in "The Invasion of Time"
How do I make certain that FILE* parameters are only passed to these
functions if it is certain that they were created by the same library that
the Python runtime is using?
Last-second re changes don't appear to be going in the right direction
Running re_tests test suite
test_basic_re_sub (__main__.ReTests) ... ok
test_constants (__main__.ReTests) ... ok
test_escaped_re_sub (__main__.ReTests) ... ok
test_flags (__main__.ReTests) ... ok
test_limitations (__main__.ReTests) ... ERROR
test_pickling (__main__.ReTests) ... ok
test_qualified_re_split (__main__.ReTests) ... ok
test_qualified_re_sub (__main__.ReTests) ... ok
test_re_escape (__main__.ReTests) ... ok
test_re_findall (__main__.ReTests) ... ok
test_re_match (__main__.ReTests) ... ok
test_re_split (__main__.ReTests) ... ok
test_re_subn (__main__.ReTests) ... ok
test_search_star_plus (__main__.ReTests) ... ok
test_symbolic_refs (__main__.ReTests) ... ok
ERROR: test_limitations (__main__.ReTests)
Traceback (most recent call last):
File "../lib/test/test_re.py", line 182, in test_limitations
self.assertEqual(re.match('(x)*', 50000*'x').span(), (0, 50000))
File "C:\Code\python\lib\sre.py", line 132, in match
return _compile(pattern, flags).match(string)
RuntimeError: maximum recursion limit exceeded
I've been working a little on the trace module lately, trying to get it
to work correctly with Zope. One issue that remains open is how to
handle multi-threaded programs. The PEP below proposes a solution.
Title: Trace and Profile Support for Threads
Version: $Revision: 1.1 $
Last-Modified: $Date: 2002/08/30 04:11:20 $
Author: Jeremy Hylton <jeremy(a)alum.mit.edu>
Type: Standards Track
This PEP describes a mechanism for attaching profile and trace
functions to a thread when it is created. This mechanism allows
existing tools, like the profiler, to work with multi-threaded
programs. The new functionality is exposed via a new event type for
The Python interpreter provides profile and trace hooks to support
tools like debuggers and profilers. The hooks are associated with a
single thread, which makes them harder to use in a multi-threaded
environment. For example, the profiler will only collect data for a
single thread. If the profiled application spawns new threads, the
new threads will not be profiled. This PEP describes a mechanism that
allows tools using profile and trace hooks to hook thread creation
events. This mechanism would allow tools like the profiler to
automatically instrument new threads as soon as they are created.
The ability to hook thread creation makes a variety of tools more
useful. It should allow them to work seamlessly with multi-threaded
applications. The best alternative given the current interpreter
support is to edit a multi-threaded application to manually insert
calls to enable tracing or profiling.
There are two different hooks provided by the interpreter, one for
tracing and one for profiling. The hooks are basically the same,
except that the trace hook is called for each line that is executed
but the profile hook is only called for each function. The hooks are
exposed by the C API  and at the Python level by the sys module .
For simplicity, the rest of the section just talks about the trace
A trace function  is called with three arguments: a frame, an
event, and an event-dependent argument. The event is one of the
following strings: "call," "line," "return," or "exception." The C
API defines trace function that takes an int instead of a string to
define the trace event.
The sys.settrace() function sets the global trace function. A global
trace function is called whenever a new local scope is entered. If
the global trace function returns a value, it is used as the local
trace function. If it returns None, no local tracing occurs.
Thread creation event
The proposed mechanism is to add a thread creation event called
"thread" and PyTrace_THREAD. When thread.start_new_thread() is
called, the calling thread's trace function is called with a thread
event. The frame passed is None or NULL and the argument is the
callable argument passed to start_new_thread(). If the trace function
returns a value from the thread event, it is used as the global trace
function for the newly created thread.
The bootstrap code in the thread module (Modules/threadmodule.c) must
be extended to take trace functions into account. A thread's
bootstate must be extended to include pointers to the trace function
and its state object. The t_bootstrap() code must call the trace
function before executing the boot function.
Compatibility and Limitations
An existing trace or profile function may be unprepared for the new
event type. This may cause them to treat the thread event as some
other kind of event.
The thread event does not pass a valid frame object, because the frame
isn't available before the thread starts running. Once the thread
starts running, it is too late to generate the thread event.
The hook is only available when a thread is created using the Python
thread module. If a custom C extension calls
PyThread_start_new_thread() directly, the trace function will not be
called for that thread. It's hard to judge whether this behavior is
good or bad. It is driven partly by implementation details. The
implementation of PyThread_start_new_thread() can not tell when or if
Python code will be executed by the thread.
..  Section 8.2, Profiling and Tracing, Python/C API Reference Manual
..  Section 3.1, sys, Python Library Reference
..  Section 9.2, How It Works (Python Debugger), Python Library
This document has been placed in the public domain.
test_socketserver seems to be in all the expected skip lists except for
(oddly enough) os2emx. It correctly bails if the network resource isn't set
and the 2.2 branch version seems to complete for me on my Mac OS X system.
When run like:
% ./python.exe ../Lib/test/test_socketserver.py
the 2.3 branch version fails because the network resource isn't enabled:
Traceback (most recent call last):
File "../Lib/test/test_socketserver.py", line 5, in ?
File "/Users/skip/src/python/head/dist/src/Lib/test/test_support.py", line 68, in requires
test.test_support.ResourceDenied: Use of the `network' resource not enabled
Seems like a fairly simple change to test_support.requires() would correct
def requires(resource, msg=None):
# see if the caller's module is __main__ - if so, treat as if
# the resource was set
if sys._getframe().f_back.f_globals.get("__name__") == "__main__":
if not is_resource_enabled(resource):
if msg is None:
msg = "Use of the `%s' resource not enabled" % resource
Someone please shout if the above not-quite-obvious code doesn't look
> > Please at least do not produce the NetrcParseError when the
> > "login" field is omitted. This can be done by changing the
> > "else:" above "malformed %s entry" to "elif not password:".
> > That is the minimal change to make this module work on my
> > system.
Bram is requesting netrc.py be modified to exclude entries
without a login field. An example use case is for mail servers:
machine mail password fruit
If the change is made, the line won't be handled at all. It
would be silently skipped. Currently is raises a NetrcParseError.
Do you guys think this is appropriate? On the one hand,
it's a bummer that netrc.py cannot currently be used with
files containing these lines. On the other hand, silently
skipping over them doesn't seem quite right either.
P.S. He would also like (but does not have to have) this
I'm going on vacation from Apr 26 - May 6. I will probably not be
available during this period.
Sometime in the next month or so, I plan to run valgrind and pychecker
over everything. I should be done before beta2.
Also, the snake farm still has some issues. I will try to improve the
snake farm status in May or June. But if anybody wants to volunteer
to fix any of the issues, feel free. :-)
Some test failures are:
test_logging Solaris 8, RedHat 9
test_getargs2 Solaris 8, Mac OS X
test_time RedHat 9, Linux ia64
For a hack which seems to fix test_logging problem, see my comment here:
I plan on checking in the following changes to the gettext.py module for
Python 2.3, based on feedback from the Zope and Mailman i18n work.
Here's a summary of the changes, hopefully there aren't too many
controversies <wink>. I'll update the tests and the docs at the same
- Expose NullTranslations and GNUTranslations to __all__
- Set the default charset to iso-8859-1. It used to be None, which
would cause problems with .ugettext() if the file had no charset
parameter. Arguably, the po/mo file would be broken, but I still think
iso-8859-1 is a reasonable default.
- Add a "coerce" default argument to GNUTranslations's constructor. The
reason for this is that in Zope, we want all msgids and msgstrs to be
Unicode. For the latter, we could use .ugettext() but there isn't
currently a mechanism for Unicode-ifying msgids.
The plan then is that the charset parameter specifies the encoding for
both the msgids and msgstrs, and both are decoded to Unicode when read.
For example, we might encode po files with utf-8. I think the GNU
gettext tools don't care.
Since this could potentially break code [*] that wants to use the
encoded interface .gettext(), the constructor flag is added, defaulting
to False. Most code I suspect will want to set this to True and use
- A few other minor changes from the Zope project, including asserting
that a zero-length msgid must have a Project-ID-Version header for it to
be counted as the metadata record.
[*] I've come to the opinion that using anything other than Unicode
msgids and msgstrs just won't work well for Python, and thus you really
should be using the .ugettext() method everywhere. It's also insane to
mix .gettext() and .ugettext(). In Zope, all human readable messages
will be Unicode strings internally, so we definitely want Unicode
I know there aren't many of you guys, but I have an Investment Bank that is looking for an OO Scriptor, with at least 2 years Java experience with Unix and proper Python development skills.
Anyone know anyone....or anyone interested in this 3-6 contract?
Key Account Manager
Harvey Nash IT
Investment Banking / Finance Team
DD: 020 73331518
Fax: 020 73332657
The information in this e-mail and any attached files is CONFIDENTIAL and may be legally privileged or prohibited from disclosure and unauthorised use. The views of the author may not necessarily reflect those of the Company.
It is intended solely for the addressee, or the employee or agent responsible for delivering such materials to the addressee. If you have received this message in error please return it to the sender then delete the email and destroy any copies of it. If you are not the intended recipient, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication or any action taken or omitted to be taken in reliance upon this message or its attachments is prohibited and may be unlawful.
At present the integrity of e-mail across the Internet cannot be guaranteed and messages sent via this medium are potentially at risk. All liability is excluded to the extent permitted by law for any claims arising as a result of the use of this medium to transmit information by or to the Harvey Nash Group plc.