Mailman 3 November 2002 - Python-Dev

Metaclass insanity - another use case
by Phillip J. Eby 06 Nov '02

06 Nov '02

I was reading the "metaclass insanity" thread this morning about dotted __name__ for nested classes, and I thought I should chime in that I've actually *used* this technique. That is, I've had classes of the form: class outer: class inner: ... And then regenerated 'inner' such that inner.__name__ == 'outer.inner' and stored it in globals()['outer.inner']. This *does* work with existing pickle code; in fact it worked as far back as Python 1.5.2! As for *why* I had inner classes, the following might be a good example: class ModelElement(Element): class isSpecification(model.Field): isRequired = 1 qualifiedName = 'Foundation.Core.ModelElement.isSpecification' _XMINames = ('Foundation.Core.ModelElement.isSpecification',) name = 'isSpecification' referencedType = 'Boolean' class stereotype(model.Reference): isNavigable = 0 isRequired = 1 _XMINames = ('Foundation.Core.ModelElement.stereotype',) name = 'stereotype' referencedType = 'Stereotype' refTypeQN = 'Foundation.Core.ModelElement.stereotype' referencedEnd = 'extendedElements' This is a tiny excerpt from some automatically generated code which defines the UML 1.3 metamodel as a set of Python classes. The nested classes represent structural features of the defined outer class, and enforce properties such as multiplicity, requiredness, etc., as you can see. In an earlier version of this work, the inner classes had metaclasses whose __get__ method instantiated the inner class, and placed an instance in the outer object instance. That is, each ModelElement instance would have a 'stereotype' instance created on demand, which would manage the 'stereotype' property. And for this to be picklable, it was necessary for the inner classes to be accessible by the pickle machinery -- hence my use of qualified class names, as described above. I will admit that I no longer use this approach for the inner classes; I found a way to get by without ever instantiating them. The above code is still valid, but the metaclasses used are different. So the pickling is simpler and faster. I'm not sure if this is really an argument for or against, but at least it's actual usage. :)

4 4

Possible ideas from Strongtalk (static typing for Smalltalk)?
by Hamish Lawson 05 Nov '02

05 Nov '02

I recently came across an announcement about the the Strongtalk system, which contains the first fully developed strong, static type system for Smalltalk. I wondered whether there might be useful ideas there for those looking into static typing for Python. http://www.cs.ucsb.edu/projects/strongtalk/pages/index.html Hamish Lawson

2 1

Re: [Python-Dev] [#527371] sre bug/patch
by Guido van Rossum 05 Nov '02

05 Nov '02

> Just be sure to keep the code compatible with Python 1.5.1 (see PEP > 291). Oops, I meant Python 1.5.2. --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

bz2module.c breaks regression tests
by Jeremy Hylton 05 Nov '02

05 Nov '02

I just did a cvs update and a fresh build of Python dies with a segfault immediately after running test_bz2. build-pydebug> ./python ../Lib/test/regrtest.py test_bz2 test_grammar test_bz2 /usr/home/jeremy/src/python/dist/src/Lib/test/test_bz2.py:30: RuntimeWarning: mktemp is a potential security risk to your program self.filename = tempfile.mktemp("bz2") test_grammar Segmentation fault (core dumped) A partial gdb stack trace shows that it's dying in PyObject_Malloc(). I'm running with a debug build of Python. Not sure what, if anything, it would do with a release build. #0 0x080828b7 in PyObject_Malloc (nbytes=17) at ../Objects/obmalloc.c:581 #1 0x08082f5c in _PyObject_DebugMalloc (nbytes=1) at ../Objects/obmalloc.c:992 #2 0x080553e5 in parsetok (tok=0x81b2fc0, g=0x81466a8, start=257, err_ret=0xbfffdfe0, flags=0) at ../Parser/parsetok.c:137 #3 0x08055218 in PyParser_ParseStringFlagsFilename ( s=0x401fcd44 "if 1:\n exec u'z=1+1\\n'\n if z != 2: raise TestFailed, 'exec u\\'z=1+1\\'\\\\n'\n del z\n exec u'z=1+1'\n if z != 2: raise TestFailed, 'exec u\\'z=1+1\\''\n", filename=0x0, g=0x81466a8, start=257, err_ret=0xbfffdfe0, flags=0) at ../Parser/parsetok.c:56 #4 0x08055156 in PyParser_ParseStringFlags ( s=0x401fcd44 "if 1:\n exec u'z=1+1\\n'\n if z != 2: raise TestFailed, 'exec u\\'z=1+1\\'\\\\n'\n del z\n exec u'z=1+1'\n if z != 2: raise TestFailed, 'exec u\\'z=1+1\\''\n", g=0x81466a8, start=257, err_ret=0xbfffdfe0, flags=0) at ../Parser/parsetok.c:31 #5 0x080e653f in PyParser_SimpleParseStringFlags ( str=0x401fcd44 "if 1:\n exec u'z=1+1\\n'\n if z != 2: raise TestFailed, 'exec u\\'z=1+1\\'\\\\n'\n del z\n exec u'z=1+1'\n if z != 2: raise TestFailed, 'exec u\\'z=1+1\\''\n", start=257, flags=0) at ../Python/pythonrun.c:1193 #6 0x080e6580 in PyParser_SimpleParseString ( str=0x401fcd44 "if 1:\n exec u'z=1+1\\n'\n if z != 2: raise TestFailed, 'exec u\\'z=1+1\\'\\\\n'\n del z\n exec u'z=1+1'\n if z != 2: raise TestFailed, 'exec u\\'z=1+1\\''\n", start=257) at ../Python/pythonrun.c:1203 #7 0x080e5fbc in PyRun_String ( str=0x401fcd44 "if 1:\n exec u'z=1+1\\n'\n if z != 2: raise TestFailed, 'exec u\\'z=1+1\\'\\\\n'\n del z\n exec u'z=1+1'\n if z != 2: raise TestFailed, 'exec u\\'z=1+1\\''\n", start=257, globals=0x4020c994, locals=0x4020c3f4) at ../Python/pythonrun.c:1025 #8 0x080c431e in exec_statement (f=0x818410c, prog=0x401fcd28, globals=0x4020c994, locals=0x4020c3f4) at ../Python/ceval.c:3786 #9 0x080bca30 in eval_frame (f=0x818410c) at ../Python/ceval.c:1539 #10 0x080c0b69 in PyEval_EvalCodeEx (co=0x40263b28, globals=0x4020c994, locals=0x0, args=0x815907c, argcount=0, kws=0x815907c, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:2542 #11 0x080c2996 in fast_function (func=0x402222b4, pp_stack=0xbfffe328, n=0, na=0, nk=0) at ../Python/ceval.c:3282 #12 0x080c2818 in call_function (pp_stack=0xbfffe328, oparg=0) at ../Python/ceval.c:3251 #13 0x080beb80 in eval_frame (f=0x8158f24) at ../Python/ceval.c:1997 #14 0x080c0b69 in PyEval_EvalCodeEx (co=0x4021e238, globals=0x4020c994, locals=0x4020c994, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:2542 #15 0x080b6abc in PyEval_EvalCode (co=0x4021e238, globals=0x4020c994, locals=0x4020c994) at ../Python/ceval.c:478 #16 0x080dadc3 in PyImport_ExecCodeModuleEx ( name=0xbfffed48 "test.test_grammar", co=0x4021e238, pathname=0xbfffe440 "/usr/home/jeremy/src/python/dist/src/Lib/test/test_grammar.pyc") at ../Python/import.c:530 Jeremy

4 6

Re: List slice assignment and custom sequences
by Michael Hudson 05 Nov '02

05 Nov '02

On Tue, 5 Nov 2002, Ronald Oussoren wrote: > > On Tuesday, Nov 5, 2002, at 15:03 Europe/Amsterdam, Michael Hudson > wrote: > > > Ronald Oussoren <oussoren(a)cistron.nl> writes: > > > >> No, I want to replace part of a sequence by another sequence. I don't > >> understand _why_ the RHS must be a list if the LHS is one. > > > > Because Objects/listobject.c:list_ass_slice pokes directly into the > > object passed on the RHS. > > > > A patch to change this would have some chance of getting accepted; > > wouldn't like to guess what, but I'd hazard non-zero. > I sure hope so. I've posted a bug+patch at SF for a related problem: > With the introduction of new-style classes 'isinstance(obj, list)' no > longer guarantees that you can savely poke in the RHS instead of using > the __getitem__ accessor function. Hmm, that's something (slightly) else. I wonder if PySequence_FAST should use PyList_CheckExact and not PyList_Chec? Guido? Cheers, M.

2 1

Re: [Python-Dev] metaclass insanity
by Guido van Rossum 05 Nov '02

05 Nov '02

> Keeping a definition of some X (whether X is a class, a function, > whatever) as local as feasible has one obvious merit which I have > already pointed out: a reader of the code need NOT ask himself > "where is this X defined" when X is used, nor "how is this X used" > when X is defined -- the answers become immediately obvious by the > very way the code is structure... X is defined right here and used > right here. Yes. However this is counterbalanced by the distraction for the reader though when the details of X's implementation make it even a moderately large lump of code (above a couple of lines); usually these details aren't of immediate interest to the reader where X is used. > > I also think that it's better that the iterator class *is* > > accessible to the user -- that way you can do an isinstance() > > check for it, for example. > > To me, that's a good reason to AVOID making the class directly > accessible to the user. I find that most uses that programmers > make of type-testing in Python (e.g. with isinstance) are more > damaging than helpful; anything that happens to discourage such > damaging practices therefore looks good to me thereby. So use a name starting with an underscore. That's enough of a hint. > In my experience so far, I find that wrapper classes tend to > be rather small -- maybe that comes from my general style. Wrapper classes are just one example of helper classes. The argument for keeping helper classes out of the way applies broadly. --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Re: [Python-Dev] metaclass insanity
by Christopher Armstrong 05 Nov '02

05 Nov '02

Guido van Russom wrote on Mon, 04 Nov 2002 15:54:48 -0500 > Can someone provide a reason why you'd want to use nested classes? > I've never felt this need myself. What are the motivations? Yes. In Reality (a Twisted Matrix Labs project), a text-based virtual world simulation framework, we have a system that can automatically generate Interface definitions from classes (with a metaclass that builds them at class-def time). Twisted has an Interface/adapter/ componentized system similar to Zope's in twisted.python.components, and we use components/adapters to their fullest in Reality. The problem is, our virtual worlds are persistent, so most of our objects get pickled (or serialized with some similar mechanism), and our objects hold references to these automatically-generated Interfaces. We would *like* to have these automatically-generated Interfaces as attributes of the classes they were generated for, but we have to use a hack that does something like:: setattr(subclass.__module__, interfaceName, NewInterface) This is really horrible, IMO. Anyway, regardless that this may be a somewhat obscure use-case (although one we rely heavily on), It _is_ wrong that str(klass) is lying about its location, and I seriously doubt fixing it would cause any problems. -- Christopher Armstrong << radix(a)twistedmatrix.com >> http://twistedmatrix.com/users/radix.twistd/

2 1

Re: [Python-Dev] metaclass insanity
by Michael Hudson 05 Nov '02

05 Nov '02

Just van Rossum <just(a)letterror.com> writes: > While I'm sure this was just a theoretical example, _this_ specific > case is much easier written as a generator (and I _love_ the idiom > of making the __iter__ method a generator, I think it's > underused...). Maybe it's underused because it hasn't occured to people? It certainly does look neat. Cheers, M. now struggling to think of an iterator that's better done as a class than a generator... -- incidentally, asking why things are "left out of the language" is a good sign that the asker is fairly clueless. -- Erik Naggum, comp.lang.lisp

1 0

Re: [Python-Dev] Becoming a python contributor
by Michael Hudson 05 Nov '02

05 Nov '02

martin(a)v.loewis.de (Martin v. Loewis) writes: > Unfortunately, adding a Status field is not possible on SF. Which reminds me: how much longer are we going to have to put up with SF for bugs? Is the roundup work getting anywhere? Cheers, M. -- > So what does "abc" / "ab" equal? cheese -- Steve Holden defends obscure semantics on comp.lang.python

4 5

[#454030] distutils cannot link C++ code with GCC
by Gustavo Niemeyer 05 Nov '02

05 Nov '02

Can someone please review the proposed solution attached on bug #454030, fixing the following bugs: [#413582] g++ must be called for c++ extensions [#454030] distutils cannot link C++ code with GCC Thank you! -- Gustavo Niemeyer [ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]

1 0