[Python-bugs-list] [ python-Bugs-487390 ] Modifying type.__module__ behavior

[noreply@sourceforge.net]

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: 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