Fix lists-in-blockquotes in 3xxx PEPs. Ref: #26914
This commit is contained in:
Georg Brandl
parent
56d4eced1d
commit
4d8ea1d0fe
10
pep-3103.txt
10
pep-3103.txt
|
|
@ -567,11 +567,11 @@ when the dispatch dict is frozen for a switch that doesn't occur
|
|||
inside a function. There are a few pragmatic choices for how to treat
|
||||
a switch outside a function:
|
||||
|
||||
(a) Disallow it.
|
||||
(b) Translate it into an if/elif chain.
|
||||
(c) Allow only compile-time constant expressions.
|
||||
(d) Compute the dispatch dict each time the switch is reached.
|
||||
(e) Like (b) but tests that all expressions evaluated are hashable.
|
||||
(a) Disallow it.
|
||||
(b) Translate it into an if/elif chain.
|
||||
(c) Allow only compile-time constant expressions.
|
||||
(d) Compute the dispatch dict each time the switch is reached.
|
||||
(e) Like (b) but tests that all expressions evaluated are hashable.
|
||||
|
||||
Of these, (a) seems too restrictive: it's uniformly worse than (c);
|
||||
and (d) has poor performance for little or no benefits compared to
|
||||
|
|
|
|||
40
pep-3104.txt
40
pep-3104.txt
|
|
@ -295,26 +295,26 @@ path of least resistance is the safer path).
|
|||
|
||||
Many spellings have been suggested for such a declaration:
|
||||
|
||||
- ``scoped x`` [1]_
|
||||
- ``global x in f`` [3]_ (explicitly specify which scope)
|
||||
- ``free x`` [5]_
|
||||
- ``outer x`` [6]_
|
||||
- ``use x`` [9]_
|
||||
- ``global x`` [10]_ (change the meaning of ``global``)
|
||||
- ``nonlocal x`` [11]_
|
||||
- ``global x outer`` [18]_
|
||||
- ``global in x`` [18]_
|
||||
- ``not global x`` [18]_
|
||||
- ``extern x`` [20]_
|
||||
- ``ref x`` [22]_
|
||||
- ``refer x`` [22]_
|
||||
- ``share x`` [22]_
|
||||
- ``sharing x`` [22]_
|
||||
- ``common x`` [22]_
|
||||
- ``using x`` [22]_
|
||||
- ``borrow x`` [22]_
|
||||
- ``reuse x`` [23]_
|
||||
- ``scope f x`` [25]_ (explicitly specify which scope)
|
||||
- ``scoped x`` [1]_
|
||||
- ``global x in f`` [3]_ (explicitly specify which scope)
|
||||
- ``free x`` [5]_
|
||||
- ``outer x`` [6]_
|
||||
- ``use x`` [9]_
|
||||
- ``global x`` [10]_ (change the meaning of ``global``)
|
||||
- ``nonlocal x`` [11]_
|
||||
- ``global x outer`` [18]_
|
||||
- ``global in x`` [18]_
|
||||
- ``not global x`` [18]_
|
||||
- ``extern x`` [20]_
|
||||
- ``ref x`` [22]_
|
||||
- ``refer x`` [22]_
|
||||
- ``share x`` [22]_
|
||||
- ``sharing x`` [22]_
|
||||
- ``common x`` [22]_
|
||||
- ``using x`` [22]_
|
||||
- ``borrow x`` [22]_
|
||||
- ``reuse x`` [23]_
|
||||
- ``scope f x`` [25]_ (explicitly specify which scope)
|
||||
|
||||
The most commonly discussed choices appear to be ``outer``,
|
||||
``global``, and ``nonlocal``. ``outer`` is already used as both a
|
||||
|
|
|
|||
304
pep-3108.txt
304
pep-3108.txt
|
|
@ -70,56 +70,56 @@ distribution for Python for users that rely upon the code.
|
|||
|
||||
* cfmfile
|
||||
|
||||
+ Documented as deprecated since Python 2.4 without an explicit
|
||||
reason.
|
||||
+ Documented as deprecated since Python 2.4 without an explicit
|
||||
reason.
|
||||
|
||||
* cl
|
||||
|
||||
+ Documented as obsolete since Python 2.0 or earlier.
|
||||
+ Interface to SGI hardware.
|
||||
+ Documented as obsolete since Python 2.0 or earlier.
|
||||
+ Interface to SGI hardware.
|
||||
|
||||
* md5
|
||||
|
||||
+ Supplanted by the ``hashlib`` module.
|
||||
+ Supplanted by the ``hashlib`` module.
|
||||
|
||||
* mimetools
|
||||
|
||||
+ Documented as obsolete in a previous version.
|
||||
+ Supplanted by the ``email`` package.
|
||||
+ Documented as obsolete in a previous version.
|
||||
+ Supplanted by the ``email`` package.
|
||||
|
||||
* MimeWriter
|
||||
|
||||
+ Supplanted by the ``email`` package.
|
||||
+ Supplanted by the ``email`` package.
|
||||
|
||||
* mimify
|
||||
|
||||
+ Supplanted by the ``email`` package.
|
||||
+ Supplanted by the ``email`` package.
|
||||
|
||||
* multifile
|
||||
|
||||
+ Supplanted by the ``email`` package.
|
||||
+ Supplanted by the ``email`` package.
|
||||
|
||||
* posixfile
|
||||
|
||||
+ Locking is better done by ``fcntl.lockf()``.
|
||||
+ Locking is better done by ``fcntl.lockf()``.
|
||||
|
||||
* rfc822
|
||||
|
||||
+ Supplanted by the ``email`` package.
|
||||
+ Supplanted by the ``email`` package.
|
||||
|
||||
* sha
|
||||
|
||||
+ Supplanted by the ``hashlib`` package.
|
||||
+ Supplanted by the ``hashlib`` package.
|
||||
|
||||
* sv
|
||||
|
||||
+ Documented as obsolete since Python 2.0 or earlier.
|
||||
+ Interface to obsolete SGI Indigo hardware.
|
||||
+ Documented as obsolete since Python 2.0 or earlier.
|
||||
+ Interface to obsolete SGI Indigo hardware.
|
||||
|
||||
* timing
|
||||
|
||||
+ Documented as obsolete since Python 2.0 or earlier.
|
||||
+ ``time.clock()`` gives better time resolution.
|
||||
+ Documented as obsolete since Python 2.0 or earlier.
|
||||
+ ``time.clock()`` gives better time resolution.
|
||||
|
||||
|
||||
Platform-specific with minimal use [done]
|
||||
|
|
@ -136,120 +136,121 @@ The modules mentioned below are documented. All undocumented modules
|
|||
for the specified platforms will also be removed.
|
||||
|
||||
IRIX
|
||||
///////////
|
||||
////
|
||||
|
||||
The IRIX operating system is no longer produced [#irix-retirement]_.
|
||||
Removing all modules from the plat-irix[56] directory has been deemed
|
||||
reasonable because of this fact.
|
||||
|
||||
+ AL/al
|
||||
+ AL/al
|
||||
|
||||
- Provides sound support on Indy and Indigo workstations.
|
||||
- Both workstations are no longer available.
|
||||
- Code has not been uniquely edited in three years.
|
||||
- Provides sound support on Indy and Indigo workstations.
|
||||
- Both workstations are no longer available.
|
||||
- Code has not been uniquely edited in three years.
|
||||
|
||||
+ cd/CD
|
||||
+ cd/CD
|
||||
|
||||
- CD drive control for SGI systems.
|
||||
- SGI no longer sells machines with IRIX on them.
|
||||
- Code has not been uniquely edited in 14 years.
|
||||
- CD drive control for SGI systems.
|
||||
- SGI no longer sells machines with IRIX on them.
|
||||
- Code has not been uniquely edited in 14 years.
|
||||
|
||||
+ cddb
|
||||
+ cddb
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
+ cdplayer
|
||||
+ cdplayer
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
+ cl/CL/CL_old
|
||||
+ cl/CL/CL_old
|
||||
|
||||
- Compression library for SGI systems.
|
||||
- SGI no longer sells machines with IRIX on them.
|
||||
- Code has not been uniquely edited in 14 years.
|
||||
- Compression library for SGI systems.
|
||||
- SGI no longer sells machines with IRIX on them.
|
||||
- Code has not been uniquely edited in 14 years.
|
||||
|
||||
+ DEVICE/GL/gl/cgen/cgensuport
|
||||
+ DEVICE/GL/gl/cgen/cgensuport
|
||||
|
||||
- GL access, which is the predecessor to OpenGL.
|
||||
- Has not been edited in at least eight years.
|
||||
- Third-party libraries provide better support (PyOpenGL [#pyopengl]_).
|
||||
- GL access, which is the predecessor to OpenGL.
|
||||
- Has not been edited in at least eight years.
|
||||
- Third-party libraries provide better support (PyOpenGL [#pyopengl]_).
|
||||
|
||||
+ ERRNO
|
||||
+ ERRNO
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
+ FILE
|
||||
+ FILE
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
+ FL/fl/flp
|
||||
+ FL/fl/flp
|
||||
|
||||
- Wrapper for the FORMS library [#irix-forms]_
|
||||
- FORMS has not been edited in 12 years.
|
||||
- Library is not widely used.
|
||||
- First eight hits on Google are for Python docs for fl.
|
||||
- Wrapper for the FORMS library [#irix-forms]_
|
||||
- FORMS has not been edited in 12 years.
|
||||
- Library is not widely used.
|
||||
- First eight hits on Google are for Python docs for fl.
|
||||
|
||||
+ fm
|
||||
+ fm
|
||||
|
||||
- Wrapper to the IRIS Font Manager library.
|
||||
- Only available on SGI machines which no longer come with IRIX.
|
||||
- Wrapper to the IRIS Font Manager library.
|
||||
- Only available on SGI machines which no longer come with IRIX.
|
||||
|
||||
+ GET
|
||||
+ GET
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
+ GLWS
|
||||
+ GLWS
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
+ imgfile
|
||||
+ imgfile
|
||||
|
||||
- Wrapper for SGI libimage library for imglib image files
|
||||
(``.rgb`` files).
|
||||
- Python Imaging Library provdes read-only support [#pil]_.
|
||||
- Not uniquely edited in 13 years.
|
||||
- Wrapper for SGI libimage library for imglib image files
|
||||
(``.rgb`` files).
|
||||
- Python Imaging Library provdes read-only support [#pil]_.
|
||||
- Not uniquely edited in 13 years.
|
||||
|
||||
+ IN
|
||||
+ IN
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
+ IOCTL
|
||||
+ IOCTL
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
+ jpeg
|
||||
+ jpeg
|
||||
|
||||
- Wrapper for JPEG (de)compressor.
|
||||
- Code not uniquely edited in nine years.
|
||||
- Third-party libraries provide better support
|
||||
(Python Imaging Library [#pil]_).
|
||||
- Wrapper for JPEG (de)compressor.
|
||||
- Code not uniquely edited in nine years.
|
||||
- Third-party libraries provide better support
|
||||
(Python Imaging Library [#pil]_).
|
||||
|
||||
+ panel
|
||||
+ panel
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
+ panelparser
|
||||
+ panelparser
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
+ readcd
|
||||
+ readcd
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
+ SV
|
||||
+ SV
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
+ torgb
|
||||
+ torgb
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
+ WAIT
|
||||
+ WAIT
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
|
||||
Mac-specific modules
|
||||
////////////////////////////
|
||||
////////////////////
|
||||
|
||||
The Mac-specific modules are not well-maintained (e.g., the bgen
|
||||
tool used to auto-generate many of the modules has never been
|
||||
|
|
@ -261,108 +262,107 @@ A stub module for proxy access will be provided for use by urllib.
|
|||
|
||||
* _builtinSuites
|
||||
|
||||
- Undocumented.
|
||||
- Package under lib-scriptpackages.
|
||||
- Undocumented.
|
||||
- Package under lib-scriptpackages.
|
||||
|
||||
* Audio_mac
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
* aepack
|
||||
|
||||
- OSA support is better through third-party modules.
|
||||
- OSA support is better through third-party modules.
|
||||
|
||||
* Appscript [#appscript]_.
|
||||
* Appscript [#appscript]_.
|
||||
|
||||
- Hard-coded endianness which breaks on Intel Macs.
|
||||
- Might need to rename if Carbon package dependent.
|
||||
- Hard-coded endianness which breaks on Intel Macs.
|
||||
- Might need to rename if Carbon package dependent.
|
||||
|
||||
* aetools
|
||||
|
||||
- See aepack.
|
||||
- See aepack.
|
||||
|
||||
* aetypes
|
||||
|
||||
- See aepack.
|
||||
- See aepack.
|
||||
|
||||
* applesingle
|
||||
|
||||
- Undocumented.
|
||||
- AppleSingle is a binary file format for A/UX.
|
||||
- A/UX no longer distributed.
|
||||
- Undocumented.
|
||||
- AppleSingle is a binary file format for A/UX.
|
||||
- A/UX no longer distributed.
|
||||
|
||||
* appletrawmain
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
* appletrunner
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
* argvemulator
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
* autoGIL
|
||||
|
||||
- Very bad model for using Python with the CFRunLoop.
|
||||
- Very bad model for using Python with the CFRunLoop.
|
||||
|
||||
* bgenlocations
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
* buildtools
|
||||
|
||||
- Documented as deprecated since Python 2.3 without an explicit
|
||||
reason.
|
||||
- Documented as deprecated since Python 2.3 without an explicit
|
||||
reason.
|
||||
|
||||
* bundlebuilder
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
* Carbon
|
||||
|
||||
- Carbon development has stopped.
|
||||
- Does not support 64-bit systems completely.
|
||||
- Dependent on bgen which has never been updated to support UCS-4
|
||||
Unicode builds of Python.
|
||||
- Carbon development has stopped.
|
||||
- Does not support 64-bit systems completely.
|
||||
- Dependent on bgen which has never been updated to support UCS-4
|
||||
Unicode builds of Python.
|
||||
|
||||
* CodeWarrior
|
||||
|
||||
- Undocumented.
|
||||
- Package under lib-scriptpackages.
|
||||
- Undocumented.
|
||||
- Package under lib-scriptpackages.
|
||||
|
||||
* ColorPicker
|
||||
|
||||
- Better to use Cocoa for GUIs.
|
||||
- Better to use Cocoa for GUIs.
|
||||
|
||||
* EasyDialogs
|
||||
|
||||
- Better to use Cocoa for GUIs.
|
||||
- Better to use Cocoa for GUIs.
|
||||
|
||||
* Explorer
|
||||
|
||||
- Undocumented.
|
||||
- Package under lib-scriptpackages.
|
||||
- Undocumented.
|
||||
- Package under lib-scriptpackages.
|
||||
|
||||
* Finder
|
||||
|
||||
- Undocumented.
|
||||
- Package under lib-scriptpackages.
|
||||
|
||||
- Undocumented.
|
||||
- Package under lib-scriptpackages.
|
||||
|
||||
* findertools
|
||||
|
||||
- No longer useful.
|
||||
- No longer useful.
|
||||
|
||||
* FrameWork
|
||||
|
||||
- Poorly documented.
|
||||
- Not updated to support Carbon Events.
|
||||
- Poorly documented.
|
||||
- Not updated to support Carbon Events.
|
||||
|
||||
* gensuitemodule
|
||||
|
||||
- See aepack.
|
||||
- See aepack.
|
||||
|
||||
* ic
|
||||
|
||||
|
|
@ -370,85 +370,84 @@ A stub module for proxy access will be provided for use by urllib.
|
|||
|
||||
* icopen
|
||||
|
||||
- Not needed on OS X.
|
||||
- Meant to replace 'open' which is usually a bad thing to do.
|
||||
- Not needed on OS X.
|
||||
- Meant to replace 'open' which is usually a bad thing to do.
|
||||
|
||||
* macerrors
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
* MacOS
|
||||
|
||||
- Would also mean the removal of binhex.
|
||||
- Would also mean the removal of binhex.
|
||||
|
||||
* macostools
|
||||
|
||||
* macresource
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
* MiniAEFrame
|
||||
|
||||
- See aepack.
|
||||
- See aepack.
|
||||
|
||||
* Nav
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
* Netscape
|
||||
|
||||
- Undocumented.
|
||||
- Package under lib-scriptpackages.
|
||||
- Undocumented.
|
||||
- Package under lib-scriptpackages.
|
||||
|
||||
* OSATerminology
|
||||
|
||||
* pimp
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
* PixMapWrapper
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
* StdSuites
|
||||
|
||||
- Undocumented.
|
||||
- Package under lib-scriptpackages.
|
||||
- Undocumented.
|
||||
- Package under lib-scriptpackages.
|
||||
|
||||
* SystemEvents
|
||||
|
||||
- Undocumented.
|
||||
- Package under lib-scriptpackages.
|
||||
- Undocumented.
|
||||
- Package under lib-scriptpackages.
|
||||
|
||||
* Terminal
|
||||
|
||||
- Undocumented.
|
||||
- Package under lib-scriptpackages.
|
||||
|
||||
- Undocumented.
|
||||
- Package under lib-scriptpackages.
|
||||
|
||||
* terminalcommand
|
||||
|
||||
- Undocumented.
|
||||
- Undocumented.
|
||||
|
||||
* videoreader
|
||||
|
||||
- No longer used.
|
||||
- No longer used.
|
||||
|
||||
* W
|
||||
|
||||
- No longer distributed with Python.
|
||||
- No longer distributed with Python.
|
||||
|
||||
|
||||
.. _PyObjC: http://pyobjc.sourceforge.net/
|
||||
|
||||
|
||||
Solaris
|
||||
///////////////
|
||||
///////
|
||||
|
||||
+ SUNAUDIODEV/sunaudiodev
|
||||
+ SUNAUDIODEV/sunaudiodev
|
||||
|
||||
- Access to the sound card on Sun machines.
|
||||
- Code not uniquely edited in over eight years.
|
||||
- Access to the sound card on Sun machines.
|
||||
- Code not uniquely edited in over eight years.
|
||||
|
||||
|
||||
Hardly used [done]
|
||||
|
|
@ -476,7 +475,6 @@ small audience or lack of adherence to more modern standards.
|
|||
+ Only useful with the 'sched' module.
|
||||
+ Not thread-safe.
|
||||
|
||||
|
||||
* stringold
|
||||
|
||||
+ Function versions of the methods on string objects.
|
||||
|
|
@ -769,7 +767,7 @@ thus makes sense to group related modules into packages.
|
|||
|
||||
|
||||
dbm package
|
||||
//////////////////
|
||||
///////////
|
||||
|
||||
================= ===============================
|
||||
Current Name Replacement Name
|
||||
|
|
@ -790,7 +788,7 @@ whichdb dbm.__init__ [1]_
|
|||
|
||||
|
||||
html package
|
||||
///////////////////
|
||||
////////////
|
||||
|
||||
================== ===============================
|
||||
Current Name Replacement Name
|
||||
|
|
@ -801,7 +799,7 @@ htmlentitydefs html.entities
|
|||
|
||||
|
||||
http package
|
||||
///////////////////
|
||||
////////////
|
||||
|
||||
================= ===============================
|
||||
Current Name Replacement Name
|
||||
|
|
@ -819,7 +817,7 @@ cookielib http.cookiejar
|
|||
|
||||
|
||||
tkinter package
|
||||
//////////////////////
|
||||
///////////////
|
||||
|
||||
================== ===============================
|
||||
Current Name Replacement Name
|
||||
|
|
@ -850,7 +848,7 @@ turtle tkinter.turtle
|
|||
|
||||
|
||||
urllib package
|
||||
//////////////////////////////////////////////////
|
||||
//////////////
|
||||
|
||||
Originally this new package was to be named ``url``, but because of
|
||||
the common use of the name as a variable, it has been deemed better
|
||||
|
|
@ -873,7 +871,7 @@ robotparser urllib.robotparser
|
|||
|
||||
|
||||
xmlrpc package
|
||||
/////////////////////
|
||||
//////////////
|
||||
|
||||
================== ===============================
|
||||
Current Name Replacement Name
|
||||
|
|
@ -895,10 +893,8 @@ Issues
|
|||
|
||||
Issues related to this PEP:
|
||||
|
||||
* `Issue 2775`_
|
||||
Master tracking issue
|
||||
* `Issue 2828`_
|
||||
clean up undoc.rst
|
||||
* `Issue 2775`_: Master tracking issue
|
||||
* `Issue 2828`_: clean up undoc.rst
|
||||
|
||||
.. _Issue 2775: http://bugs.python.org/issue2775
|
||||
.. _Issue 2828: http://bugs.python.org/issue2828
|
||||
|
|
|
|||
|
|
@ -190,13 +190,13 @@ Tim Peters reports in [1]_ that PythonLabs considered such a feature
|
|||
at one point, and lists the following additional hooks which aren't
|
||||
currently supported in this PEP:
|
||||
|
||||
* when the module object is deleted from sys.modules
|
||||
* when the module object is deleted from sys.modules
|
||||
|
||||
* when Py_Finalize is called
|
||||
* when Py_Finalize is called
|
||||
|
||||
* when Python exits
|
||||
* when Python exits
|
||||
|
||||
* when the Python DLL is unloaded (Windows only)
|
||||
* when the Python DLL is unloaded (Windows only)
|
||||
|
||||
|
||||
References
|
||||
|
|
|
|||
76
pep-3127.txt
76
pep-3127.txt
|
|
@ -24,14 +24,14 @@ literals will also be valid in 2.6.
|
|||
|
||||
The proposal is that:
|
||||
|
||||
a) octal literals must now be specified
|
||||
with a leading "0o" or "0O" instead of "0";
|
||||
a) octal literals must now be specified
|
||||
with a leading "0o" or "0O" instead of "0";
|
||||
|
||||
b) binary literals are now supported via a
|
||||
leading "0b" or "0B"; and
|
||||
b) binary literals are now supported via a
|
||||
leading "0b" or "0B"; and
|
||||
|
||||
c) provision will be made for binary numbers in
|
||||
string formatting.
|
||||
c) provision will be made for binary numbers in
|
||||
string formatting.
|
||||
|
||||
|
||||
Motivation
|
||||
|
|
@ -39,15 +39,15 @@ Motivation
|
|||
|
||||
This PEP was motivated by two different issues:
|
||||
|
||||
- The default octal representation of integers is silently confusing
|
||||
to people unfamiliar with C-like languages. It is extremely easy
|
||||
to inadvertently create an integer object with the wrong value,
|
||||
because '013' means 'decimal 11', not 'decimal 13', to the Python
|
||||
language itself, which is not the meaning that most humans would
|
||||
assign to this literal.
|
||||
- The default octal representation of integers is silently confusing
|
||||
to people unfamiliar with C-like languages. It is extremely easy
|
||||
to inadvertently create an integer object with the wrong value,
|
||||
because '013' means 'decimal 11', not 'decimal 13', to the Python
|
||||
language itself, which is not the meaning that most humans would
|
||||
assign to this literal.
|
||||
|
||||
- Some Python users have a strong desire for binary support in
|
||||
the language.
|
||||
- Some Python users have a strong desire for binary support in
|
||||
the language.
|
||||
|
||||
|
||||
Specification
|
||||
|
|
@ -175,22 +175,22 @@ literals.
|
|||
Throughout this document, unless otherwise noted, discussions about
|
||||
the string representation of integers relate to these features:
|
||||
|
||||
- Literal integer tokens, as used by normal module compilation,
|
||||
by eval(), and by int(token, 0). (int(token) and int(token, 2-36)
|
||||
are not modified by this proposal.)
|
||||
- Literal integer tokens, as used by normal module compilation,
|
||||
by eval(), and by int(token, 0). (int(token) and int(token, 2-36)
|
||||
are not modified by this proposal.)
|
||||
|
||||
* Under 2.6, long() is treated the same as int()
|
||||
* Under 2.6, long() is treated the same as int()
|
||||
|
||||
- Formatting of integers into strings, either via the % string
|
||||
operator or the new PEP 3101 advanced string formatting method.
|
||||
- Formatting of integers into strings, either via the % string
|
||||
operator or the new PEP 3101 advanced string formatting method.
|
||||
|
||||
It is presumed that:
|
||||
|
||||
- All of these features should have an identical set
|
||||
of supported radices, for consistency.
|
||||
- All of these features should have an identical set
|
||||
of supported radices, for consistency.
|
||||
|
||||
- Python source code syntax and int(mystring, 0) should
|
||||
continue to share identical behavior.
|
||||
- Python source code syntax and int(mystring, 0) should
|
||||
continue to share identical behavior.
|
||||
|
||||
|
||||
Removal of old octal syntax
|
||||
|
|
@ -239,14 +239,14 @@ Assume the rare complete newcomer to computing who *does*, either
|
|||
occasionally or as a matter of habit, use leading zeros for decimal
|
||||
numbers. Python could either:
|
||||
|
||||
a) silently do the wrong thing with his numbers, as it does now;
|
||||
a) silently do the wrong thing with his numbers, as it does now;
|
||||
|
||||
b) immediately disabuse him of the notion that this is viable syntax
|
||||
(and yes, the SyntaxWarning should be more gentle than it
|
||||
currently is, but that is a subject for a different PEP); or
|
||||
b) immediately disabuse him of the notion that this is viable syntax
|
||||
(and yes, the SyntaxWarning should be more gentle than it
|
||||
currently is, but that is a subject for a different PEP); or
|
||||
|
||||
c) let him continue to think that computers are happy with
|
||||
multi-digit decimal integers which start with "0".
|
||||
c) let him continue to think that computers are happy with
|
||||
multi-digit decimal integers which start with "0".
|
||||
|
||||
Some people passionately believe that (c) is the correct answer,
|
||||
and they would be absolutely right if we could be sure that new
|
||||
|
|
@ -416,16 +416,16 @@ attention in the discussion on Python-3000. There are several
|
|||
(sometimes conflicting) requirements and "nice-to-haves" for
|
||||
this syntax:
|
||||
|
||||
- It should be as compatible with other languages and
|
||||
previous versions of Python as is reasonable, both
|
||||
for the input syntax and for the output (e.g. string
|
||||
% operator) syntax.
|
||||
- It should be as compatible with other languages and
|
||||
previous versions of Python as is reasonable, both
|
||||
for the input syntax and for the output (e.g. string
|
||||
% operator) syntax.
|
||||
|
||||
- It should be as obvious to the casual observer as
|
||||
possible.
|
||||
- It should be as obvious to the casual observer as
|
||||
possible.
|
||||
|
||||
- It should be easy to visually distinguish integers
|
||||
formatted in the different bases.
|
||||
- It should be easy to visually distinguish integers
|
||||
formatted in the different bases.
|
||||
|
||||
|
||||
Proposed syntaxes included things like arbitrary radix prefixes,
|
||||
|
|
|
|||
|
|
@ -144,9 +144,9 @@ John Nagle suggested consideration of Unicode Technical Standard #39,
|
|||
It's not clear how that can precisely apply to this PEP; possible
|
||||
consequences are
|
||||
|
||||
* warn about characters listed as "restricted" in xidmodifications.txt
|
||||
* warn about identifiers using mixed scripts
|
||||
* somehow perform Confusable Detection
|
||||
* warn about characters listed as "restricted" in xidmodifications.txt
|
||||
* warn about identifiers using mixed scripts
|
||||
* somehow perform Confusable Detection
|
||||
|
||||
In the latter two approaches, it's not clear how precisely the
|
||||
algorithm should work. For mixed scripts, certain kinds of mixing
|
||||
|
|
|
|||
66
pep-3137.txt
66
pep-3137.txt
|
|
@ -58,11 +58,11 @@ Naming
|
|||
|
||||
I propose the following type names at the Python level:
|
||||
|
||||
- ``bytes`` is an immutable array of bytes (PyString)
|
||||
- ``bytes`` is an immutable array of bytes (PyString)
|
||||
|
||||
- ``bytearray`` is a mutable array of bytes (PyBytes)
|
||||
- ``bytearray`` is a mutable array of bytes (PyBytes)
|
||||
|
||||
- ``memoryview`` is a bytes view on another object (PyMemory)
|
||||
- ``memoryview`` is a bytes view on another object (PyMemory)
|
||||
|
||||
The old type named ``buffer`` is so similar to the new type
|
||||
``memoryview``, introduce by PEP 3118, that it is redundant. The rest
|
||||
|
|
@ -116,27 +116,27 @@ Constructors
|
|||
There are four forms of constructors, applicable to both bytes and
|
||||
bytearray:
|
||||
|
||||
- ``bytes(<bytes>)``, ``bytes(<bytearray>)``, ``bytearray(<bytes>)``,
|
||||
``bytearray(<bytearray>)``: simple copying constructors, with the
|
||||
note that ``bytes(<bytes>)`` might return its (immutable)
|
||||
argument, but ``bytearray(<bytearray>)`` always makes a copy.
|
||||
- ``bytes(<bytes>)``, ``bytes(<bytearray>)``, ``bytearray(<bytes>)``,
|
||||
``bytearray(<bytearray>)``: simple copying constructors, with the
|
||||
note that ``bytes(<bytes>)`` might return its (immutable)
|
||||
argument, but ``bytearray(<bytearray>)`` always makes a copy.
|
||||
|
||||
- ``bytes(<str>, <encoding>[, <errors>])``, ``bytearray(<str>,
|
||||
<encoding>[, <errors>])``: encode a text string. Note that the
|
||||
``str.encode()`` method returns an *immutable* bytes object. The
|
||||
<encoding> argument is mandatory; <errors> is optional.
|
||||
<encoding> and <errrors>, if given, must be ``str`` instances.
|
||||
- ``bytes(<str>, <encoding>[, <errors>])``, ``bytearray(<str>,
|
||||
<encoding>[, <errors>])``: encode a text string. Note that the
|
||||
``str.encode()`` method returns an *immutable* bytes object. The
|
||||
<encoding> argument is mandatory; <errors> is optional.
|
||||
<encoding> and <errrors>, if given, must be ``str`` instances.
|
||||
|
||||
- ``bytes(<memory view>)``, ``bytearray(<memory view>)``: construct
|
||||
a bytes or bytearray object from anything that implements the PEP
|
||||
3118 buffer API.
|
||||
- ``bytes(<memory view>)``, ``bytearray(<memory view>)``: construct
|
||||
a bytes or bytearray object from anything that implements the PEP
|
||||
3118 buffer API.
|
||||
|
||||
- ``bytes(<iterable of ints>)``, ``bytearray(<iterable of ints>)``:
|
||||
construct a bytes or bytearray object from a stream of integers in
|
||||
range(256).
|
||||
- ``bytes(<iterable of ints>)``, ``bytearray(<iterable of ints>)``:
|
||||
construct a bytes or bytearray object from a stream of integers in
|
||||
range(256).
|
||||
|
||||
- ``bytes(<int>)``, ``bytearray(<int>)``: construct a
|
||||
zero-initialized bytes or bytearray object of a given length.
|
||||
- ``bytes(<int>)``, ``bytearray(<int>)``: construct a
|
||||
zero-initialized bytes or bytearray object of a given length.
|
||||
|
||||
Comparisons
|
||||
-----------
|
||||
|
|
@ -190,26 +190,26 @@ Operators
|
|||
The following operators are implemented by the bytes and bytearray
|
||||
types, except where mentioned:
|
||||
|
||||
- ``b1 + b2``: concatenation. With mixed bytes/bytearray operands,
|
||||
the return type is that of the first argument (this seems arbitrary
|
||||
until you consider how ``+=`` works).
|
||||
- ``b1 + b2``: concatenation. With mixed bytes/bytearray operands,
|
||||
the return type is that of the first argument (this seems arbitrary
|
||||
until you consider how ``+=`` works).
|
||||
|
||||
- ``b1 += b2``: mutates b1 if it is a bytearray object.
|
||||
- ``b1 += b2``: mutates b1 if it is a bytearray object.
|
||||
|
||||
- ``b * n``, ``n * b``: repetition; n must be an integer.
|
||||
- ``b * n``, ``n * b``: repetition; n must be an integer.
|
||||
|
||||
- ``b *= n``: mutates b if it is a bytearray object.
|
||||
- ``b *= n``: mutates b if it is a bytearray object.
|
||||
|
||||
- ``b1 in b2``, ``b1 not in b2``: substring test; b1 can be any
|
||||
object implementing the PEP 3118 buffer API.
|
||||
- ``b1 in b2``, ``b1 not in b2``: substring test; b1 can be any
|
||||
object implementing the PEP 3118 buffer API.
|
||||
|
||||
- ``i in b``, ``i not in b``: single-byte membership test; i must
|
||||
be an integer (if it is a length-1 bytes array, it is considered
|
||||
to be a substring test, with the same outcome).
|
||||
- ``i in b``, ``i not in b``: single-byte membership test; i must
|
||||
be an integer (if it is a length-1 bytes array, it is considered
|
||||
to be a substring test, with the same outcome).
|
||||
|
||||
- ``len(b)``: the number of bytes.
|
||||
- ``len(b)``: the number of bytes.
|
||||
|
||||
- ``hash(b)``: the hash value; only implemented by the bytes type.
|
||||
- ``hash(b)``: the hash value; only implemented by the bytes type.
|
||||
|
||||
Note that the % operator is *not* implemented. It does not appear
|
||||
worth the complexity.
|
||||
|
|
|
|||
|
|
@ -426,8 +426,8 @@ This code will obviously fail once this PEP is implemented.
|
|||
To support this use case, we'll add two new methods to the `imp`
|
||||
package [17]_:
|
||||
|
||||
* `imp.cache_from_source(py_path)` -> `pyc_path`
|
||||
* `imp.source_from_cache(pyc_path)` -> `py_path`
|
||||
* `imp.cache_from_source(py_path)` -> `pyc_path`
|
||||
* `imp.source_from_cache(pyc_path)` -> `py_path`
|
||||
|
||||
Alternative implementations are free to override these functions to
|
||||
return reasonable values based on their own support for this PEP.
|
||||
|
|
|
|||
20
pep-3149.txt
20
pep-3149.txt
|
|
@ -117,9 +117,9 @@ Python implementations *MAY* include additional flags in the file name
|
|||
tag as appropriate. For example, on POSIX systems these flags will
|
||||
also contribute to the file name:
|
||||
|
||||
* ``--with-pydebug`` (flag: ``d``)
|
||||
* ``--with-pymalloc`` (flag: ``m``)
|
||||
* ``--with-wide-unicode`` (flag: ``u``)
|
||||
* ``--with-pydebug`` (flag: ``d``)
|
||||
* ``--with-pymalloc`` (flag: ``m``)
|
||||
* ``--with-wide-unicode`` (flag: ``u``)
|
||||
|
||||
By default in Python 3.2, ``configure`` enables ``--with-pymalloc`` so
|
||||
shared library file names would appear as ``foo.cpython-32m.so``.
|
||||
|
|
@ -224,13 +224,13 @@ by adding a keyword argument to the ``Extension`` class, such as::
|
|||
Martin v. Löwis describes his thoughts [7]_ about the applicability of this
|
||||
PEP to PEP 384. In summary:
|
||||
|
||||
* ``--with-pydebug`` would not be supported by the stable ABI because
|
||||
this changes the layout of ``PyObject``, which is an exposed
|
||||
structure.
|
||||
* ``--with-pymalloc`` has no bearing on the issue.
|
||||
* ``--with-wide-unicode`` is trickier, though Martin's inclination is
|
||||
to force the stable ABI to use a ``Py_UNICODE`` that matches the
|
||||
platform's ``wchar_t``.
|
||||
* ``--with-pydebug`` would not be supported by the stable ABI because
|
||||
this changes the layout of ``PyObject``, which is an exposed
|
||||
structure.
|
||||
* ``--with-pymalloc`` has no bearing on the issue.
|
||||
* ``--with-wide-unicode`` is trickier, though Martin's inclination is
|
||||
to force the stable ABI to use a ``Py_UNICODE`` that matches the
|
||||
platform's ``wchar_t``.
|
||||
|
||||
|
||||
Alternatives
|
||||
|
|
|
|||
38
pep-3150.txt
38
pep-3150.txt
|
|
@ -60,15 +60,15 @@ substitute for such a statement for purely syntactic purposes. The
|
|||
current list of simple statements that would be affected by this
|
||||
addition is as follows:
|
||||
|
||||
* expression statement
|
||||
* assignment statement
|
||||
* augmented assignment statement
|
||||
* del statement
|
||||
* return statement
|
||||
* yield statement
|
||||
* raise statement
|
||||
* assert statement
|
||||
* pass statement
|
||||
* expression statement
|
||||
* assignment statement
|
||||
* augmented assignment statement
|
||||
* del statement
|
||||
* return statement
|
||||
* yield statement
|
||||
* raise statement
|
||||
* assert statement
|
||||
* pass statement
|
||||
|
||||
The ``given`` clause would allow subexpressions to be referenced by
|
||||
name in the header line, with the actual definitions following in
|
||||
|
|
@ -238,17 +238,17 @@ Based on the similar guidelines already present for ``try`` statements, this
|
|||
PEP proposes the following additions for ``given`` statements to the
|
||||
"Programming Conventions" section of PEP 8:
|
||||
|
||||
- for code that could reasonably be factored out into a separate function,
|
||||
but is not currently reused anywhere, consider using a ``given`` clause.
|
||||
This clearly indicates which variables are being used only to define
|
||||
subcomponents of another statement rather than to hold algorithm or
|
||||
application state. This is an especially useful technique when
|
||||
passing multi-line functions to operations which take callable
|
||||
arguments.
|
||||
- for code that could reasonably be factored out into a separate function,
|
||||
but is not currently reused anywhere, consider using a ``given`` clause.
|
||||
This clearly indicates which variables are being used only to define
|
||||
subcomponents of another statement rather than to hold algorithm or
|
||||
application state. This is an especially useful technique when
|
||||
passing multi-line functions to operations which take callable
|
||||
arguments.
|
||||
|
||||
- keep ``given`` clauses concise. If they become unwieldy, either break
|
||||
them up into multiple steps or else move the details into a separate
|
||||
function.
|
||||
- keep ``given`` clauses concise. If they become unwieldy, either break
|
||||
them up into multiple steps or else move the details into a separate
|
||||
function.
|
||||
|
||||
|
||||
Rationale
|
||||
|
|
|
|||
Loading…
Reference in New Issue