iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update Pep 294 to Rst.

This commit is contained in:
Matthias Bussonnier 2016-07-06 17:10:04 -07:00
parent 100404228a
commit ff82921f4c
1 changed files with 67 additions and 59 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

126
pep-0294.txt
View File

@ -5,101 +5,109 @@ Last-Modified: $Date$
Author: oren at hishome.net (Oren Tirosh) Author: oren at hishome.net (Oren Tirosh)
Status: Rejected Status: Rejected
Type: Standards Track Type: Standards Track
Content-Type: text/x-rst
Created: 19-Jun-2002 Created: 19-Jun-2002
Python-Version: 2.5 Python-Version: 2.5
Post-History: Post-History:
Abstract Abstract
========
This PEP proposes that symbols matching the type name should be This PEP proposes that symbols matching the type name should be added
added to the types module for all basic Python types in the types to the types module for all basic Python types in the types module::
module:
types.IntegerType -> types.int types.IntegerType -> types.int
types.FunctionType -> types.function types.FunctionType -> types.function
types.TracebackType -> types.traceback types.TracebackType -> types.traceback
... ...
The long capitalized names currently in the types module will be The long capitalized names currently in the types module will be
deprecated. deprecated.
With this change the types module can serve as a replacement for With this change the types module can serve as a replacement for the
the new module. The new module shall be deprecated and listed in new module. The new module shall be deprecated and listed in PEP 4.
PEP 4.
Pronouncement Pronouncement
=============
A centralized repository of type names was a mistake. Neither the A centralized repository of type names was a mistake. Neither the
"types" nor "new" modules should be carried forward to Python 3.0. "types" nor "new" modules should be carried forward to Python 3.0.
In the meantime, it does not make sense to make the proposed updates In the meantime, it does not make sense to make the proposed updates
to the modules. This would cause disruption without any compensating to the modules. This would cause disruption without any compensating
benefit. benefit.
Instead, the problem that some internal types (frames, functions,
etc.) don't live anywhere outside those modules may be addressed by
either adding them to `__builtin__` or sys. This will provide a
smoother transition to Python 3.0.
Instead, the problem that some internal types (frames, functions,
etc.) don't live anywhere outside those modules may be addressed by
either adding them to __builtin__ or sys. This will provide a
smoother transition to Python 3.0.
Rationale Rationale
=========
Using two sets of names for the same objects is redundant and Using two sets of names for the same objects is redundant and
confusing. confusing.
In Python versions prior to 2.2 the symbols matching many type In Python versions prior to 2.2 the symbols matching many type names
names were taken by the factory functions for those types. Now were taken by the factory functions for those types. Now all basic
all basic types have been unified with their factory functions and types have been unified with their factory functions and therefore the
therefore the type names are available to be consistently used to type names are available to be consistently used to refer to the type
refer to the type object. object.
Most types are accessible as either builtins or in the new module Most types are accessible as either builtins or in the new module but
but some types such as traceback and generator are only accssible some types such as traceback and generator are only accssible through
through the types module under names which do not match the type the types module under names which do not match the type name. This
name. This PEP provides a uniform way to access all basic types PEP provides a uniform way to access all basic types under a single
under a single set of names. set of names.
Specification Specification
=============
The types module shall pass the following test: The types module shall pass the following test::
import types import types
for t in vars(types).values(): for t in vars(types).values():
if type(t) is type: if type(t) is type:
assert getattr(types, t.__name__) is t assert getattr(types, t.__name__) is t
The types 'class', 'instance method' and 'dict-proxy' have already The types 'class', 'instance method' and 'dict-proxy' have already
been renamed to the valid Python identifiers 'classobj', been renamed to the valid Python identifiers 'classobj',
'instancemethod' and 'dictproxy', making this possible. 'instancemethod' and 'dictproxy', making this possible.
Backward compatibility Backward compatibility
======================
Because of their widespread use it is not planned to actually Because of their widespread use it is not planned to actually remove
remove the long names from the types module in some future the long names from the types module in some future version. However,
version. However, the long names should be changed in the long names should be changed in documentation and library sources
documentation and library sources to discourage their use in new to discourage their use in new code.
code.
Reference Implementation Reference Implementation
========================
A reference implementation is available in SourceForge patch
#569328: http://www.python.org/sf/569328 A reference implementation is available in bpo #569328:
`<http://bugs.python.org/issue569328>`_
Copyright Copyright
=========
This document has been placed in the public domain. This document has been placed in the public domain.
Local Variables:
mode: indented-text ..
indent-tabs-mode: nil Local Variables:
sentence-end-double-space: t mode: indented-text
fill-column: 70 indent-tabs-mode: nil
End: sentence-end-double-space: t
fill-column: 70
End: