Mailman 3 February 2012 - Python-checkins

peps: Describe two more alternate numbering schemes
by nick.coghlan Feb. 26, 2012

Feb. 26, 2012

http://hg.python.org/peps/rev/a2ad0f016166 changeset: 4086:a2ad0f016166 user: Nick Coghlan <ncoghlan(a)gmail.com> date: Sun Feb 26 15:33:31 2012 +1000 summary: Describe two more alternate numbering schemes files: pep-0413.txt | 68 +++++++++++++++++++++++++++++++++++++++- 1 files changed, 67 insertions(+), 1 deletions(-) diff --git a/pep-0413.txt b/pep-0413.txt --- a/pep-0413.txt +++ b/pep-0413.txt @@ -710,9 +710,75 @@ Other Questions =============== -Why not a date-based versioning scheme? +Why not use the major version number? +------------------------------------- + +The simplest and most logical solution would actually be to map the +major.minor.micro version numbers to the language version, stdlib version +and maintenance release version respectively. + +Instead of releasing Python 3.3.0, we would instead release Python 4.0.0 +and the release cycle would look like:: + + 4.0.0 # Language release + + 4.0.1 # Maintenance release + 4.1.0 # Standard library release + + 4.0.2 # Maintenance release + 4.2.0 # Standard library release + + 4.0.3 # Maintenance release + 4.3.0 # Standard library release + 5.0.0 # Language release + +However, the ongoing pain of the Python 2 -> Python 3 transition (and +associated workarounds like the ``python3`` and ``python2`` symlinks to +refer directly to the desired release series) means that this simple option +isn't viable for historical reasons. + +One way that this simple approach *could* be made to work is to merge the +current major and minor version numbers directly into a 2-digit major +version number:: + + 33.0.0 # Language release + + 33.0.1 # Maintenance release + 33.1.0 # Standard library release + + 33.0.2 # Maintenance release + 33.2.0 # Standard library release + + 33.0.3 # Maintenance release + 33.3.0 # Standard library release + 34.0.0 # Language release + + +Why not use a four part version number? --------------------------------------- +Another simple versioning scheme would just add a "standard library" version +into the existing versioning scheme:: + + 3.3.0.0 # Language release + + 3.3.0.1 # Maintenance release + 3.3.1.0 # Standard library release + + 3.3.0.2 # Maintenance release + 3.3.2.0 # Standard library release + + 3.3.0.3 # Maintenance release + 3.3.3.0 # Standard library release + 3.4.0.0 # Language release + +However, this scheme isn't viable due to backwards compatibility constraints +on the ``sys.version_info`` structure. + + +Why not use a date-based versioning scheme? +------------------------------------------- + Earlier versions of this PEP proposed a date-based versioning scheme for the standard library. However, such a scheme made it very difficult to handle out-of-cycle releases to fix security issues and other critical -- Repository URL: http://hg.python.org/peps

1 0

peps: Propose a simpler sequential version numbering scheme for standard library
by nick.coghlan Feb. 25, 2012

Feb. 25, 2012

http://hg.python.org/peps/rev/f6c8d8af66d7 changeset: 4085:f6c8d8af66d7 user: Nick Coghlan <ncoghlan(a)gmail.com> date: Sun Feb 26 14:53:07 2012 +1000 summary: Propose a simpler sequential version numbering scheme for standard library releases files: pep-0413.txt | 453 ++++++++++++++++++++++---------------- 1 files changed, 259 insertions(+), 194 deletions(-) diff --git a/pep-0413.txt b/pep-0413.txt --- a/pep-0413.txt +++ b/pep-0413.txt @@ -14,8 +14,8 @@ Abstract ======== -This PEP proposes the adoption of a new date-based versioning scheme for -the standard library (distinct from, but coupled to, the existing language +This PEP proposes the adoption of a separate versioning scheme for the +standard library (distinct from, but coupled to, the existing language versioning scheme) that allows accelerated releases of the Python standard library, while maintaining (or even slowing down) the current rate of change in the core language definition. @@ -87,11 +87,11 @@ the lives of the CPython core developers a little easier at the expense of everyone else). -But, if we go back to the primary rationale for increasing the pace of change -(i.e. more timely support for web protocols and related technologies), we can -note that those only require *standard library* changes. That means many -(perhaps even most) of the negative effects on the wider community can be -avoided by explicitly limiting which parts of CPython are affected by the +However, if we go back to the primary rationale for increasing the pace of +change (i.e. more timely support for web protocols and related technologies), +we can note that those only require *standard library* changes. That means +many (perhaps even most) of the negative effects on the wider community can +be avoided by explicitly limiting which parts of CPython are affected by the new release cycle, and allowing other parts to evolve at their current, more sedate, pace. @@ -105,12 +105,12 @@ * Language release: "x.y.0" * Maintenance release: "x.y.z" (where z > 0) -* Standard library release: "x.y (YY.MM)" +* Standard library release: "x.y (xy.z)" (where z > 0) Under this scheme, an unqualified version reference (such as "3.3") would always refer to the most recent corresponding language or maintenance release. It will never be used without qualification to refer to a standard -library release (at least by python-dev - obviously, we can only set an +library release (at least, not by python-dev - obviously, we can only set an example, not force the rest of the Python ecosystem to go along with it). Language releases will continue as they are now, as new versions of the @@ -126,7 +126,8 @@ * changes to the AST * any other significant changes to the compilation toolchain * changes to the core interpreter eval loop -* changes to the C ABI (although the PEP 384 stable ABI must be preserved) +* binary incompatible changes to the C ABI (although the PEP 384 stable ABI + must still be preserved) * bug fixes Maintenance releases will also continue as they do today, being strictly @@ -134,9 +135,9 @@ or radical internal changes are permitted. The new standard library releases will occur in parallel with each -maintenance release and will be qualified with a date-based version -identifier documenting their *actual* release date. Standard library -releases may include the following changes: +maintenance release and will be qualified with a new version identifier +documenting the standard library version. Standard library releases may +include the following changes: * new features in pure Python modules * new features in C extension modules (subject to PEP 399 compatibility @@ -144,6 +145,11 @@ * new features in language builtins (provided the C ABI remains unaffected) * bug fixes from the corresponding maintenance release +Standard library version identifiers are constructed by combining the major +and minor version numbers for the Python language release into a single two +digit number and then appending a sequential standard library version +identifier. + Release Cycle ------------- @@ -152,53 +158,53 @@ actually be published on python.org (using the first 3.3 maintenance release, planned for February 2013 as an example):: - 3.3.1 # Maintenance release - 3.3 (13.02) # Standard library release + 3.3.1 # Maintenance release + 3.3 (33.1) # Standard library release A further 6 months later, the next 3.3 maintenance release would again be accompanied by a new standard library release:: - 3.3.2 # Maintenance release - 3.3 (13.08) # Standard library release + 3.3.2 # Maintenance release + 3.3 (33.2) # Standard library release Again, the standard library release would be binary compatible with the previous language release, merely offering additional features at the Python level. Finally, 18 months after the release of 3.3, a new language release would -be made around the same time as the final 3.3 maintenance release:: +be made around the same time as the final 3.3 maintenance and standard +library releases:: - 3.3.3 # Maintenance release - 3.4.0 # Language release - -Language releases would then contain all the features that are not -permitted in standard library releases: + 3.3.3 # Maintenance release + 3.3 (33.3) # Standard library release + 3.4.0 # Language release The 3.4 release cycle would then follow a similar pattern to that for 3.3:: - 3.4.1 # Maintenance release - 3.4 (14.08) # Standard library release + 3.4.1 # Maintenance release + 3.4 (34.1) # Standard library release - 3.4.2 # Maintenance release - 3.4 (15.02) # Standard library release + 3.4.2 # Maintenance release + 3.4 (34.2) # Standard library release - 3.4.3 # Maintenance release - 3.5 # Language release + 3.4.3 # Maintenance release + 3.4 (34.3) # Standard library release + 3.5.0 # Language release Programmatic Version Identification ----------------------------------- -To expose the new release details programmatically, this PEP proposes the -addition of a new ``sys.stdlib_info`` attribute that records the date based +To expose the new version details programmatically, this PEP proposes the +addition of a new ``sys.stdlib_info`` attribute that records the new standard library version above and beyond the underlying interpreter version. Using the initial Python 3.3 release as an example:: - sys.stdlib_info(year=2012, month=8, micro=0, releaselevel='final', serial=0) + sys.stdlib_info(python=33, version=0, releaselevel='final', serial=0) This information would also be included in the ``sys.version`` string:: - Python 3.3.0 (12.08.0, default, Feb 17 2012, 23:03:41) + Python 3.3.0 (33.0, default, Feb 17 2012, 23:03:41) [GCC 4.6.1] @@ -211,19 +217,11 @@ new release is made incorporating the required bug fixes, as well as any other bug fixes that have been committed since the previous release. -For standard library releases, things are slightly more complicated, as the -corresponding source control branch may contain new features in addition to -bug fixes. If such features exist, then, to provide a comprehensible release, -it would be necessary to: +For standard library releases, the process is essentially the same, but the +corresponding "What's New?" document may require some tidying up for the +release (as the standard library release may incorporate new features, +not just bug fixes). -1. Change the release version number to the date of the current month. -2. Update the What's New, NEWS and documentation to refer to the new release - number. -3. Make the new release. - -(Note: due to this problem with out-of-cycle releases, I'm considering an -alternate standard library version scheme that would use date independent -numbers like "33.1" and "33.2". See `Why a date-based versioning scheme?`_). User Scenarios ============== @@ -249,7 +247,7 @@ **Status quo:** must choose between 3.3 and 2.7 -**This PEP:** must choose between 3.3 (13.02), 3.3 and 2.7. +**This PEP:** must choose between 3.3 (33.1), 3.3 and 2.7. **PEP 407:** must choose between 3.4, 3.3 (LTS) and 2.7. @@ -264,16 +262,15 @@ **Status quo:** minor version differences indicate 18-24 months of language evolution -**This PEP:** same as status quo for language core, or just compare the -standard library version numbers to get a rough time in months. +**This PEP:** same as status quo for language core, standard library version +numbers indicate 6 months of standard library evolution. **PEP 407:** minor version differences indicate 18-24 months of language evolution up to 3.3, then 6 months of language evolution thereafter. -**Verdict:** date based numbering schemes with regular release cycles are -a *much* better way to give novices a rough handle on the currency of -information. Since keeping the minor version implications the same is a gain -for *current* Python users, I'm calling this a win twice over for the schemes +**Verdict:** Since language changes and deprecations can have a much bigger +effect on the accuracy of third party documentation than the addition of new +features to the standard library, I'm calling this a win for the scheme in this PEP. @@ -359,7 +356,7 @@ doesn't currently spell out a specific development strategy. Assuming a 3.3 compatibility branch is adopted (as proposed in this PEP), then the outcome would be much the same, but the version number signalling would be -slightly less clear (since you would have to look up to see if a particular +slightly less clear (since you would have to check to see if a particular release was an LTS release or not). **Verdict:** while not as clear cut as some previous scenarios, I'm still @@ -380,7 +377,7 @@ **This PEP:** look for "version added" or "version changed" markers in the documentation. If written as a bare Python version, such as "3.3", check against ``sys.version_info``. If qualified with a standard library version, -such as "3.3 (13.02)", check against ``sys.stdlib_info``. +such as "3.3 (33.1)", check against ``sys.stdlib_info``. **PEP 407:** same as status quo @@ -415,6 +412,26 @@ fault reports will already include it, and it is easy to request if needed. +CPython release managers, handling a security fix +------------------------------------------------- + +**Status quo:** create a new maintenance release incorporating the security +fix and any other bug fixes under source control. Also create source releases +for any branches open solely for security fixes. + +**This PEP:** same as the status quo for maintenance branches. Also create a +new standard library release (potentially incorporating new features along +with the security fix). For security branches, create source releases for +both the former maintenance branch and the standard library update branch. + +**PEP 407:** same as the status quo for maintenance and security branches, +but handling security fixes for non-LTS releases is currently an open +question. + +**Verdict:** until PEP 407 is updated to actually address this scenario, a +clear win for this PEP. + + Effects ======= @@ -427,10 +444,6 @@ worth of standard library changes, as well as any changes associated with new syntax. -If a release date slips by a month or two, the current proposal is to keep -the planned standard library version number rather than updating it to -reflect the actual release date. - Effect on workflow ------------------ @@ -451,14 +464,15 @@ The "version added" and "version changed" markers for any changes made on the ``3.3-compat`` branch would need to be flagged with both the language -version and the standard library version. For example: "3.3 (13.02)". +version and the standard library version. For example: "3.3 (33.1)". Any changes made directly on the ``default`` branch would just be flagged with "3.4" as usual. -The ``3.3-compat`` branch would be closed after the 3.3+13.08 release, as -the next release at that time will be a full language release and changes -(including standard library changes) should be marked accordingly. +The ``3.3-compat`` branch would be closed to normal development at the +same time as the ``3.3`` maintenance branch. The ``3.3-compat`` branch would +remain open for security fixes for the same period of time as the ``3.3`` +maintenance branch. Effect on bugfix cycle @@ -469,14 +483,14 @@ before the change reaches the ``default`` branch. If critical bugs are found in a maintenance release, then new maintenance and -standard library releases will be created to resolve the problem. The micro -release number will be incremented for both the language version and the -standard library version. +standard library releases will be created to resolve the problem. The final +part of the version number will be incremented for both the language version +and the standard library version. If critical bugs are found in a standard library release that do not affect the associated maintenance release, then only a new standard library release -will be created and only the standard library version's micro release number -will be incremented. +will be created and only the standard library's version number will be +incremented. Note that in these circumstances, the standard library release *may* include additional features, rather than just containing the bug fix. It is @@ -505,8 +519,8 @@ such opinions were justified or not). I believe isolating the increased pace of change to the standard library, -and clearly delineating it with a separate date-based version number will -greatly reassure the rest of the community that no, we're not suddenly +and clearly delineating it with a separate version number will greatly +reassure the rest of the community that no, we're not suddenly asking them to triple their own rate of development. Instead, we're merely going to ship standard library updates for the next language release in 6-monthly installments rather than delaying them all until the next language @@ -541,8 +555,9 @@ cycle, we would see: * What's New in Python 3.3? -* What's New in Python 3.3 (13.02)? -* What's New in Python 3.3 (13.08)? +* What's New in the Python Standard Library 33.1? +* What's New in the Python Standard Library 33.2? +* What's New in the Python Standard Library 33.3? And then finally, we would see the next language release: @@ -564,58 +579,59 @@ One suggestion from Barry Warsaw is to adopt a non-conflicting separate-files-per-change approach, similar to that used by Twisted [2_]. -For this PEP, one possible layout for such an approach (to be adopted -following the initial release of 3.3.0+12.8.0 that will use the current NEWS -process) might look like:: +Given that the current manually updated NEWS file will be used for the 3.3.0 +release, one possible layout for such an approach might look like:: Misc/ + NEWS # Now autogenerated from news_entries news_entries/ - 3.3.1/ # Maintenance branch changes + 3.3/ + NEWS # Original 3.3 NEWS file + maint.1/ # Maintenance branch changes + core/ + <news entries> + builtins/ + <news entries> + extensions/ + <news entries> + library/ + <news entries> + documentation/ + <news entries> + tests/ + <news entries> + compat.1/ # Compatibility branch changes + builtins/ + <news entries> + extensions/ + <news entries> + library/ + <news entries> + documentation/ + <news entries> + tests/ + <news entries> + # Add maint.2, compat.2 etc as releases are made + 3.4/ + core/ + <news entries> builtins/ - <files for builtin changes> + <news entries> extensions/ - <files for extension module changes> + <news entries> library/ - <files for pure Python module changes> + <news entries> documentation/ - <files for documentation changes> + <news entries> tests/ - <files for testing changes> - 3.4.0/ # default branch changes - language/ # Only exists for "x.y.0" - <files for core language changes> - builtins/ - <files for builtin changes> - extensions/ - <files for extension module changes> - library/ - <files for pure Python module changes> - documentation/ - <files for documentation changes> - tests/ - <files for testing changes> - 13.02.0/ # 3.3 compatibility branch changes - builtins/ - <files for builtin changes> - extensions/ - <files for extension module changes> - library/ - <files for pure Python module changes> - documentation/ - <files for documentation changes> - tests/ - <files for testing changes> - NEWS # Now autogenerated from news_entries + <news entries> + # Add maint.1, compat.1 etc as releases are made Putting the version information in the directory heirarchy isn't strictly necessary (since the NEWS file generator could figure out from the version history), but does make it easier for *humans* to keep the different versions in order. -Other layouts are obviously also possible (for example, having separate "3.3" -and "3.4" directories to group entries for each language version and the -associated maintenance and standard library releases). - Other benefits of reduced version coupling ========================================== @@ -633,81 +649,17 @@ *slow down* the rate of change in the language definition. The language moratorium for Python 3.2 effectively slowed that cycle down to *more than 3 years* (3.1: June 2009, 3.3: August 2012) without causing any major -complaints. +problems or complaints. The NEWS file management scheme described above is actually designed to allow us the flexibility to slow down language releases at the same time as standard library releases become more frequent. -As simple example, if a full two years was allowed between 3.3 and 3.4, +As a simple example, if a full two years was allowed between 3.3 and 3.4, the 3.3 release cycle would end up looking like:: - 3.2.4 # Maintenance release - 3.3.0 # Language release - - 3.3.1 # Maintenance release - 3.3 (13.02) # Standard library release - - 3.3.2 # Maintenance release - 3.3 (13.08) # Standard library release - - 3.3.3 # Maintenance release - 3.3 (14.02) # Standard library release - - 3.3.4 # Maintenance release - 3.4.0 # Language release - -The elegance of the proposed NEWS entry layout is that this decision -wouldn't need to be made until after the 13.08 standard library release. At -that point, the ``3.3-compat`` branch could be kept open (thus adding -another standard library release to the cycle), or else it could be closed, -committing to the next release being a full language release. If the -compatibility branch was kept open, the choice between another standard -library release or a full language release would then be available every -6 months after that. - - -Further increasing the pace of standard library development ------------------------------------------------------------ - -A further benefit of the scheme proposed in this PEP is that it almost -*fully* decouples the language release cycle from the standard library -release cycle. The standard library could be updated every 3 months, or -even once a month, without having any flow on effects on the language -version numbering or the perceived stability of the core language. - -While that pace of development isn't practical as long as the binary -installer creation for Windows and Mac OS X involves several manual steps -(including manual testing) and for as long as we don't have separate -"<branch>-release" trees that only receive versions that have been marked as -good by the stable buildbots, it's a useful criterion to keep in mind when -considering proposed new versioning schemes: what if we eventually want -to make standard library releases even *faster* than every 6 months? - -If the practical issues were ever resolved, then the separate date-based -versioning scheme in this PEP could handle it. The approach proposed in -PEP 407 could not (at least, not without a lot of user confusion). - - -Other Questions -=============== - -Why a date-based versioning scheme? ------------------------------------ - -While a date-based scheme does mean additional work in the case of an -out-of-cycle release, it's an easy way to come up with a numbering system -that is clearly orthogonal to the existing versioning scheme used for -language releases. - -Another possibility would just be ``major.minor`` versioning where: - -* major: xy from the corresponding language release (that is, "33" for 3.3) -* minor: release sequence number for the standard library releases - -Then the Python 3.3 release series would look like:: - - 3.3.0 # Language release + 3.2.4 # Maintenance release + 3.3.0 # Language release 3.3.1 # Maintenance release 3.3 (33.1) # Standard library release @@ -715,13 +667,64 @@ 3.3.2 # Maintenance release 3.3 (33.2) # Standard library release - 3.3.3 # Maintenance release - 3.4.0 # Language release + 3.3.3 # Maintenance release + 3.3 (33.3) # Standard library release -Such a scheme would have the advantage of tolerating out-of-cycle releases -without needing to adjust the version numbering for the release, but would -lose the minor benefit of providing clearer age information within the -versioning scheme itself. + 3.3.4 # Maintenance release + 3.3 (33.4) # Standard library release + 3.4.0 # Language release + +The elegance of the proposed branch structure and NEWS entry layout is that +this decision wouldn't really need to be made until shortly before the planned +3.4 release date. At that point, the decision could be made to postpone the +3.4 release and keep the ``3.3`` and ``3.3-compat`` branches open after the +3.3.3 maintenance release and the 3.3 (33.3) standard library release, thus +adding another standard library release to the cycle. The choice between +another standard library release or a full language release would then be +available every 6 months after that. + + +Further increasing the pace of standard library development +----------------------------------------------------------- + +As noted in the previous section, one benefit of the scheme proposed in this +PEP is that it largely decouples the language release cycle from the +standard library release cycle. The standard library could be updated every +3 months, or even once a month, without having any flow on effects on the +language version numbering or the perceived stability of the core language. + +While that pace of development isn't practical as long as the binary +installer creation for Windows and Mac OS X involves several manual steps +(including manual testing) and for as long as we don't have separate +"<branch>-release" trees that only receive versions that have been marked as +good by the stable buildbots, it's still a useful criterion to keep in mind +when considering proposed new versioning schemes: what if we eventually want +to make standard library releases even *faster* than every 6 months? + +If the practical issues were ever resolved, then the separate standard +library versioning scheme in this PEP could handle it. The tagged version +number approach proposed in PEP 407 could not (at least, not without a lot +of user confusion and uncertainty). + + +Other Questions +=============== + +Why not a date-based versioning scheme? +--------------------------------------- + +Earlier versions of this PEP proposed a date-based versioning scheme for +the standard library. However, such a scheme made it very difficult to +handle out-of-cycle releases to fix security issues and other critical +bugs in standard library releases, as it required the following steps: + +1. Change the release version number to the date of the current month. +2. Update the What's New, NEWS and documentation to refer to the new release + number. +3. Make the new release. + +With the sequential scheme now proposed, such releases should at most require +a little tidying up of the What's New document before making the release. Why isn't PEP 384 enough? @@ -737,25 +740,85 @@ migrating to the stable ABI can involve quite a lot of work (especially for extension modules that define a lot of classes). With limited development resources available, any time spent on such a change is time that could -otherwise have been spent working on features that are offer more direct -benefits to end users. +otherwise have been spent working on features that offer more direct benefits +to end users. + +There are also other benefits to separate versioning (as described above) +that are not directly related to the question of binary compatibility with +third party C extensions. + + +Why no binary compatible additions to the C ABI in standard library releases? +----------------------------------------------------------------------------- + +There's a case to be made that *additions* to the CPython C ABI could +reasonably be permitted in standard library releases. This would give C +extension authors the same freedom as any other package or module author +to depend either on a particular language version or on a standard library +version. + +The PEP currently associates the interpreter version with the language +version, and therefore limits major interpreter changes (including C ABI +additions) to the language releases. + +An alternative, internally consistent, approach would be to link the +interpreter version with the standard library version, with only changes that +may affect backwards compatibility limited to language releases. + +Under such a scheme, the following changes would be acceptable in standard +library releases: + +* Standard library updates + + * new features in pure Python modules + * new features in C extension modules (subject to PEP 399 compatibility + requirements) + * new features in language builtins + +* Interpreter implementation updates + + * binary compatible additions to the C ABI + * changes to the compilation toolchain that do not affect the AST or alter + the bytecode magic number + * changes to the core interpreter eval loop + +* bug fixes from the corresponding maintenance release + +And the following changes would be acceptable in language releases: + +* new language syntax +* any updates acceptable in a standard library release +* new deprecation warnings +* removal of previously deprecated features +* changes to the AST +* changes to the emitted bytecode that require altering the magic number +* binary incompatible changes to the C ABI (although the PEP 384 stable ABI + must still be preserved) + +While such an approach could probably be made to work, there does not appear +to be a compelling justification for it, and the approach currently described +in the PEP is simpler and easier to explain. Why not separate out the standard library entirely? --------------------------------------------------- -Because it's a lot of work for next to no pay-off. CPython without the -standard library is useless (the build chain won't even run, let alone the -test suite). You can't create a standalone pure Python standard library -either, because too many "modules" are actually tightly linked in to the -internal details of their respective interpreters (e.g. ``weakref``, ``gc``, -``sys``, ``inspect``, ``ast``). +A concept that is occasionally discussed is the idea of making the standard +library truly independent from the CPython reference implementation. -Creating a separate development branch that is kept compatible with the -previous feature release, and making releases from that branch that are -flagged with a separate date-based version number should provide most of -the benefits of a separate standard library repository with only a fraction -of the pain. +My personal opinion is that actually making such a change would involve a +lot of work for next to no pay-off. CPython without the standard library is +useless (the build chain won't even run, let alone the test suite). You also +can't create a standalone pure Python standard library either, because too +many "standard library modules" are actually tightly linked in to the +internal details of their respective interpreters (for example, the builtins, +``weakref``, ``gc``, ``sys``, ``inspect``, ``ast``). + +Creating a separate CPython development branch that is kept compatible with +the previous language release, and making releases from that branch that are +identified with a separate standard library version number should provide +most of the benefits of a separate standard library repository with only a +fraction of the pain. Acknowledgements -- Repository URL: http://hg.python.org/peps

1 0

cpython (merge 3.2 -> default): Merge 3.2
by eric.araujo Feb. 25, 2012

Feb. 25, 2012

http://hg.python.org/cpython/rev/be4ae700c877 changeset: 75290:be4ae700c877 parent: 75289:4ba743417053 parent: 75288:d0c86cc5a8ba user: Éric Araujo <merwok(a)netwok.org> date: Sun Feb 26 04:07:37 2012 +0100 summary: Merge 3.2 files: Doc/library/logging.rst | 2 +- Lib/distutils/tests/test_sdist.py | 3 ++- Modules/_io/_iomodule.c | 2 +- Modules/_io/textio.c | 2 +- 4 files changed, 5 insertions(+), 4 deletions(-) diff --git a/Doc/library/logging.rst b/Doc/library/logging.rst --- a/Doc/library/logging.rst +++ b/Doc/library/logging.rst @@ -1112,7 +1112,7 @@ If *capture* is ``True``, warnings issued by the :mod:`warnings` module will be redirected to the logging system. Specifically, a warning will be formatted using :func:`warnings.formatwarning` and the resulting string - logged to a logger named ``'py.warnings'`` with a severity of ``'WARNING'``. + logged to a logger named ``'py.warnings'`` with a severity of :const:`WARNING`. If *capture* is ``False``, the redirection of warnings to the logging system will stop, and warnings will be redirected to their original destinations diff --git a/Lib/distutils/tests/test_sdist.py b/Lib/distutils/tests/test_sdist.py --- a/Lib/distutils/tests/test_sdist.py +++ b/Lib/distutils/tests/test_sdist.py @@ -6,6 +6,7 @@ import zipfile from os.path import join from textwrap import dedent +from test.support import captured_stdout, check_warnings, run_unittest try: import zlib @@ -13,7 +14,6 @@ except ImportError: ZLIB_SUPPORT = False -from test.support import captured_stdout, check_warnings, run_unittest from distutils.command.sdist import sdist, show_formats from distutils.core import Distribution @@ -326,6 +326,7 @@ # filling data_files by pointing files in package_data dist.package_data = {'somecode': ['*.txt']} self.write_file((self.tmp_dir, 'somecode', 'doc.txt'), '#') + cmd.formats = ['gztar'] cmd.ensure_finalized() cmd.run() diff --git a/Modules/_io/_iomodule.c b/Modules/_io/_iomodule.c --- a/Modules/_io/_iomodule.c +++ b/Modules/_io/_iomodule.c @@ -59,7 +59,7 @@ "\n" "At the top of the I/O hierarchy is the abstract base class IOBase. It\n" "defines the basic interface to a stream. Note, however, that there is no\n" -"seperation between reading and writing to streams; implementations are\n" +"separation between reading and writing to streams; implementations are\n" "allowed to throw an IOError if they do not support a given operation.\n" "\n" "Extending IOBase is RawIOBase which deals simply with the reading and\n" diff --git a/Modules/_io/textio.c b/Modules/_io/textio.c --- a/Modules/_io/textio.c +++ b/Modules/_io/textio.c @@ -641,7 +641,7 @@ "enabled. With this enabled, on input, the lines endings '\\n', '\\r',\n" "or '\\r\\n' are translated to '\\n' before being returned to the\n" "caller. Conversely, on output, '\\n' is translated to the system\n" - "default line seperator, os.linesep. If newline is any other of its\n" + "default line separator, os.linesep. If newline is any other of its\n" "legal values, that newline becomes the newline when the file is read\n" "and it is returned untranslated. On output, '\\n' is converted to the\n" "newline.\n" -- Repository URL: http://hg.python.org/cpython

1 0

cpython (merge 3.2 -> 3.2): Branch merge
by eric.araujo Feb. 25, 2012

Feb. 25, 2012

http://hg.python.org/cpython/rev/d0c86cc5a8ba changeset: 75288:d0c86cc5a8ba branch: 3.2 parent: 75261:7f651187b25c parent: 75286:e96777f6dc5c user: Éric Araujo <merwok(a)netwok.org> date: Sun Feb 26 04:00:43 2012 +0100 summary: Branch merge files: Doc/library/logging.rst | 2 +- Lib/distutils/tests/test_sdist.py | 3 +- Lib/test/test_tools.py | 39 +++++++++++++++++++ Misc/NEWS | 3 + Modules/_io/_iomodule.c | 2 +- Modules/_io/textio.c | 2 +- 6 files changed, 47 insertions(+), 4 deletions(-) diff --git a/Doc/library/logging.rst b/Doc/library/logging.rst --- a/Doc/library/logging.rst +++ b/Doc/library/logging.rst @@ -1077,7 +1077,7 @@ If *capture* is ``True``, warnings issued by the :mod:`warnings` module will be redirected to the logging system. Specifically, a warning will be formatted using :func:`warnings.formatwarning` and the resulting string - logged to a logger named ``'py.warnings'`` with a severity of ``'WARNING'``. + logged to a logger named ``'py.warnings'`` with a severity of :const:`WARNING`. If *capture* is ``False``, the redirection of warnings to the logging system will stop, and warnings will be redirected to their original destinations diff --git a/Lib/distutils/tests/test_sdist.py b/Lib/distutils/tests/test_sdist.py --- a/Lib/distutils/tests/test_sdist.py +++ b/Lib/distutils/tests/test_sdist.py @@ -6,6 +6,7 @@ import zipfile from os.path import join from textwrap import dedent +from test.support import captured_stdout, check_warnings, run_unittest try: import zlib @@ -13,7 +14,6 @@ except ImportError: ZLIB_SUPPORT = False -from test.support import captured_stdout, check_warnings, run_unittest from distutils.command.sdist import sdist, show_formats from distutils.core import Distribution @@ -326,6 +326,7 @@ # filling data_files by pointing files in package_data dist.package_data = {'somecode': ['*.txt']} self.write_file((self.tmp_dir, 'somecode', 'doc.txt'), '#') + cmd.formats = ['gztar'] cmd.ensure_finalized() cmd.run() diff --git a/Lib/test/test_tools.py b/Lib/test/test_tools.py new file mode 100644 --- /dev/null +++ b/Lib/test/test_tools.py @@ -0,0 +1,39 @@ +"""Tests for scripts in the Tools directory. + +This file contains regression tests for some of the scripts found in the +Tools directory of a Python checkout or tarball, such as reindent.py. +""" + +import os +import unittest +import sysconfig +from test import support +from test.script_helper import assert_python_ok + +if not sysconfig.is_python_build(): + # XXX some installers do contain the tools, should we detect that + # and run the tests in that case too? + raise unittest.SkipTest('test irrelevant for an installed Python') + +srcdir = sysconfig.get_config_var('projectbase') +basepath = os.path.join(os.getcwd(), srcdir, 'Tools') + + +class ReindentTests(unittest.TestCase): + script = os.path.join(basepath, 'scripts', 'reindent.py') + + def test_noargs(self): + assert_python_ok(self.script) + + def test_help(self): + rc, out, err = assert_python_ok(self.script, '-h') + self.assertEqual(out, b'') + self.assertGreater(err, b'') + + +def test_main(): + support.run_unittest(ReindentTests) + + +if __name__ == '__main__': + unittest.main() diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -124,6 +124,9 @@ Library ------- +- Issue #13447: Add a test file to host regression tests for bugs in the + scripts found in the Tools directory. + - Issue #6884: Fix long-standing bugs with MANIFEST.in parsing in distutils on Windows. diff --git a/Modules/_io/_iomodule.c b/Modules/_io/_iomodule.c --- a/Modules/_io/_iomodule.c +++ b/Modules/_io/_iomodule.c @@ -58,7 +58,7 @@ "\n" "At the top of the I/O hierarchy is the abstract base class IOBase. It\n" "defines the basic interface to a stream. Note, however, that there is no\n" -"seperation between reading and writing to streams; implementations are\n" +"separation between reading and writing to streams; implementations are\n" "allowed to throw an IOError if they do not support a given operation.\n" "\n" "Extending IOBase is RawIOBase which deals simply with the reading and\n" diff --git a/Modules/_io/textio.c b/Modules/_io/textio.c --- a/Modules/_io/textio.c +++ b/Modules/_io/textio.c @@ -627,7 +627,7 @@ "enabled. With this enabled, on input, the lines endings '\\n', '\\r',\n" "or '\\r\\n' are translated to '\\n' before being returned to the\n" "caller. Conversely, on output, '\\n' is translated to the system\n" - "default line seperator, os.linesep. If newline is any other of its\n" + "default line separator, os.linesep. If newline is any other of its\n" "legal values, that newline becomes the newline when the file is read\n" "and it is returned untranslated. On output, '\\n' is converted to the\n" "newline.\n" -- Repository URL: http://hg.python.org/cpython

1 0

cpython (merge default -> default): Branch merge
by eric.araujo Feb. 25, 2012

Feb. 25, 2012

http://hg.python.org/cpython/rev/4ba743417053 changeset: 75289:4ba743417053 parent: 75287:937b1613d0e6 parent: 75262:39ddcc5c7fb9 user: Éric Araujo <merwok(a)netwok.org> date: Sun Feb 26 04:01:54 2012 +0100 summary: Branch merge files: Doc/tools/sphinxext/layout.html | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Doc/tools/sphinxext/layout.html b/Doc/tools/sphinxext/layout.html --- a/Doc/tools/sphinxext/layout.html +++ b/Doc/tools/sphinxext/layout.html @@ -6,7 +6,7 @@ {% endblock %} {% block extrahead %} <link rel="shortcut icon" type="image/png" href="{{ pathto('_static/py.png', 1) }}" /> - <script type="text/javascript" src="{{ pathto('_static/copybutton.js', 1) }}"></script> + {% if not embedded %}<script type="text/javascript" src="{{ pathto('_static/copybutton.js', 1) }}"></script>{% endif %} {{ super() }} {% endblock %} {% block footer %} -- Repository URL: http://hg.python.org/cpython

1 0

cpython: Port the #6884 fix to packaging
by eric.araujo Feb. 25, 2012

Feb. 25, 2012

http://hg.python.org/cpython/rev/937b1613d0e6 changeset: 75287:937b1613d0e6 parent: 75283:1892f4567b07 user: Éric Araujo <merwok(a)netwok.org> date: Sun Feb 26 04:01:34 2012 +0100 summary: Port the #6884 fix to packaging files: Lib/packaging/manifest.py | 20 +- Lib/packaging/tests/test_manifest.py | 138 +++++++++++--- Misc/NEWS | 2 +- 3 files changed, 117 insertions(+), 43 deletions(-) diff --git a/Lib/packaging/manifest.py b/Lib/packaging/manifest.py --- a/Lib/packaging/manifest.py +++ b/Lib/packaging/manifest.py @@ -272,6 +272,7 @@ Return True if files are found. """ + # XXX docstring lying about what the special chars are? files_found = False pattern_re = _translate_pattern(pattern, anchor, prefix, is_regex) @@ -335,11 +336,14 @@ # IMHO is wrong -- '?' and '*' aren't supposed to match slash in Unix, # and by extension they shouldn't match such "special characters" under # any OS. So change all non-escaped dots in the RE to match any - # character except the special characters. - # XXX currently the "special characters" are just slash -- i.e. this is - # Unix-only. - pattern_re = re.sub(r'((?<!\\)(\\\\)*)\.', r'\1[^/]', pattern_re) - + # character except the special characters (currently: just os.sep). + sep = os.sep + if os.sep == '\\': + # we're using a regex to manipulate a regex, so we need + # to escape the backslash twice + sep = r'\\\\' + escaped = r'\1[^%s]' % sep + pattern_re = re.sub(r'((?<!\\)(\\\\)*)\.', escaped, pattern_re) return pattern_re @@ -366,8 +370,10 @@ # ditch end of pattern character empty_pattern = _glob_to_re('') prefix_re = _glob_to_re(prefix)[:-len(empty_pattern)] - # paths should always use / in manifest templates - pattern_re = "^%s/.*%s" % (prefix_re, pattern_re) + sep = os.sep + if os.sep == '\\': + sep = r'\\' + pattern_re = "^" + sep.join((prefix_re, ".*" + pattern_re)) else: # no prefix -- respect anchor flag if anchor: pattern_re = "^" + pattern_re diff --git a/Lib/packaging/tests/test_manifest.py b/Lib/packaging/tests/test_manifest.py --- a/Lib/packaging/tests/test_manifest.py +++ b/Lib/packaging/tests/test_manifest.py @@ -7,7 +7,22 @@ from packaging.tests import unittest, support -_MANIFEST = """\ +MANIFEST_IN = """\ +include ok +include xo +exclude xo +include foo.tmp +include buildout.cfg +global-include *.x +global-include *.txt +global-exclude *.tmp +recursive-include f *.oo +recursive-exclude global *.x +graft dir +prune dir3 +""" + +MANIFEST_IN_2 = """\ recursive-include foo *.py # ok # nothing here @@ -17,12 +32,17 @@ *.dat *.txt """ -_MANIFEST2 = """\ +MANIFEST_IN_3 = """\ README file1 """ +def make_local_path(s): + """Converts '/' in a string to os.sep""" + return s.replace('/', os.sep) + + class ManifestTestCase(support.TempdirManager, support.LoggingCatcher, unittest.TestCase): @@ -37,7 +57,7 @@ tmpdir = self.mkdtemp() MANIFEST = os.path.join(tmpdir, 'MANIFEST.in') with open(MANIFEST, 'w') as f: - f.write(_MANIFEST) + f.write(MANIFEST_IN_2) manifest = Manifest() manifest.read_template(MANIFEST) @@ -63,27 +83,74 @@ os.chdir(tmpdir) self.write_file('README', 'xxx') self.write_file('file1', 'xxx') - content = StringIO(_MANIFEST2) + content = StringIO(MANIFEST_IN_3) manifest = Manifest() manifest.read_template(content) self.assertEqual(['README', 'file1'], manifest.files) def test_glob_to_re(self): - # simple cases - self.assertEqual(_glob_to_re('foo*'), 'foo[^/]*\\Z(?ms)') - self.assertEqual(_glob_to_re('foo?'), 'foo[^/]\\Z(?ms)') - self.assertEqual(_glob_to_re('foo??'), 'foo[^/][^/]\\Z(?ms)') + sep = os.sep + if os.sep == '\\': + sep = r'\\' - # special cases - self.assertEqual(_glob_to_re(r'foo\\*'), r'foo\\\\[^/]*\Z(?ms)') - self.assertEqual(_glob_to_re(r'foo\\\*'), r'foo\\\\\\[^/]*\Z(?ms)') - self.assertEqual(_glob_to_re('foo????'), r'foo[^/][^/][^/][^/]\Z(?ms)') - self.assertEqual(_glob_to_re(r'foo\\??'), r'foo\\\\[^/][^/]\Z(?ms)') + for glob, regex in ( + # simple cases + ('foo*', r'foo[^%(sep)s]*\Z(?ms)'), + ('foo?', r'foo[^%(sep)s]\Z(?ms)'), + ('foo??', r'foo[^%(sep)s][^%(sep)s]\Z(?ms)'), + # special cases + (r'foo\\*', r'foo\\\\[^%(sep)s]*\Z(?ms)'), + (r'foo\\\*', r'foo\\\\\\[^%(sep)s]*\Z(?ms)'), + ('foo????', r'foo[^%(sep)s][^%(sep)s][^%(sep)s][^%(sep)s]\Z(?ms)'), + (r'foo\\??', r'foo\\\\[^%(sep)s][^%(sep)s]\Z(?ms)'), + ): + regex = regex % {'sep': sep} + self.assertEqual(_glob_to_re(glob), regex) + + def test_process_template_line(self): + # testing all MANIFEST.in template patterns + manifest = Manifest() + l = make_local_path + + # simulated file list + manifest.allfiles = ['foo.tmp', 'ok', 'xo', 'four.txt', + 'buildout.cfg', + # filelist does not filter out VCS directories, + # it's sdist that does + l('.hg/last-message.txt'), + l('global/one.txt'), + l('global/two.txt'), + l('global/files.x'), + l('global/here.tmp'), + l('f/o/f.oo'), + l('dir/graft-one'), + l('dir/dir2/graft2'), + l('dir3/ok'), + l('dir3/sub/ok.txt'), + ] + + for line in MANIFEST_IN.split('\n'): + if line.strip() == '': + continue + manifest._process_template_line(line) + + wanted = ['ok', + 'buildout.cfg', + 'four.txt', + l('.hg/last-message.txt'), + l('global/one.txt'), + l('global/two.txt'), + l('f/o/f.oo'), + l('dir/graft-one'), + l('dir/dir2/graft2'), + ] + + self.assertEqual(manifest.files, wanted) def test_remove_duplicates(self): manifest = Manifest() manifest.files = ['a', 'b', 'a', 'g', 'c', 'g'] - # files must be sorted beforehand + # files must be sorted beforehand (like sdist does) manifest.sort() manifest.remove_duplicates() self.assertEqual(manifest.files, ['a', 'b', 'c', 'g']) @@ -143,6 +210,7 @@ self.assertEqual(manifest.allfiles, ['a.py', 'b.txt']) def test_process_template(self): + l = make_local_path # invalid lines manifest = Manifest() for action in ('include', 'exclude', 'global-include', @@ -153,7 +221,7 @@ # implicit include manifest = Manifest() - manifest.allfiles = ['a.py', 'b.txt', 'd/c.py'] + manifest.allfiles = ['a.py', 'b.txt', l('d/c.py')] manifest._process_template_line('*.py') self.assertEqual(manifest.files, ['a.py']) @@ -161,7 +229,7 @@ # include manifest = Manifest() - manifest.allfiles = ['a.py', 'b.txt', 'd/c.py'] + manifest.allfiles = ['a.py', 'b.txt', l('d/c.py')] manifest._process_template_line('include *.py') self.assertEqual(manifest.files, ['a.py']) @@ -173,31 +241,31 @@ # exclude manifest = Manifest() - manifest.files = ['a.py', 'b.txt', 'd/c.py'] + manifest.files = ['a.py', 'b.txt', l('d/c.py')] manifest._process_template_line('exclude *.py') - self.assertEqual(manifest.files, ['b.txt', 'd/c.py']) + self.assertEqual(manifest.files, ['b.txt', l('d/c.py')]) self.assertNoWarnings() manifest._process_template_line('exclude *.rb') - self.assertEqual(manifest.files, ['b.txt', 'd/c.py']) + self.assertEqual(manifest.files, ['b.txt', l('d/c.py')]) self.assertWarnings() # global-include manifest = Manifest() - manifest.allfiles = ['a.py', 'b.txt', 'd/c.py'] + manifest.allfiles = ['a.py', 'b.txt', l('d/c.py')] manifest._process_template_line('global-include *.py') - self.assertEqual(manifest.files, ['a.py', 'd/c.py']) + self.assertEqual(manifest.files, ['a.py', l('d/c.py')]) self.assertNoWarnings() manifest._process_template_line('global-include *.rb') - self.assertEqual(manifest.files, ['a.py', 'd/c.py']) + self.assertEqual(manifest.files, ['a.py', l('d/c.py')]) self.assertWarnings() # global-exclude manifest = Manifest() - manifest.files = ['a.py', 'b.txt', 'd/c.py'] + manifest.files = ['a.py', 'b.txt', l('d/c.py')] manifest._process_template_line('global-exclude *.py') self.assertEqual(manifest.files, ['b.txt']) @@ -209,50 +277,50 @@ # recursive-include manifest = Manifest() - manifest.allfiles = ['a.py', 'd/b.py', 'd/c.txt', 'd/d/e.py'] + manifest.allfiles = ['a.py', l('d/b.py'), l('d/c.txt'), l('d/d/e.py')] manifest._process_template_line('recursive-include d *.py') - self.assertEqual(manifest.files, ['d/b.py', 'd/d/e.py']) + self.assertEqual(manifest.files, [l('d/b.py'), l('d/d/e.py')]) self.assertNoWarnings() manifest._process_template_line('recursive-include e *.py') - self.assertEqual(manifest.files, ['d/b.py', 'd/d/e.py']) + self.assertEqual(manifest.files, [l('d/b.py'), l('d/d/e.py')]) self.assertWarnings() # recursive-exclude manifest = Manifest() - manifest.files = ['a.py', 'd/b.py', 'd/c.txt', 'd/d/e.py'] + manifest.files = ['a.py', l('d/b.py'), l('d/c.txt'), l('d/d/e.py')] manifest._process_template_line('recursive-exclude d *.py') - self.assertEqual(manifest.files, ['a.py', 'd/c.txt']) + self.assertEqual(manifest.files, ['a.py', l('d/c.txt')]) self.assertNoWarnings() manifest._process_template_line('recursive-exclude e *.py') - self.assertEqual(manifest.files, ['a.py', 'd/c.txt']) + self.assertEqual(manifest.files, ['a.py', l('d/c.txt')]) self.assertWarnings() # graft manifest = Manifest() - manifest.allfiles = ['a.py', 'd/b.py', 'd/d/e.py', 'f/f.py'] + manifest.allfiles = ['a.py', l('d/b.py'), l('d/d/e.py'), l('f/f.py')] manifest._process_template_line('graft d') - self.assertEqual(manifest.files, ['d/b.py', 'd/d/e.py']) + self.assertEqual(manifest.files, [l('d/b.py'), l('d/d/e.py')]) self.assertNoWarnings() manifest._process_template_line('graft e') - self.assertEqual(manifest.files, ['d/b.py', 'd/d/e.py']) + self.assertEqual(manifest.files, [l('d/b.py'), l('d/d/e.py')]) self.assertWarnings() # prune manifest = Manifest() - manifest.files = ['a.py', 'd/b.py', 'd/d/e.py', 'f/f.py'] + manifest.files = ['a.py', l('d/b.py'), l('d/d/e.py'), l('f/f.py')] manifest._process_template_line('prune d') - self.assertEqual(manifest.files, ['a.py', 'f/f.py']) + self.assertEqual(manifest.files, ['a.py', l('f/f.py')]) self.assertNoWarnings() manifest._process_template_line('prune e') - self.assertEqual(manifest.files, ['a.py', 'f/f.py']) + self.assertEqual(manifest.files, ['a.py', l('f/f.py')]) self.assertWarnings() diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -502,7 +502,7 @@ scripts found in the Tools directory. - Issue #6884: Fix long-standing bugs with MANIFEST.in parsing in distutils - on Windows. + on Windows. Also fixed in packaging. - Issue #8033: sqlite3: Fix 64-bit integer handling in user functions on 32-bit architectures. Initial patch by Philippe Devalkeneer. -- Repository URL: http://hg.python.org/cpython

1 0

cpython (3.2): Set archive format explicitly in one distutils test
by eric.araujo Feb. 25, 2012

Feb. 25, 2012

http://hg.python.org/cpython/rev/e96777f6dc5c changeset: 75286:e96777f6dc5c branch: 3.2 user: Éric Araujo <merwok(a)netwok.org> date: Sun Feb 26 02:14:33 2012 +0100 summary: Set archive format explicitly in one distutils test files: Lib/distutils/tests/test_sdist.py | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/Lib/distutils/tests/test_sdist.py b/Lib/distutils/tests/test_sdist.py --- a/Lib/distutils/tests/test_sdist.py +++ b/Lib/distutils/tests/test_sdist.py @@ -6,6 +6,7 @@ import zipfile from os.path import join from textwrap import dedent +from test.support import captured_stdout, check_warnings, run_unittest try: import zlib @@ -13,7 +14,6 @@ except ImportError: ZLIB_SUPPORT = False -from test.support import captured_stdout, check_warnings, run_unittest from distutils.command.sdist import sdist, show_formats from distutils.core import Distribution @@ -326,6 +326,7 @@ # filling data_files by pointing files in package_data dist.package_data = {'somecode': ['*.txt']} self.write_file((self.tmp_dir, 'somecode', 'doc.txt'), '#') + cmd.formats = ['gztar'] cmd.ensure_finalized() cmd.run() -- Repository URL: http://hg.python.org/cpython

1 0

cpython (3.2): Fix typo in “seperat{or,ion}”
by eric.araujo Feb. 25, 2012

Feb. 25, 2012

http://hg.python.org/cpython/rev/042061e98c02 changeset: 75285:042061e98c02 branch: 3.2 user: Éric Araujo <merwok(a)netwok.org> date: Sun Feb 26 02:14:08 2012 +0100 summary: Fix typo in “seperat{or,ion}” files: Modules/_io/_iomodule.c | 2 +- Modules/_io/textio.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Modules/_io/_iomodule.c b/Modules/_io/_iomodule.c --- a/Modules/_io/_iomodule.c +++ b/Modules/_io/_iomodule.c @@ -58,7 +58,7 @@ "\n" "At the top of the I/O hierarchy is the abstract base class IOBase. It\n" "defines the basic interface to a stream. Note, however, that there is no\n" -"seperation between reading and writing to streams; implementations are\n" +"separation between reading and writing to streams; implementations are\n" "allowed to throw an IOError if they do not support a given operation.\n" "\n" "Extending IOBase is RawIOBase which deals simply with the reading and\n" diff --git a/Modules/_io/textio.c b/Modules/_io/textio.c --- a/Modules/_io/textio.c +++ b/Modules/_io/textio.c @@ -627,7 +627,7 @@ "enabled. With this enabled, on input, the lines endings '\\n', '\\r',\n" "or '\\r\\n' are translated to '\\n' before being returned to the\n" "caller. Conversely, on output, '\\n' is translated to the system\n" - "default line seperator, os.linesep. If newline is any other of its\n" + "default line separator, os.linesep. If newline is any other of its\n" "legal values, that newline becomes the newline when the file is read\n" "and it is returned untranslated. On output, '\\n' is converted to the\n" "newline.\n" -- Repository URL: http://hg.python.org/cpython

1 0

cpython (merge 3.2 -> default): Merge from 3.2
by eric.araujo Feb. 25, 2012

Feb. 25, 2012

http://hg.python.org/cpython/rev/1892f4567b07 changeset: 75283:1892f4567b07 parent: 75259:e1740afa1a04 parent: 75282:ade06ef94fbe user: Éric Araujo <merwok(a)netwok.org> date: Sat Feb 25 17:26:44 2012 +0100 summary: Merge from 3.2 files: Lib/test/test_tools.py | 39 ++++++++++++++++++++++++++++++ Misc/NEWS | 3 ++ 2 files changed, 42 insertions(+), 0 deletions(-) diff --git a/Lib/test/test_tools.py b/Lib/test/test_tools.py new file mode 100644 --- /dev/null +++ b/Lib/test/test_tools.py @@ -0,0 +1,39 @@ +"""Tests for scripts in the Tools directory. + +This file contains regression tests for some of the scripts found in the +Tools directory of a Python checkout or tarball, such as reindent.py. +""" + +import os +import unittest +import sysconfig +from test import support +from test.script_helper import assert_python_ok + +if not sysconfig.is_python_build(): + # XXX some installers do contain the tools, should we detect that + # and run the tests in that case too? + raise unittest.SkipTest('test irrelevant for an installed Python') + +srcdir = sysconfig.get_config_var('projectbase') +basepath = os.path.join(os.getcwd(), srcdir, 'Tools') + + +class ReindentTests(unittest.TestCase): + script = os.path.join(basepath, 'scripts', 'reindent.py') + + def test_noargs(self): + assert_python_ok(self.script) + + def test_help(self): + rc, out, err = assert_python_ok(self.script, '-h') + self.assertEqual(out, b'') + self.assertGreater(err, b'') + + +def test_main(): + support.run_unittest(ReindentTests) + + +if __name__ == '__main__': + unittest.main() diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -498,6 +498,9 @@ Library ------- +- Issue #13447: Add a test file to host regression tests for bugs in the + scripts found in the Tools directory. + - Issue #6884: Fix long-standing bugs with MANIFEST.in parsing in distutils on Windows. -- Repository URL: http://hg.python.org/cpython

1 0

cpython (3.2): Use const markup instead of a misleading string literal
by eric.araujo Feb. 25, 2012

Feb. 25, 2012

http://hg.python.org/cpython/rev/bf76fa256c5a changeset: 75284:bf76fa256c5a branch: 3.2 parent: 75282:ade06ef94fbe user: Éric Araujo <merwok(a)netwok.org> date: Sun Feb 26 02:13:30 2012 +0100 summary: Use const markup instead of a misleading string literal files: Doc/library/logging.rst | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Doc/library/logging.rst b/Doc/library/logging.rst --- a/Doc/library/logging.rst +++ b/Doc/library/logging.rst @@ -1077,7 +1077,7 @@ If *capture* is ``True``, warnings issued by the :mod:`warnings` module will be redirected to the logging system. Specifically, a warning will be formatted using :func:`warnings.formatwarning` and the resulting string - logged to a logger named ``'py.warnings'`` with a severity of ``'WARNING'``. + logged to a logger named ``'py.warnings'`` with a severity of :const:`WARNING`. If *capture* is ``False``, the redirection of warnings to the logging system will stop, and warnings will be redirected to their original destinations -- Repository URL: http://hg.python.org/cpython

1 0