From: Michael W. Hudson <mwh@python.net>
Date: Mon, 28 Jan 2002 16:06:11 +0000 (+0000)
Subject: It's merge time!  (well, this is the last one for the moment)
X-Git-Tag: v2.2.1c1~220
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=7043010028ae15e3f23b2dc0516d39fd2a3e2359;p=thirdparty%2FPython%2Fcpython.git

It's merge time!  (well, this is the last one for the moment)

Backport gvanrossum's checkin of revision 2.236:

A tentative fix for SF bug #503837 (Roeland Rengelink):
type.__module__ problems (again?)

This simply initializes the __module__ local in a class statement from
the __name__ global.  I'm not 100% sure that this is the correct fix,
although it usually does the right thing.  The problem is that if the
class statement executes in a custom namespace, the __name__ global
may be taken from __builtins__, in which case it would have the value
__builtin__, or it may not exist at all (if the custom namespace also
has a custom __builtins__), in which case the class statement will
fail.

Nevertheless, unless someone finds a better solution, this is a 2.2.1
bugfix too.

(apparently noone has :()
---

diff --git a/Python/compile.c b/Python/compile.c
index 442128495d2d..21342936204f 100644
--- a/Python/compile.c
+++ b/Python/compile.c
@@ -3926,6 +3926,9 @@ compile_classdef(struct compiling *c, node *n)
 	/* classdef: 'class' NAME ['(' testlist ')'] ':' suite */
 	c->c_name = STR(CHILD(n, 1));
 	c->c_private = c->c_name;
+	/* Initialize local __module__ from global __name__ */
+	com_addop_name(c, LOAD_GLOBAL, "__name__");
+	com_addop_name(c, STORE_NAME, "__module__");
 	ch = CHILD(n, NCH(n)-1); /* The suite */
 	doc = get_docstring(c, ch);
 	if (doc != NULL) {