I grabbed the latest Python2.5 code via subversion and ran my typo script on it.
Weeding out the obvious false positives and Neal's comments leaves about 129 typos.
Should I enter the typos as bugs in the Python bug db?
> Date: Fri, 22 Sep 2006 21:51:38 -0700> From: nnorwitz(a)gmail.com> To: typo_pl(a)hotmail.com> Subject: Re: [Python-Dev] Typo.pl scan of Python 2.5 source code> CC: python-dev(a)python.org> > On 9/22/06, Johnny Lee <typo_pl(a)hotmail.com> wrote:> >> > Hello,> > My name is Johnny Lee. I have developed a *ahem* perl script which scans> > C/C++ source files for typos.> > Hi Johnny.> > Thanks for running your script, even if it is written in Perl and ran> on Windows. :-)> > > The Python 2.5 typos can be classified into 7 types.> >> > 2) realloc overwrite src if NULL, i.e. p = realloc(p, new_size);> > If realloc() fails, it will return NULL. If you assign the return value to> > the same variable you passed into realloc,> > then you've overwritten the variable and possibly leaked the memory that the> > variable pointed to.> > A bunch of these warnings were accurate and a bunch were not. There> were 2 reasons for the false positives. 1) The pointer was aliased,> thus not lost, 2) On failure, we exited (Parser/*.c)> > > 4) if ((X!=0) || (X!=1))> > These 2 cases occurred in binascii. I have no idea if the warning is> wright or the code is.> > > 6) XX;;> > Just being anal here. Two semicolons in a row. Second one is extraneous.> > I already checked in a fix for these on HEAD. Hard for even me to> screw up those fixes. :-)> > > 7) extraneous test for non-NULL ptr> > Several memory calls that free memory accept NULL ptrs.> > So testing for NULL before calling them is redundant and wastes code space.> > Now some codepaths may be time-critical, but probably not all, and smaller> > code usually helps.> > I ignored these as I'm not certain all the platforms we run on accept> free(NULL).> > Below is my categorization of the warnings except #7. Hopefully> someone will fix all the real problems in the first batch.> > Thanks again!> > n> --> > # Problems> Objects\fileobject.c (338): realloc overwrite src if NULL; 17:> file->f_setbuf=(char*)PyMem_Realloc(file->f_setbuf,bufsize)> Objects\fileobject.c (342): using PyMem_Realloc result w/no check> 30: setvbuf(file->f_fp, file->f_setbuf, type, bufsize);> [file->f_setbuf]> Objects\listobject.c (2619): using PyMem_MALLOC result w/no check> 30: garbage[i] = selfitems[cur]; [garbage]> Parser\myreadline.c (144): realloc overwrite src if NULL; 17:> p=(char*)PyMem_REALLOC(p,n+incr)> Modules\_csv.c (564): realloc overwrite src if NULL; 17:> self->field=PyMem_Realloc(self->field,self->field_size)> Modules\_localemodule.c (366): realloc overwrite src if NULL; 17:> buf=PyMem_Realloc(buf,n2)> Modules\_randommodule.c (290): realloc overwrite src if NULL; 17:> key=(unsigned#long*)PyMem_Realloc(key,bigger*sizeof(*key))> Modules\arraymodule.c (1675): realloc overwrite src if NULL; 17:> self->ob_item=(char*)PyMem_REALLOC(self->ob_item,itemsize*self->ob_size)> Modules\cPickle.c (536): realloc overwrite src if NULL; 17:> self->buf=(char*)realloc(self->buf,n)> Modules\cPickle.c (592): realloc overwrite src if NULL; 17:> self->buf=(char*)realloc(self->buf,bigger)> Modules\cPickle.c (4369): realloc overwrite src if NULL; 17:> self->marks=(int*)realloc(self->marks,s*sizeof(int))> Modules\cStringIO.c (344): realloc overwrite src if NULL; 17:> self->buf=(char*)realloc(self->buf,self->buf_size)> Modules\cStringIO.c (380): realloc overwrite src if NULL; 17:> oself->buf=(char*)realloc(oself->buf,oself->buf_size)> Modules\_ctypes\_ctypes.c (2209): using PyMem_Malloc result w/no> check 30: memset(obj->b_ptr, 0, dict->size); [obj->b_ptr]> Modules\_ctypes\callproc.c (1472): using PyMem_Malloc result w/no> check 30: strcpy(conversion_mode_encoding, coding);> [conversion_mode_encoding]> Modules\_ctypes\callproc.c (1478): using PyMem_Malloc result w/no> check 30: strcpy(conversion_mode_errors, mode);> [conversion_mode_errors]> Modules\_ctypes\stgdict.c (362): using PyMem_Malloc result w/no> check 30: memset(stgdict->ffi_type_pointer.elements, 0,> [stgdict->ffi_type_pointer.elements]> Modules\_ctypes\stgdict.c (376): using PyMem_Malloc result w/no> check 30: memset(stgdict->ffi_type_pointer.elements, 0,> [stgdict->ffi_type_pointer.elements]> > # No idea if the code or tool is right.> Modules\binascii.c (1161)> Modules\binascii.c (1231)> > # Platform specific files. I didn't review and won't fix without testing.> Python\thread_lwp.h (107): using malloc result w/no check 30:> lock->lock_locked = 0; [lock]> Python\thread_os2.h (141): using malloc result w/no check 30:> (long)sem)); [sem]> Python\thread_os2.h (155): using malloc result w/no check 30:> lock->is_set = 0; [lock]> Python\thread_pth.h (133): using malloc result w/no check 30:> memset((void *)lock, '\0', sizeof(pth_lock)); [lock]> Python\thread_solaris.h (48): using malloc result w/no check 30:> funcarg->func = func; [funcarg]> Python\thread_solaris.h (133): using malloc result w/no check 30:> if(mutex_init(lock,USYNC_THREAD,0)) [lock]> > # Who cares about these modules.> Modules\almodule.c:182> Modules\svmodule.c:547> > # Not a problem.> Parser\firstsets.c (76)> Parser\grammar.c (40)> Parser\grammar.c (59)> Parser\grammar.c (83)> Parser\grammar.c (102)> Parser\node.c (95)> Parser\pgen.c (52)> Parser\pgen.c (69)> Parser\pgen.c (126)> Parser\pgen.c (438)> Parser\pgen.c (462)> Parser\tokenizer.c (797)> Parser\tokenizer.c (869)> Modules\_bsddb.c (2633)> Modules\_csv.c (1069)> Modules\arraymodule.c (1871)> Modules\gcmodule.c (1363)> Modules\zlib\trees.c (375)
Get the new Windows Live Messenger!
On Saturday 28 October 2006 03:13, andrew.kuchling wrote:
> 2.4 backport candidate, probably.
FWIW, I'm not planning on doing any more "collect all the bugfixes" releases
of 2.4. It's now in the same category as 2.3 - that is, only really serious
bugs (in particular, security related bugs) will get a new release, and then
only with the serious bugfixes applied.
One active maintenance branch is quite enough to deal with, IMHO.
Anthony Baxter <anthony(a)interlink.com.au>
It's never too late to have a happy childhood.
I have patched Lib/modulefinder.py to work with absolute and relative imports.
It also is faster now, and has basic unittests in Lib/test/test_modulefinder.py.
The work was done in a theller_modulefinder SVN branch.
If nobody objects, I will merge this into trunk, and possibly also into release25-maint, when I have time.
Martin v. Löwis wrote:
> Georg Brandl schrieb:
>> Perhaps you can bring up a discussion on python-dev about your improvements
>> and how they could be integrated into the standard library...
> Let me second this. The compiler package is largely unmaintained and
> was known to be broken (and perhaps still is). A replacement
> implementation, especially if it comes with a new maintainer, would
> be welcome.
I use AST-based code inspection and manipulation, and I've been looking forward
to using v2.5 ASTs for their increased accuracy, consistency and speed. However,
there is as yet no Python-exposed mechanism for compiling v2.5 ASTs to bytecode.
So to meet my own need and interest I've been implementing 'compiler2', similar
in scope to the stblib compiler package, but generating code from Python 2.5
_ast.ASTs. The code has evolved considerably from the compiler package: in
aggregate the changes amount to a re-write. More about the package and its
I'm introducing this project here to discuss whether and how these changes
should be integrated with the stdlib.
I believe there is a prima facie need to have a builtin/stdlib capability for
compiling v2.5 ASTs from Python, and there is some advantage to having that be
implemented in Python. There is also a case for deprecating the v2.4 ASTs to
ease maintenance and reduce the confusion associated with two different AST formats.
If there is interest, I'm willing make compiler2 stdlib-ready. I'm also open to
alternative approaches, including doing nothing.
compiler2 Objectives and Status
My goal is to get compiler2 to produce identical output to __builtin__.compile
(at least optionally), while also providing an accessible framework for
AST-manipulation, experimental compiler optimizations and customization.
compiler2 is not finished - there are some unresolved bugs, and open questions
on interface design - but already it produces identical output to
__builtin__.compile for all of the stdlib modules and their tests (except for
the stackdepth attribute which is different in 12 cases). All but three stdlib
modules pass their tests after being compiled using compiler2. More on goals,
status, known issues etc... in the project readme.txt at:
Code is available in Subversion at
The main test script is test/test_compiler.py which compiles all the modules in
/Lib and /Lib/test and compares the output with __builtin__.compile.
Is this a bug? If not, how do I override __str__ on a unicode derived class?
def __str__(self): return '__str__ overridden'
def __str__(self): return '__str__ overridden'
def __unicode__(self): return u'__unicode__ overridden'
s = S()
u = U()
print 's:', s
print "str(s):", str(s)
print 's substitued is "%s"\n' % s
print 'u:', u
print "str(u):", str(u)
print 'u substitued is "%s"' % u
s: __str__ overridden
str(s): __str__ overridden
s substitued is "__str__ overridden"
str(u): __str__ overridden
u substitued is ""
Results are identical for 2.4.2 and 2.5c2 (running under windows).
Per my conversation with Martin v. Löwis on the python-list, I think I
have found a problem with the configure script and Makefile.in.
For Python 2.4.4 it seems that the arguement --libdir does not change
the Makefile. Specifically I need this to change the libdir to
/usr/lib64 for RH on a x86_64 machine.
I'd like to contribute a fix for this, but I'm relatively new so I
would appreciate some guidance.
In the Makefile, I tried setting LIBDIR to $(exec_prefix)/lib64 and
SCRIPTDIR to $(prefix)/lib64 manually. Unfortuantely that created an
error when I ran python2.4:
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
'import site' failed; use -v for traceback
so I edited my /etc/profile and included:
export PYTHONHOME = "/usr"
and reran python2.4 and now the only error is:
'import site' failed; use -v for traceback
I poked around in /Modules/getpath.c and I'm starting to understand
how things are comming together. My question is: how does $(prefix)
from the congifure script make it into PREFIX in the c code? I see on
line 106 of /Modules/getpath.c that it checks to see if PREFIX is
defined and if not set's it to "/usr/local". So I did a grep on
PREFIX from the Python2.4.4 dir level and it didn't return anything
that looks like PREFIX is being set based on the input to the
configure script. Where might this be happening? I'm assuming
there's also a similar disconnect for LIBDIR (even though it never
get's set properly in the Makefile, even when I edited it by hand,
those changes don't make it into the code .... but I don't know where
it should be changed in the code.)