Mailman 3 February 2001 - Python-Dev

PEPS, version control, release intervals
by Martin v. Loewis 08 Feb '01

08 Feb '01

> A more critical issue might be why people haven't adopted 2.0 yet; > there seems little reason is there to continue using 1.5.2, yet I > still see questions on the XML-SIG, for example, from people who > haven't upgraded. Is it that Zope doesn't support it? Or that Red > Hat and Debian don't include it? Availability of Linux binaries is certainly an issue. On xml-sig, one Linux distributor (I forgot whether SuSE or Redhat) mentioned that they won't include 2.0 in their current major release series (7.x for both). Furthermore, the available 2.0 binaries won't work for either Redhat 7.0 nor SuSE 7.0; I think collecting binaries as we did for earlier releases is an important activity that was forgotten during 2.0. In addition, many packages are still not available for 2.0. Zope is only one of them; gtk, Qt, etc packages are still struggling with Unicode support. omniORBpy has #include <python15/Python.h> in their sources, ILU does not compile on 2.0 (due to wrong tests involving the PY_MAJOR/MINOR roll-over), Fnorb falls into the select.bind parameter change pitfall. This list probably could be continued - I'm sure many of the maintainers of these packages would appreciate a helping hand from some Python Guru. Regards, Martin

2 3

Re: [Python-Dev] PEPS, version control, release intervals
by Uche Ogbuji 07 Feb '01

07 Feb '01

> Availability of Linux binaries is certainly an issue. On xml-sig, one > Linux distributor (I forgot whether SuSE or Redhat) mentioned that > they won't include 2.0 in their current major release series (7.x for > both). 'Twas Red Hat. However, others claim to have spotted Python 2.0 in Rawhide and supposedly both versions might be included until 8.0. > In addition, many packages are still not available for 2.0. Zope is > only one of them; gtk, Qt, etc packages are still struggling with > Unicode support. omniORBpy has #include <python15/Python.h> in their > sources, I hadn't noticed this. OmniORBpy compiles and runs just fine for me using Python 2.0 and 2.1a2, except that it throws BAD_PARAM when passed Unicode objects in place of strings. -- Uche Ogbuji Principal Consultant uche.ogbuji(a)fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA Software-engineering, knowledge-management, XML, CORBA, Linux, Python

1 0

fp vs. fd
by Eric S. Raymond 07 Feb '01

07 Feb '01

There are a number of places in the Python library that require a numeric file descriptor, rather than a file object. This complicates code slightly and (IMO) breaches the wrapper around the file-object abstraction (which Guido says is only supposed to depend on stdio-level stuff). Are there design reasons for this, or is it historical accident? If the latter, I'll go through and fix these to accept either an fd or an fp. And fix the docs, too. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> Non-cooperation with evil is as much a duty as cooperation with good. -- Mohandas Gandhi

6 5

more 2.1a2 macosx build problems
by Steven D. Majewski 07 Feb '01

07 Feb '01

Is anyone else tracking builds on macosx ? A bug I reported [#131170] on the 2.1a2 release has been growing more heads... Initial problem: make install fails as it tries to run ranlib on a shared library: ranlib: file: /usr/local/lib/python2.1/config/libpython2.1.dylib is not an archive commented out that line in the makefile: @if test -d $(LDLIBRARY); then :; else \ $(INSTALL_DATA) $(LDLIBRARY) $(LIBPL)/$(LDLIBRARY) ; \ # $(RANLIB) $(LIBPL)/$(LDLIBRARY) ; \ make and install seem to work, however, if you run python from somewhere other than the build directory, you get a fatal error: dyld: python2.1 can't open library: libpython2.1.dylib (No such file or directory, errno = 2) looking at executable with 'otool -L' shows that while system frameworks have their complete pathnames, libpython2.1.dylib has no path, so it's expected to be in the current directory. Added "-install_name $(LIBPL)/$(LDLIBRARY)" to the libtool command to tell it that it will be installed somewhere other than the current build directory. 'make' fails on setup when python can't find os module. Investigating that, it looks like sys.path is all confused. Looking at Modules/getpath.c, it looks like the WITH_NEXT_FRAMEWORK conditional code is getting the path from the shared library and not the executable. -- Steve Majewski

1 0

unichr
by Paul Prescod 07 Feb '01

07 Feb '01

Does anyone have an example of real code that would break if unichr and chr were merged? chr would return a regular string if possible and a Unicode string otherwise. When the two string types are merged, there would be no need to deprecate unichr as redundant. Paul Prescod

2 1

New benchmark results (2.1a2 vs. 2.0)
by M.-A. Lemburg 07 Feb '01

07 Feb '01

I reran the benchmark I posted a couple of days ago against the current CVS tree. Here are the results (this time I double checked that both version were compiled using the same compiler settings) on my AMD K6 (I gave back the AMK K6 to Andrew :-). This time I ran the benchmark with Python in -O mode which should give better performance characteristics: PYBENCH 0.8 Benchmark: tmp/pybench-2.1a2-O.pyb (rounds=10, warp=20) Tests: per run per oper. diff * ------------------------------------------------------------------------ BuiltinFunctionCalls: 1080.60 ms 8.48 us +7.91% BuiltinMethodLookup: 1185.60 ms 2.26 us +47.86% ConcatStrings: 1157.75 ms 7.72 us +10.03% ConcatUnicode: 1398.80 ms 9.33 us +8.76% CreateInstances: 1694.30 ms 40.34 us +12.08% CreateStringsWithConcat: 1393.90 ms 6.97 us +9.75% CreateUnicodeWithConcat: 1487.90 ms 7.44 us +7.81% DictCreation: 1794.45 ms 11.96 us +4.22% DictWithFloatKeys: 2102.75 ms 3.50 us +18.03% DictWithIntegerKeys: 1107.80 ms 1.85 us +13.33% DictWithStringKeys: 892.80 ms 1.49 us -2.39% ForLoops: 1145.95 ms 114.59 us -0.00% IfThenElse: 1229.60 ms 1.82 us +15.67% ListSlicing: 551.75 ms 157.64 us +2.23% NestedForLoops: 649.65 ms 1.86 us -0.60% NormalClassAttribute: 1253.35 ms 2.09 us +29.57% NormalInstanceAttribute: 1394.25 ms 2.32 us +51.52% PythonFunctionCalls: 942.45 ms 5.71 us -10.22% PythonMethodCalls: 975.30 ms 13.00 us +14.33% Recursion: 770.35 ms 61.63 us -0.42% SecondImport: 855.50 ms 34.22 us -1.37% SecondPackageImport: 869.40 ms 34.78 us -2.56% SecondSubmoduleImport: 1075.40 ms 43.02 us -3.93% SimpleComplexArithmetic: 1632.95 ms 7.42 us +7.04% SimpleDictManipulation: 1018.15 ms 3.39 us +11.44% SimpleFloatArithmetic: 782.25 ms 1.42 us +0.49% SimpleIntFloatArithmetic: 770.70 ms 1.17 us +0.93% SimpleIntegerArithmetic: 769.85 ms 1.17 us +0.82% SimpleListManipulation: 1097.35 ms 4.06 us +13.16% SimpleLongArithmetic: 1274.80 ms 7.73 us +8.27% SmallLists: 1982.30 ms 7.77 us +5.20% SmallTuples: 1259.90 ms 5.25 us +3.87% SpecialClassAttribute: 1265.35 ms 2.11 us +33.74% SpecialInstanceAttribute: 1694.35 ms 2.82 us +51.38% StringMappings: 1483.15 ms 11.77 us +8.04% StringPredicates: 1205.05 ms 4.30 us -4.89% StringSlicing: 1158.00 ms 6.62 us +12.65% TryExcept: 1128.70 ms 0.75 us -1.22% TryRaiseExcept: 1199.50 ms 79.97 us +6.45% TupleSlicing: 971.40 ms 9.25 us +10.99% UnicodeMappings: 1111.15 ms 61.73 us -2.04% UnicodePredicates: 1307.20 ms 5.81 us -7.54% UnicodeProperties: 1228.05 ms 6.14 us +8.81% UnicodeSlicing: 1032.95 ms 5.90 us -7.52% ------------------------------------------------------------------------ Average round time: 59476.00 ms +6.18% *) measured against: tmp/pybench-2.0-O.pyb (rounds=10, warp=20) The version 0.8 pybench archive can be downloaded from: http://www.lemburg.com/python/pybench-0.8.zip It includes two new test for special dictionary keys. What's interesting here is that attribute lookups seem to have suffered (I consider figures above ~10% to be significant) while Python function calls got faster. The new dictionary key tests nicely show the effect of the string optimization compared to the standard lookup scheme which applies lots of error checking. OTOH, it is surprising that attribute lookup got a slowdown since these normally are string lookups in dictionaries... -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

1 0

Re: [Python-checkins] CVS: python/dist/src/Modules socketmodule.c,1.135,1.136
by Andrew Kuchling 07 Feb '01

07 Feb '01

On Tue, Feb 06, 2001 at 02:58:07PM -0800, A.M. Kuchling wrote: >! if (!PyArg_ParseTuple(args, "s|i:write", &data, &len)) >! if (!PyArg_ParseTuple(args, "s#|i:write", &data, &len)) Hm... actually, this patch isn't correct after all. The |i meant you could specify an optional integer to write out only a partial chunk of the string; why not just slice it? Since the SSL code isn't documented, I'm tempted to just rip out the |i. --amk

2 1

Quick Unix work needed
by Tim Peters 06 Feb '01

06 Feb '01

Trent Mick's C API testing framework has been checked in, along with everything needed to get it working on Windows: http://sourceforge.net/patch/?func=detailpatch&patch_id=101162& group_id=5470 It still needs someone to add it to the Unixish builds. You'll know that it worked if the new std test test_capi.py succeeds.

3 2

Re: [Python-checkins] CVS: python/dist/src/Modules socketmodule.c,1.135,1.136
by Thomas Wouters 06 Feb '01

06 Feb '01

On Tue, Feb 06, 2001 at 02:58:07PM -0800, A.M. Kuchling wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory usw-pr-cvs1:/tmp/cvs-serv21837 > Modified Files: > socketmodule.c > Log Message: > Patch #103636: Allow writing strings containing null bytes to an SSL socket > Index: socketmodule.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v > retrieving revision 1.135 > retrieving revision 1.136 > diff -C2 -r1.135 -r1.136 > *** socketmodule.c 2001/02/02 19:55:17 1.135 > --- socketmodule.c 2001/02/06 22:58:05 1.136 > *************** > *** 2219,2223 **** > size_t len = 0; > > ! if (!PyArg_ParseTuple(args, "s|i:write", &data, &len)) > return NULL; > > --- 2219,2223 ---- > size_t len = 0; > > ! if (!PyArg_ParseTuple(args, "s#|i:write", &data, &len)) > return NULL; This doesn't seem right. The new function needs another 'length' argument (an int), and the smallest of the two should be used. -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

1 0

re: for in dict (user expectation poll)
by Greg Wilson 06 Feb '01

06 Feb '01

> > > > On Mon, 5 Feb 2001, Greg Wilson wrote: > > > > Based on my very-informal survey, if: > > > > for i in someList: > > > > works, then many people will assume that: > > > > for i in someDict: > > > > will also work, and yield values. > > > Ka-Ping Yee: > > > ...the latter is ambiguous (keys or values?)... > > Greg Wilson > > The latter is exactly as ambiguous as the former... I think this > > is a case where your (intimate) familiarity with the way Python > > works now is preventing you from getting into newbie headspace... > Ka-Ping Yee: > No, i don't think so. It seems quite possible to argue from first > principles that if you ask to iterate over things "in" a sequence, > you clearly want the items in the sequence, not their integer indices. Greg Wilson: Well, arguing from first principles, Aristotle was able to demonstrate that heavy objects fall faster than light ones :-). I'm basing my claim on the kind of errors students in my course make. Even after being shown half-a-dozen examples of Python for loops, many of them write: for i in someSequence: print someSequence[i] in their first exercise. Thanks, Greg

4 6