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

Merge pull request #48 from Carreau/pep-0294-to-rst 

Update Pep 294 to Rst.
This commit is contained in:
Chris Angelico 2016-07-07 10:15:22 +10:00 committed by GitHub
parent 100404228a ff82921f4c
commit c7a746ddea
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)
Status: Rejected
Type: Standards Track
Content-Type: text/x-rst
Created: 19-Jun-2002
Python-Version: 2.5
Post-History:
Abstract
========
This PEP proposes that symbols matching the type name should be
added to the types module for all basic Python types in the types
module:
This PEP proposes that symbols matching the type name should be added
to the types module for all basic Python types in the types module::
types.IntegerType -> types.int
types.FunctionType -> types.function
types.TracebackType -> types.traceback
...
types.IntegerType -> types.int
types.FunctionType -> types.function
types.TracebackType -> types.traceback
...
The long capitalized names currently in the types module will be
deprecated.
The long capitalized names currently in the types module will be
deprecated.
With this change the types module can serve as a replacement for
the new module. The new module shall be deprecated and listed in
PEP 4.
With this change the types module can serve as a replacement for the
new module. The new module shall be deprecated and listed in PEP 4.
Pronouncement
=============
A centralized repository of type names was a mistake. Neither the
"types" nor "new" modules should be carried forward to Python 3.0.
A centralized repository of type names was a mistake. Neither the
"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
to the modules. This would cause disruption without any compensating
benefit.
In the meantime, it does not make sense to make the proposed updates
to the modules. This would cause disruption without any compensating
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
=========
Using two sets of names for the same objects is redundant and
confusing.
Using two sets of names for the same objects is redundant and
confusing.
In Python versions prior to 2.2 the symbols matching many type
names were taken by the factory functions for those types. Now
all basic types have been unified with their factory functions and
therefore the type names are available to be consistently used to
refer to the type object.
In Python versions prior to 2.2 the symbols matching many type names
were taken by the factory functions for those types. Now all basic
types have been unified with their factory functions and therefore the
type names are available to be consistently used to refer to the type
object.
Most types are accessible as either builtins or in the new module
but some types such as traceback and generator are only accssible
through the types module under names which do not match the type
name. This PEP provides a uniform way to access all basic types
under a single set of names.
Most types are accessible as either builtins or in the new module but
some types such as traceback and generator are only accssible through
the types module under names which do not match the type name. This
PEP provides a uniform way to access all basic types under a single
set of names.
Specification
=============
The types module shall pass the following test:
The types module shall pass the following test::
import types
for t in vars(types).values():
if type(t) is type:
assert getattr(types, t.__name__) is t
import types
for t in vars(types).values():
if type(t) is type:
assert getattr(types, t.__name__) is t
The types 'class', 'instance method' and 'dict-proxy' have already
been renamed to the valid Python identifiers 'classobj',
'instancemethod' and 'dictproxy', making this possible.
The types 'class', 'instance method' and 'dict-proxy' have already
been renamed to the valid Python identifiers 'classobj',
'instancemethod' and 'dictproxy', making this possible.
Backward compatibility
======================
Because of their widespread use it is not planned to actually
remove the long names from the types module in some future
version. However, the long names should be changed in
documentation and library sources to discourage their use in new
code.
Because of their widespread use it is not planned to actually remove
the long names from the types module in some future version. However,
the long names should be changed in documentation and library sources
to discourage their use in new code.
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
=========
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
sentence-end-double-space: t
fill-column: 70
End:
..
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
End: