Mailman 3 October 2000 - Python-Dev

Proposal -- makefile patches and scripts to generate python RPMs
by Martin v. Loewis 06 Oct '00

06 Oct '00

> The main thing a specfile generator can accomplish is to automate > the generation of the file list so that (for example) when we add a > new library module the specfile doesn't have to be hand-edited. That sounds similar to the rationale for having automatically generated dependency files for make, e.g. by gcc -MM. Many projects use this as a convenience, and it kind-of works. However, I still like it better to have dependencies explicitly recorded in the Makefiles. That requires more discipline, but is easier to understand, and the behaviour is more reproducable. So given the option of using an existing hand-written spec file, and having some magic generate one for me, I'd always use the hand-written one. The magic is only good if there is no hand-written one. Regards, Martin

4 4

htmllib.HTMLescape()
by Martin von Loewis 06 Oct '00

06 Oct '00

> The difficulty, I assume, lies in figuring out which encodings > support what characters. It's not that difficult to write a set of new codecs; with the module below, I can do >>> import xmlenc >>> u'\u0416'.encode('latin-1-xml') 'Ж' >>> unicode('XɅY','latin-1-xml') u'X\u0245Y' The difficulty is that the algorithm is not very efficient if there are many unsupported characters in a string. Regards, Martin # Module implementing a set of new encodings of the form <enc>-xml # Copyright Martin v. Löwis # It currently supports hex character references only import codecs class CodecWrapper: def __init__(self,encoder,decoder): self.encoder = encoder self.decoder = decoder def encode(self,input,errors='strict'): try: return self.encoder(input,"strict") except ValueError: l = len(input) if l==1: return "&#x%x;" % ord(input), 1 s1,l1 = self.encode(input[:l/2]) s2,l2 = self.encode(input[l/2:]) return s1+s2,l1+l2 def decode(self,input,errors='strict'): input = str(input) # might be buffer object pos = input.find("&#x") if pos == -1: return self.decoder(input,errors) r1,l1 = self.decode(input[:pos],errors) end = input.find(";",pos) try: if end==-1: raise ValueError # goto failure code below val = int(input[pos+3:end],16) r2,l2 = self.decode(input[end+1:],errors) return r1+unichr(val)+r2,l1+end-pos+l2 except ValueError: # how to deal with errors in decode? r2,l2 = self.decode(input[pos+2:],errors) return r1+"&#x"+r2,l1+3+l2 def mkreader(self): r = codecs.StreamReader() r.decode = self.decode r.encode = self.encode return r def mkwriter(self): r = codecs.StreamWriter() r.decode = self.decode r.encode = self.encode return r def search_function(encoding): if not encoding.endswith("-xml"): return None enc,dec,reader,writer = codecs.lookup(encoding[:-4]) c = CodecWrapper(enc,dec) return c.encode,c.decode,c.mkreader,c.mkwriter codecs.register(search_function)

1 0

RE: buffer overlow in PC/getpathp.c
by Jeremy Hylton 06 Oct '00

06 Oct '00

>I would be happy to! Although I am happy to report that I believe it >safe - I have been very careful of this from the time I wrote it. > >What is the process? How formal should it be? Not sure how formal it should be, but I would recommend you review uses of strcpy and convince yourself that the source string is never longer than the target buffer. I am not convinced. For example, in calculate_path(), char *pythonhome is initialized from an environment variable and thus has unknown length. Later it used in a strcpy(prefix, pythonhome), where prefix has a fixed length. This looks like a vulnerability than could be closed by using strncpy(prefix, pythonhome, MAXPATHLEN). The Unix version of this code had three or four vulnerabilities of this sort. So I imagine the Windows version has those too. I was imagining that the registry offered a whole new opportunity to provide unexpectedly long strings that could overflow buffers. Jeremy

2 2

forwarded message from Gerald Pfeifer
by Fred L. Drake, Jr. 06 Oct '00

06 Oct '00

I just got this message from the gcc-announce list. We've seen bug reports related to GCC 2.96 (which may or may not be the problem). We need to be aware that these releases are out there and can be a problem. I've noticed that the version of GCC shipped with Mandrake 7.1 is "gcc version 2.95.3 19991030 (prerelease)", which doesn't give my much confidence either. ;( -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member

2 2

Re: [Python-checkins] CVS: python/dist/src configure,1.157,1.158 configure.in,1.166,1.167
by Thomas Wouters 05 Oct '00

05 Oct '00

On Thu, Oct 05, 2000 at 11:45:55AM -0700, Barry Warsaw wrote: > Update of /cvsroot/python/python/dist/src > In directory slayer.i.sourceforge.net:/tmp/cvs-serv14007 > Modified Files: > configure configure.in > Log Message: > Change all occurances of > > test -d "$directory" > to > test ! -z "directory" -a -d "directory" > Apparently, on SunOS 4.1.4_JL (and other?) OSes, -d on an empty string > always returns true. This closes SF bug #115392. > --- 3103,3110 ---- > USE_THREAD_MODULE="#" > else > ! if test ! -z $with_threads -a -d $with_threads > then LDFLAGS="$LDFLAGS -L$with_threads" > fi > ! if test ! -z $withval -a -d $withval > then LDFLAGS="$LDFLAGS -L$withval" > fi Is this really going to work ? I always see 'portable' shell code do something like if [ "X${spam}" != "X" ] ... instead of 'test -z', eventhough even BSDI test has -z. (The portable code I'm talking about are mostly BSDI /etc/rc* scripts... BSDI's /bin/sh is minimal, compared to modern day equivalents.) My /bin/sh-knowledge is decidedly less impressive than my Python knowledge, but I thought something like if test ! -z $withval -a -d $withval where $withval is empty, would be parsed as if test ! -z -a -d which would be, uhm, wrong ? But like I said, I don't really know what I'm talking about here, there could be another perfectly valid reason for BSDI to use the roundabout way, instead of using -z. -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

1 0

forwarded message from aahz@panix.com
by bwarsaw＠beopen.com 05 Oct '00

05 Oct '00

4 4

Re: [Python-checkins] CVS: python/dist/src configure,1.157,1.158 configure.in,1.166,1.167
by Skip Montanaro 05 Oct '00

05 Oct '00

Barry> Apparently, on SunOS 4.1.4_JL (and other?) OSes, -d on an empty Barry> string always returns true. This closes SF bug #115392. There was a big thread recently on the tramp mailing list (similar to efs for remote file editing in Emacs, but uses ssh/scp instead) about trying to find a portable way to test for the existence of a file. After trying all sorts of stuff, the final result was pretty ugly, as I recall. -- Skip Montanaro (skip(a)mojam.com) http://www.mojam.com/ http://www.musi-cal.com/

1 0

PEP 4: Deprecation of standard modules
by Martin von Loewis 05 Oct '00

05 Oct '00

I just finished a first draft of a PEP on deprecating (and eventually removing) modules from the standard Python library; it is available from http://python.sourceforge.net/peps/pep-0004.html If you have comments or suggestions on the proposed procedures, or the wording of the text, please send me a message. According to the PEP procedures (PEP 1), this is the preferred way of progressing this PEP (rather than discussing it on these lists), at least initially. Regards, Martin

1 0

Release candidate followed by feature freeze?
by Martin von Loewis 05 Oct '00

05 Oct '00

> I'd like to poll opinions about this (we haven't had a PythonLabs > group meeting about this yet). YES! I was hoping somebody would propose such a thing; I was quite concerned that check-in procedures are still that liberate. To report how similar projects operate: In gcc, a CVS release branch is created at some point in time (usually months before the release). When the code is declared frozen, all changes to the release branch have to go through the release manager. After the release, "important" changes to the mainline branch are manually propagated to the release branch for subminor releases. Regards, Martin

7 14

Adding a section to PEP 0042
by Greg Ward 05 Oct '00

05 Oct '00

I need to add an entry to PEP 0042 about the lack of cross-compilation support, because that's a bug report that was assigned to me, and needs to be marked "Closed/Feature Request/Later" and put in PEP 0042. Seems to me that I should just add a section on "Build/Installation" to the PEP -- anyone disagree? This might also be a good place to gather other gripes about Python's build/installation machinery... Greg -- Greg Ward - software developer gward(a)mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367

2 1