Mailman 3 January 2001 - Python-Dev

Re: [Python-checkins] CVS: python/dist/src/Include pyport.h,2.20,2.21
by Gregor Hoffleit 29 Jan '01

29 Jan '01

FYI: This misdefinition with LONG_BIT was due to a bug in glibc's limits.h. It has been fixed in glibc 2.96. Gregor On Wed, Oct 04, 2000 at 06:42:32PM -0700, Tim Peters wrote: > Update of /cvsroot/python/python/dist/src/Include > In directory slayer.i.sourceforge.net:/tmp/cvs-serv5758/python/dist/src/Include > > Modified Files: > pyport.h > Log Message: > Move LONG_BIT from intobject.c to pyport.h. #error if it's already been > #define'd to an unreasonable value (several recent gcc systems have > misdefined it, causing bogus overflows in integer multiplication). Nuke > CHAR_BIT entirely.

3 2

XSLT parser interface
by Martin v. Loewis 28 Jan '01

28 Jan '01

Based on my previous IDL interface for XPath parsers, I've defined an API for a parser that parsers XSLT pattern expressions. It is an extension to the XPath API, so I attach only the additional functions. Any comments are appreciated. Martin module XPath{ // XSLT exprType values const unsigned short PATTERN = 17; const unsigned short LOCATION_PATTERN = 18; const unsigned short RELATIVE_PATH_PATTERN = 19; const unsigned short STEP_PATTERN = 20; interface Pattern; interface LocationPathPattern; interface RelativePathPattern; interface StepPattern; interface PatternFactory:ExprFactory{ Pattern createPattern(in LocationPathPattern first); // idkey may be null, represents IdKeyPattern // if parent is true, it is '/', else '//' // rel may be null LocationPathPattern createLocationPathPattern(in FunctionCall idkey, boolean parent, in RelativePathPattern rel); // if parent is true, it is /, else // RelativePathPattern createRelativePathPattern(in RelativePathPattern rel, boolean parent, in StepPattern step); StepPattern createStepPattern(in AxisSpecifier axis, in NodeTest test, in PredicateList predicates); }; typedef sequence<LocationPathPattern> LocationPathPatterns; interface Pattern:Expr{ readonly attribute LocationPathPatterns patterns; void append(in LocationPathPattern pattern); }; interface LocationPathPattern:Expr{ readonly attribute FunctionCall idkey; readonly attribute boolean parent; readonly attribute RelativePathPattern relative_pattern; }; interface RelativePathPattern:Expr{ readonly attribute RelativePathPattern relative; readonly attribute boolean parent; readonly attribute StepPattern step; }; interface StepPattern:Expr{ readonly attribute AxisSpecifier axis; readonly attribute NodeTest test; readonly attribute PredicateList predicates; }; interface XSLTParser:Parser{ Pattern parsePattern(in DOMString pattern); }; };

1 0

New bug in function object hash() and comparisons
by Guido van Rossum 27 Jan '01

27 Jan '01

Barry noticed: > Anyway, did you know that you can use functions as keys to a > dictionary, but that you can mutate them to "lose" the element? > > -------------------- snip snip -------------------- > Python 2.0 (#13, Jan 10 2001, 13:06:39) > [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 > Type "copyright", "credits" or "license" for more information. > >>> d = {} > >>> def foo(): pass > ... > >>> def bar(): pass > ... > >>> d[foo] = 1 > >>> d[foo] > 1 > >>> foocode = foo.func_code > >>> foo.func_code = bar.func_code > >>> d[foo] > Traceback (most recent call last): > File "<stdin>", line 1, in ? > KeyError: <function foo at 0x81ef474> > >>> d[bar] = 2 > >>> d[bar] > 2 > >>> d[foo] > 2 > >>> foo.func_code = foocode > >>> d[foo] > 1 > -------------------- snip snip -------------------- > > It's because a function's func_code attribute is used in its hash > calculation, but func_code is writable! Clearly, something changed. I'm pretty sure it's the function attributes. Either the function attributes shouldn't be used in comparing function objects, or hash() on functions should be unimplemented, or comparison on functions should use simple pointer compares. What's the right solution? Do people use functions as dict keys? If not, we can remove the hash() implementation. But I suspect they *are* used as dict keys. Not using the __dict__ on comparisons appears ugly, so probably the best solution is to change function comparisons to use simple pointer compares. That removes the possibility to see whether two different functions implement the same code -- but does anybody really use that? --Guido van Rossum (home page: http://www.python.org/~guido/)

3 4

RE: Python-Dev digest, Vol 1 #1119 - 17 msgs
by Greg Wilson 27 Jan '01

27 Jan '01

> Guido wrote: > What's the right solution? Do people use functions as dict keys? Yup --- even use this as an example in the course (part of drumming home to students that functions are just a special kind of data). Greg

1 0

LINKCC defaults to CXX
by Neil Schemenauer 27 Jan '01

27 Jan '01

Dear lord why? So people can develop extensions using C++? Its not worth the pain inflicted on everyone else. Let them recompile with LINKCC=CXX. Linking with CXX opens a huge can of stinky worms. First of all, just because configure found a value for CXX doesn't mean it works. Even if it does that doesn't mean that using it is a good idea. Linking with CXX will bring in the C++ runtime. There are a large number of platforms where the C++ ABI has not been standarized; for example, anything that used g++. Can we please leave LINKCC default to CXX? Its easy enough for the crazies to override if they like. I'll even create a configure option for them. Neil

3 2

Re: [Python-Dev] problems building Python 2.1a1 on QNX 4.25
by Armin Steinhoff 27 Jan '01

27 Jan '01

Hello Guido, nice to see the first 2.1 version :) At 16:52 26.01.01 -0500, you wrote: > > [CC'ing to Armin Steinhoff, who maintains pyqnx on SourceForge.] > > > > I'm having trouble building Python 2.1a1 on QNX 4.25. Caveat: my C is very > > rusty (long live Python!), I don't know my way around configure, and am not > > familiar with Python's Makefile. Python 2.0 compiled fine (with a couple of > > tweaks), but I'm getting caught by the new way of building things. Please > > help if you can! Many thanks in advance. > > > > Here's an excerpt of my efforts: > > > > # cd /tmp/py > > # gunzip -c < python-2.1a1.tgz | tar -rf - > > # cd Python-2.1a1 > > # ./configure 2>&1 | tee ../configure.1 I did a fast hack with the new 2.1 version: CC=cc LINKCC=cc configure --without-gcc --shared=no --without-threads (Hope '--shared=no' works ... QNX4 doesn't support dynamic loading) Please replace all references to g++ by cc -> in the main Makefile and the Modules/Makefile. In the Modules/Makefile set LDFLAGS=250K ... the default stacksize of 32K seems to be too small. > > # make 2>&1 | tee ../make.1 > > ... > > ./python //5/tmp/py/Python-2.1a1/setup.py build > > 'import site' failed; use -v for traceback 'python -v' shows that the module 'distutils.util' isn't there .... it seems to be not included in the source distribution. 'import site' failed; traceback: Traceback (most recent call last): File "//1/Python-2.1a1/Lib/site.py", line 85, in ? from distutils.util import get_platform ImportError: No module named distutils.util ^^^^^^^^^^^^^^ [ clip ..] >This is probably in the realm of the distutils. I have no idea how to >teach it to build on QNX, sorry! IMHO ... it is not a path problem. In the moment there is no time left for me to go into these details. A clean port will happen in a few weeks. Please check out PyQNX for news regarding QNX4.25 and QNX6.0 (aka QNX Neutrino). Greetings Armin Steinhoff Life-Demo of PyDACHS http://www.dachs.net/PyDACHS_python-tilcon.htm in our booth at Embedded Systems 2001, Nuremberg, GER http://www.embedded-systems-messe.de Febr. 14-16, 2000 Hall 11, Booth P 04

1 0

Nightly CVS tarballs
by Martin v. Loewis 27 Jan '01

27 Jan '01

> Is there any chance of reactivating the nightly tarball generation > that was once in place ? What's wrong with http://cvs.sourceforge.net/cvstarballs/python-cvsroot.tar.gz ? Regards, Martin

3 3

setup.py
by M.-A. Lemburg 27 Jan '01

27 Jan '01

I have posted two messages here regarding the new setup.py mechanism for building Modules/ but have received no comments on them so far. Here's another go: 1. I think that setup.py should output warnings about modules which cannot be built for some reason rather than having ot the build process completely. 2. I suggest adding -L/usr/lib/termcap to the readline extension. This doesn't hurt anywhere and will get this extension to compile on SuSE Linux too. Thoughts ? -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

4 6

Nightly CVS tarballs
by M.-A. Lemburg 27 Jan '01

27 Jan '01

I just got a request from someone who wants to test the latest CVS version but unfortunately can't because he's behind a firewall. Is there any chance of reactivating the nightly tarball generation that was once in place ? http://www.python.org/download/cvs.html Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

3 2

RE: [Python-Dev] problems building Python 2.1a1 on QNX 4.25
by Goodger, David 27 Jan '01

27 Jan '01

Thank you all for your prompt replies. (Guido's was within seconds! Well, minutes, certainly.) I'll give it another go on Monday. I've got renovations to fill my weekend. /David

2 1

Python-Dev January 2001