Ignore changes in the amount of whitespace
Differences between version dated 2005-01-16 19:12:55 and 2005-01-16 23:51:46
Deletions are marked like this.
Additions are marked like this.
prevents users from having to "relearn how to write good code" in order to use
the new features successfully.
This PEP directly competes with PEP 245, which proposes a syntax for
Python interfaces. If some form of this proposal is accepted, it
would be unnecessary for a special interface type or syntax to be added to
Python, since normal classes and partially or completely abstract classes will
be routinely usable as interfaces. Some packages or frameworks, of course, may
have additional requirements for interface features, but they can use
metaclasses to implement such enhanced interfaces without impeding their
ability to be used as interfaces by this PEP's system for creating extenders.
Of course, given the number of previous failed attempts to create a type
declaration system for Python, this PEP is an act of extreme optimism, and it
will not be altogether surprising if it, too, ultimately fails. However, if
return value(s).
The problem with this concept is that interface implementations are typically
expected to be complete. In Java, for example, you say that your class
expected to be complete. In Java, for example, you can't say that your class
implements an interface unless you actually add all of the required methods,
even if some of them aren't needed in your program yet.
of more rigid type systems like those of Java or Microsoft's COM (Component
Object Model).
This PEP directly competes with PEP 245, which proposes a syntax for
Python interfaces. If some form of this proposal is accepted, it
would be unnecessary for a special interface type or syntax to be added to
Python, since normal classes and partially or completely abstract classes will
be routinely usable as interfaces. Some packages or frameworks, of course, may
have additional requirements for interface features, but they can use
metaclasses to implement such enhanced interfaces without impeding their
ability to be used as interfaces by this PEP's system for creating extenders.
Specification
form the basis for compatible interfacing between packages; if each package
denotes the relationship between its types' operations and the operations
of the ``file`` type, then those packages can accept other packages' objects
as parameters declared as requiring a ``file`` instance.
as ``:file`` parameters.
However, the standard library cannot contain base versions of all possible
operations for which multiple implementations might exist, so different
such a type, you must fall back to either storing the additional state in the
object itself, using the object to key some other dictionary to obtain the
state, or declaring that your extender can live with potentially inconsistent
states. XXX have a way to declare that state is kept in the extender for this
states.
XXX have a way to declare that state is kept in the extender for this scenario
Using Multiple Extender States
