[Python-checkins] CVS: python/nondist/peps pep-0252.txt,NONE,1.1 pep-0000.txt,1.87,1.88

2001年4月19日 14:27:27 -0700

Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv26125
Modified Files:
	pep-0000.txt 
Added Files:
	pep-0252.txt 
Log Message:
Add the first bits of PEP 252, Making Types Look More Like Classes.
--- NEW FILE: pep-0252.txt ---
PEP: 252
Title: Making Types Look More Like Classes
Version: $Revision: 1.1 $
Author: guido@python.org (Jeremy Hylton)
Status: Draft
Type: Standards Track
Python-Version: 2.2
Created: 19-Apr-2001
Post-History:
Abstract
 This PEP proposes changes to the introspection API for types that
 makes them look more like classes. For example, type(x) will be
 equivalent to x.__class__ for most built-in types. When C is
 x.__class__, x.meth(a) will be equivalent to C.meth(x, a), and
 C.__dict__ contains descriptors for x's methods and other
 attributes.
 The PEP also introduces a new approach to specifying attributes,
 using attribute descriptors, or descriptors for short.
 Descriptors unify and generalize several different common
 mechanisms used for describing attributes: a descriptor can be an
 unbound method, a typed field in the object structure, or a
 generalized attribute represented by getter and setter functions
 (or just a getter function, for read-only attributes).
Introduction
 One of Python's oldest language warts is the difference between
 classes and types. For example, you can't directly subclass the
 dictionary type, and the introspection interface for finding out
 what methods and instance variables an object has is different for
 types and for classes.
 Healing the class/type split is a big effort, because it affects
 many aspects of how Python is implemented. This PEP concerns
 itself with making the introspection API for types look the same
 as that for classes. Other PEPs will propose making classes look
 more like types, and subclassing from built-in types; these topics
 are not on the table for this PEP.
Introspection APIs
 Introspection concerns itself with finding out what attributes an
 object has. Python's very general getattr/setattr API makes it
 impossible to guarantee that there always is a way to get a list
 of all attributes supported by a specific object, but in practice
 two conventions have appeared that together work for almost all
 objects.
 The first API is used primarily for class instances; it is also
 used by Digital Creations's ExtensionClasses. It assumes that all
 data attributes of an object x are stored in the dictionary
 x.__dict__, and that all methods and class variables can be found
 by inspection of x's class, written as x.__class__. Classes have
 a __dict__ attribute, which yields a dictionary containing methods
 and class variables defined by the class itself, and a __bases__
 attribute, which is a tuple of base classes that must be inspected
 recursively. Some assumption here are:
 - attributes defined in the instance dict override attributes
 defined by the object's class;
 - attributes defined in a derived class override attributes
 defined in a base class;
 - attributes in an earlier base class (meaning occurring earlier
 in __bases__) override attributes in a later base class.
 (The last two rules together are often summarized as the
 left-to-right, depth-first rule for attribute search.)
 The second introspection API is supported in one form or another
 by most built-in objects. It uses two special attributes,
 __members__ and __methods__. The __members__ attribute, if
 present, is a list of method names supported by the object. The
 __methods__ attribute, if present, is a list of data attribute
 names supported by the object.
 This API is sometimes combined by a __dict__ that works the same
 was as for instances (e.g., for function objects in Python 2.1,
 f.__dict__ contains f's dynamic attributes, while f.__members__
 lists the names of f's statically defined attributes).
 Some caution must be exercised: some objects don't list theire
 "intrinsic" attributes (e.g. __dict__ and __doc__) in __members__,
 while others do; sometimes attribute names that occur both in
 __members__ or __methods__ and as keys in __dict__, in which case
 it's anybody's guess whether the value found in __dict__ is used
 or not.
 This second introspection API has never been carefully specified.
 It is part of folklore, and most 3rd party extensions support it
 because they follow examples that support it. Also, any type that
 uses Py_FindMethod() and/or PyMember_Get() in its tp_getattr
 handler supports it, because these two functions special-case the
 attribute names __methods__ and __members__, respectively.
 Digital Creations's ExtensionClasses ignore the second
 introspection API, and instead emulate the class instance
 introspection API, which is more powerful. In this PEP, I propose
 to phase out the second API in favor of supporting the class
 instance introspection API for all types.
 One argument in favor of the class instance introspection API is
 that it doesn't require you to create an instance in order to find
 out which attributes a type supports; this in turn is useful for
 documentation processors. For example, the socket module exports
 the SocketType object, but this currently doesn't tell us what
 methods are defined on socket objects.
Specification
 XXX
Discussion
 XXX
Examples
 XXX
Backwards compatibility
 XXX
Compatibility of C API
 XXX
Warnings and Errors
 XXX
Implementation
 XXX
References
 XXX

Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:
Index: pep-0000.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0000.txt,v
retrieving revision 1.87
retrieving revision 1.88
diff -C2 -r1.87 -r1.88
*** pep-0000.txt	2001年04月18日 10:27:03	1.87
--- pep-0000.txt	2001年04月19日 21:27:25	1.88
***************
*** 52,55 ****
--- 52,56 ----
 S 250 pep-0250.txt Using site-packages on All Platforms Moore
 I 251 pep-0251.txt Python 2.2 Release Schedule Warsaw
+ S 252 pep-0252.txt Making Types Look More Like Classes van Rossum
 
 Py-in-the-sky PEPs (not ready; may become active yet)
***************
*** 171,174 ****
--- 172,176 ----
 S 250 pep-0250.txt Using site-packages on All Platforms Moore
 I 251 pep-0251.txt Python 2.2 Release Schedule Warsaw
+ S 252 pep-0252.txt Making Types Look More Like Classes van Rossum