[Python-bugs-list] [ python-Bugs-487390 ] Modifying type.__module__ behavior
noreply@sourceforge.net
noreply@sourceforge.net
Sun, 09 Dec 2001 13:32:27 -0800
Bugs item #487390, was opened at 2001-11-29 21:10
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487390&group_id=5470
Category: Type/class unification
Group: Python 2.2
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Burton Radons (loth)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Modifying type.__module__ behavior
Initial Comment:
A __module__ attribute request on a C type will return
__builtin__ if the typeobject.c code cannot find a
period in the type name. This is always incorrect for
extension libraries, and can be a _very_ confusing
error when trying to pickle your types (as the error
makes it seem as if you're supposed to register your
type in __builtin__). I propose that:
A) All builtin Python types have a "__builtin__."
prefixed to their type declaration's name.
B) If the __module__ code cannot find a period, it
raises AttributeError with a somewhat descriptive
message. This would be in the place where it returns
__builtin__.
C) The tp_name comment in Include/object.h describe the
special semantics. "/* 'module.typename' */", for example.
This is a lot of files to change, I know, but it's only
one or two line changes each file. The only code this
should affect is code which is written incorrectly; it
may not understand the name semantics, or it may
actually be registering itself in __builtin__ (as I did
before I figured out what it was doing). Otherwise
we're golden.
----------------------------------------------------------------------
>Comment By: Jack Jansen (jackjansen)
Date: 2001-12-09 13:32
Message:
Logged In: YES
user_id=45365
A question about this patch: is the module name actually used for something? I ask because the Mac toolbox modules have different names, depending on the situation.
The Python programmer will always refer to the modules as something like "Carbon.Win". This, however, is a wrapper module (in Python) that imports the _Win module.
If you use them under command line Python on OSX _Win will live in Lib/lib-dynload, so the "real" name will indeed be "_Win".
If you use them in MacPython, however, _Win will live in the Carbon package, so the "real" name will be "Carbon._Win". Or, I should phrase that differently, if you want to import it afresh you should import it as Carbon._Win (unless you're inside the Carbon package, of course).
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-08 10:00
Message:
Logged In: YES
user_id=6380
Thanks, I've applied the second version of the patch. I'm
closing this because I'm satisfied now.
----------------------------------------------------------------------
Comment By: Burton Radons (loth)
Date: 2001-12-07 21:56
Message:
Logged In: YES
user_id=2441
I should have remembered the test suite, sorry. Pickling
had the highest chance of messing up with the change, but I
didn't even think of trying it with the lovely set of tests
available.
Go ahead, remove the "__builtin__." part of the patch. I've
put up a modified patch that is missing the __builtin__
changes and the change to __module__ behaviour, if you want
one; simple hack job.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-07 21:22
Message:
Logged In: YES
user_id=6380
Thanks. Unfortunately, ten standard tests fail with these
patches.
I have a set of fixes, but I believe that the set of fixes
needed could be much smaller if we did *not* add the
"__builtin__." in front of all built-in types.
Their __module__ will still have the correct value
"__builtin__" because it defaults that way, and various bits
of code that print or test tp_name won't suddenly see
"__builtin__." where it wasn't before.
(The worst case was cPickle, which switches on the first
char of tp_name as a speed hack -- this caused mysterious
failures in test_cookie and test_sre.)
What do you think of this idea? IMO the rest of your patch
still implements an important improvement.
----------------------------------------------------------------------
Comment By: Burton Radons (loth)
Date: 2001-12-07 17:03
Message:
Logged In: YES
user_id=2441
Sorry about the delay. I've attached a patch doing
described and threw in patches to fix Module and Mac type
names as well, if it so pleases. If it does not, I can amend.
Further complications came in with
PyStructSequence_InitType, which sets tp_name to a passed
descriptor's field. I merely patched all the places that
use the function. "__module__" should now be a guaranteed
correct attribute amongst Python and the modules.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-04 08:41
Message:
Logged In: YES
user_id=6380
I agree with this in principle, but I don't hve the time to
make all the changes. Can you submit a patch? Since, as
you say, it's so simple, I wouldn't object against including
it in 2.2c1, if it's submitted in time (2.2c1 is planned for
December 12 -- give us a couple of days before that).
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487390&group_id=5470