Mailman 3 May 2002 - Python-Dev

bug: mro, subclassing and equality
by Josh Hoyt 31 May '02

31 May '02

Hello, I found a bug in Python 2.2.1, that I think is related to method resolution order and type initialization. I'm pretty new to Python, so bear with me while I try to explain. The following code: class Nanite(type): key = "blargchoo" def __eq__(self, other): return self.key == other.key def crashbang(): """KILL!""" c1 = type("molly", (Nanite,), {}) p1 = type('parent1', (), {}) p2 = type('parent2', (), {}) c1('child', (p1, p2), {}) causes the interpreter to seg fault. GDB tells me that it's crashing in typeobject.c, at line 1217. I made the following change, based on a bit of copy-coding, without actually tracing the full execution path, and it seemed to fix the problem, but hopefully someone here knows enough that they can tell whether I just made the symptom go away or this actually fixes the problem: *************** *** 1213,1224 **** /* Look in tp_dict of types in MRO */ mro = type->tp_mro; ! if (mro == NULL) { ! n = 0; ! } else { ! assert(PyTuple_Check(mro)); ! n = PyTuple_GET_SIZE(mro); ! } for (i = 0; i < n; i++) { base = PyTuple_GET_ITEM(mro, i); if (PyClass_Check(base)) --- 1213,1220 ---- /* Look in tp_dict of types in MRO */ mro = type->tp_mro; ! assert(PyTuple_Check(mro)); ! n = PyTuple_GET_SIZE(mro); for (i = 0; i < n; i++) { base = PyTuple_GET_ITEM(mro, i); if (PyClass_Check(base)) Thanks, Josh Hoyt <josh(a)janrain.com> Software Engineer JanRain, Inc.

2 1

Re: Python-Dev digest, Vol 1 #2276 - 14 msgs
by Kevin Butler 31 May '02

31 May '02

I asked about publishing a module & submodules in one .py file, and showed an implementation. Guido responded: > I think it's much better to split it up in multiple files than to use > all those hacks. Those hacks are hard to understand for someone > trying to read the code. I agree - I don't like the look of that code for user-level code. However, to me the complexity was that I had to show the implementation (and the dynamic "getMethods" call instead of explicitly listing methods to publish). If the 'imp' module had a 'publish_module' method that created a module (with an optional dictionary?) & registered it in sys.modules, client code becomes very simple, clear, and can be very explicit: assertions = imp.publish_module( __name__ + ".assertions" ) _a = Assertions() assertions.failUnless = _a.failUnless # ... Is that more pleasant, or is the whole idea of organizing portions of a single file into submodules unacceptable? kb

2 1

Re: [Python-Dev] Single .py file contains submodule?
by Kevin Butler 31 May '02

31 May '02

M.-A. Lemburg wrote: > Kevin Butler wrote: > > from unittest.assertions import * > > That's bad style (at least for modules which don't only include > constants). Why would you want to enable this ? :-) - In general, if you provide a submodule, users can do 'from unittest import assertions' or 'import unittest.assertions as test' or some such. Just having a grundle of top-level symbols in a module is less convenient than appropriate grouping into submodules. - The Style Guide suggests prefixing methods that are intended for use with 'import *', and these functions are 'test*' or 'assert*'... - For test code, I tend to be a bit more liberal with 'import *', because in general, test code is pretty clear about what it is exercising. - The assertion methods are very independent of the other TestCase methods, and can be very useful for non-TestCase methods. This low coupling/high cohesion suggests organizing them together, but currently there's no convenient way to get at them separately. And since the methods really have little to do with an object instance, I find the 'self.assert*' construct distracting, although I like self.* in most cases. kb

2 1

Distutils confuses Berkeley DB and dbm?
by Skip Montanaro 31 May '02

31 May '02

Would someone on Linux please try the following: import dbm f = dbm.open("foo", "c") f["1"] = "1" f.close then ask the file command what kind of file it is. On my system it tells me the file is a Berkeley DB 1.85 hash file. I figure that distutils is getting ahold of the libdb dbm-compatibility include files and libraries and using them. On my system, the only ndbm.h is in /usr/include/db1. Here's how the dbm module builds on my system: building 'dbm' extension gcc -DNDEBUG -O3 -fPIC -I. -I/home/skip/src/python/head/dist/src/./Include -I/usr/local/include \ -IInclude/ -c /home/skip/src/python/head/dist/src/Modules/dbmmodule.c -o \ build/temp.linux-i686-2.3/dbmmodule.o gcc -shared build/temp.linux-i686-2.3/dbmmodule.o -L/usr/local/lib -ldb1 \ -o build/lib.linux-i686-2.3/dbm.so I know there is a bug report open about something related to building Berkeley DB-based modules, but I'm offline at the moment so I can't check it. Barry, were you going to look at this? How about a little collaboration? I think I'm mostly responsible for what distutils does as far as building bsddb. Skip

5 13

Making distutils string-free?
by Guido van Rossum 31 May '02

31 May '02

I notice distutils still imports the string module instead of using string methods. Is it still necessary that this codebase runs with Python 1.5.2? If not, someone can start working on removing the string module references. (The sre module needs to run under 1.5.2, per agreement with /F, so it has to keep using the string module.) --Guido van Rossum (home page: http://www.python.org/~guido/)

8 19

Removing types module from stdlib
by Neal Norwitz 31 May '02

31 May '02

Should I start converting/removing uses of the types module where possible? So where we have: assert type(lineno) is types.IntType assert type(lineno) in (types.IntType, types.LongType) would become: assert type(lineno) is int assert type(lineno) in (int, long) or assert isinstance(lineno, int) assert isinstance(lineno, (int, long)) Preferences? Neal

6 12

Re: [Python-Dev] String module
by Raymond Hettinger 31 May '02

31 May '02

> > Maybe you can do a patch for isxxx() methods instead? > > Will do. I need to un-volunteer on this one. The string module already has a bunch of isxxx methods and I'm not clear which others are needed or how to make them vary by locale. Raymond Hettinger

11 22

Single .py file contains submodule?
by Kevin Butler 31 May '02

31 May '02

Guido wrote: > (Barry prefers that there's only one class per file; fortunately I > don't have that hangup. :-) So how about a single .py file containing a module and one-or-more submodules? (Sounds like Barry will definitely not like it... ;-) ) Specifically, I wanted to allow easy isolated import of the PyUnit assertion functions, something like: from unittest.assertions import * There are a few ways of refactoring unittest.py to support this, but part of the beauty of PyUnit is the single, independent file. Consulting the Python Reference Manual, I couldn't find anything that forbade a single file from containing submodules, so I came up with the following implementation, which works in Jython 2.1 and Python 2.2: import new import sys import types class Assertions: failureException = AssertionError def failUnless(self, expr, msg=None): """Fail the test unless the expression is true.""" if not expr: raise self.failureException, msg #... def __publishAsModule( name, dict ): submodule = new.module( name ) submodule.__dict__.update( dict ) sys.modules[ name ] = submodule return submodule def __getMethods( instance ): methods = {} for name, member in instance.__class__.__dict__.items(): if type( member ) is types.FunctionType: methods[name] = getattr( instance, name ) return methods assertions = __publishAsModule( __name__ + ".assertions", __getMethods( Assertions() ) ) So, is this an egregious abuse of a regrettable oversight in the specification, or a reasonable way to publish multiple modules from a single .py file? Thanks kb

6 6

Re: [Python-Dev] New bugtracker project
by Matthias Urlichs 31 May '02

31 May '02

Guido van Rossum: >[David] > > For one thing, it was basically impossible for people with only a > > peripheral view of the database (managers, QA folks) to get accurate > > pictures of the database. Nothing that can't be fixed if one has a > > real DB backend. Currently it uses bsddb or anydbm. Backends for SQL or ZODB should certainly be writeable, the question is whether they'll be useful. Looking through the roundup code, a SQL backend looks like a good idea. The code for finding elements needs to be rewritten (currently it's not database specific and just scans everything -- that doesn't scale), but other than that it should be relatively straightforward. A ZODB backend should also be writebale, though I don't have enough experience with ZODB to say whether making all classes inherit from Persist and removing the marshalling code is enough. ;-) Both backends are limited to read-only access from outside Roundup, though. If not, triggers and journalling won't work. >Speaking of which, how real is RoundUp's DB backend? Does it use >MySQL? *Could* it use MySQL? *Should* it use MySQL? Umm, please s/MySQL/SQL/, as there are more databases out there -- besides, recommending MySQL is sure to provoke a flame war. (ACID may or may not work 100%, no views, no sub-selects, ...) -- Matthias Urlichs

7 8

Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib/test test_signal.py,1.9,1.10
by Michael Hudson 31 May '02

31 May '02

martin(a)v.loewis.de (Martin v. Loewis) writes: > Michael Hudson <mwh(a)python.net> writes: > > > It doesn't fail if you disable threading. Oh /good/. > > > > Does anyone want to explain BSD threads and their interaction with > > signals to me? > > I believe this is an overgeneralization in question. Well, yes. I think I've found enough to the relavent bits of FreeBSD source to answer at least some of my own questions now (libc_r/uthread/uthread_sig.c, for the curious). > Thread implementations in BSD vary from "distribution to > distribution" (Free, Net, Open), and may also vary from release to > release. That's what makes this such a fun game <1e-9 wink>. > For example, one of them recently dropped the libc_r library. Didn't know that. Which one? Not Free, by the signs. > Try compiling with the -mt option, unless this is already done; it > appears that this causes the compiler to define things that are > otherwise not defined. $ cc -mt -o sigp sigp.c cc1: Invalid option `t' ? Cheers, M. -- ... when all the programmes on all the channels actually were made by actors with cleft pallettes speaking lines by dyslexic writers filmed by blind cameramen instead of merely seeming like that, it somehow made the whole thing more worthwhile. -- HHGTG, Episode 11

1 0