Python-Dev March 2014

python-dev@python.org

108 participants
94 discussions

by Antoine Pitrou

Hello, I've created the 3.4 category in the buildbots setup: http://buildbot.python.org/all/waterfall?category=3.4.stable I've also retired 3.2 and 3.3 buildbots. Someone will have to update the text and URLs at https://www.python.org/dev/buildbot/. Regards Antoine.

7 years, 4 months

RFE 20469: ssl.getpeercert() should include extensions

by Andrew M. Hettinger

I thought I'd wait until the 3.4 release before I bothered asking about this: http://bugs.python.org/issue20469 I don't think I'm qualified to actually be writing code for the ssl module, but is there anything else that I can do to help? I could probably put together a demonstration-case if that would be helpful.

7 years, 4 months

PEP 466 (round 3): Python 2 network security enhancements

by Nick Coghlan

And time for round 3 :) Notable changes: - removed the higher level networking modules from the scope of the PEP. They made people nervous, and aren't actually needed to achieved the desired result (at the higher levels, it's much easier for third party pure Python modules like requests to step in and fill the gap, as long as the core SSL infrastructure has been updated) - dropped the sha module from the exemption and explicitly noted that both the sha and md5 modules have been deprecated since Python 2.5 - conditional exemptions are now only granted for things that the security infrastructure depends on, rather than the other way around - answered the OpenSSL question based on MAL and Ned's feedback - added the "2.7-legacy-ssl" branch to the proposal (along with some pointed comments about the development priorities implied by preferring this branch to the one with the improved security infrastructure) - made it even clearer that I consider the situation commercial redistributor's responsibility to clean up, based on the support commitments they have made to their users. The PEP is primarily about changing one specific aspect of our maintenance policies so that the onus is clearly pushed back on them to fill the gap between what their customers want and what upstream volunteers are prepared to do for free - we shouldn't give them the opportunity to hide behind the excuse that we won't let them fix it upstream. Cheers, Nick. ==================================== PEP: 466 Title: Network Security Enhancement Exception for Python 2.7 Version: $Revision$ Last-Modified: $Date$ Author: Nick Coghlan <ncoghlan(a)gmail.com>, Status: Draft Type: Informational Content-Type: text/x-rst Created: 23-Mar-2014 Post-History: 23-Mar-2014 Abstract ======== Most CPython tracker issues are classified as errors in behaviour or proposed enhancements. Most patches to fix behavioural errors are applied to all active maintenance branches. Enhancement patches are restricted to the default branch that becomes the next Python version. This cadence works reasonably well during Python's normal 18-24 month feature release cycle, which is still applicable to the Python 3 series. However, the age of the standard library in Python 2 has now reached a point where it is sufficiently far behind the state of the art in network security protocols for it to be causing real problems in commercial use cases where upgrading to Python 3 in the near term may not be practical. Accordingly, this PEP relaxes the normal restrictions by allowing enhancements to be applied in Python 2.7 maintenance releases for standard library components that have implications for the overall security of the internet. In particular, the exception will apply to: * the ``ssl`` module * the ``hashlib`` module * the ``hmac`` module * the components of the ``random`` and ``os`` modules that the above modules rely on for cryptographic randomness * the version of OpenSSL bundled with the binary installers for Windows and Mac OS X Changes to these modules will still need to undergo normal backwards compatibility assessments, but otherwise they will be kept entirely aligned with the latest feature release of their Python 3 counterparts. This is designed to make it easier to implement secure networked software in Python, even for software that currently needs to remain compatible with the Python 2 series (which includes a lot of network infrastructure software). The development branches will be arranged in such a way that even though any further Python 2.7 releases published by the core development team provide updated network security infrastructure, it will remain possible for downstream redistributors to publish "Python 2.7 with legacy SSL infrastructure" if they choose to do so. While this PEP does not make any changes to the core development team's handling of security-fix-only branches that are no longer in active maintenance, it *does* recommend that commercial redistributors providing extended support periods for the Python standard library either adopt a similar approach to ensuring that the secure networking infrastructure keeps pace with the evolution of the internet, or else disclaim support for the use of older versions in roles that involving connecting directly to the public internet. Exemption Policy ================ Under this policy, the following network security related modules are granted a blanket exemption to the restriction against adding new features in maintenance releases, for the purpose of keeping their APIs aligned with their counterparts in the latest feature release of Python 3: * the ``ssl`` module * the ``hashlib`` module * the ``hmac`` module This exemption applies to *all* proposals to backport backwards compatible changes in these modules to Python 2.7 maintenance releases. This choice is made deliberately to ensure that the "feature or fix?" argument isn't simply replaced by a "security related or not?" argument. These particular modules are inherently security related, and all enhancements to them improve Python's capabilities as a platform for development of secure networked software. As part of this policy, permission is also granted to upgrade to newer feature releases of OpenSSL when preparing the binary installers for new maintenance releases of CPython. Note that the ``sha`` and ``md5`` modules are not covered by this policy, but have been deprecated in favour of ``hashlib`` since Python 2.5 and have been removed entirely in the Python 3 series. In addition to the above blanket exemption, a conditional exemption is granted for these modules that may include some network security related features: * the ``os`` module (specifically ``os.urandom``) * the ``random`` module This more limited exemption for these modules requires that the *specific* enhancement being proposed for backporting needs to be justified as being network security related. This is generally restricted to cases where the feature in question is needed by an update to one of the modules covered by the blanket exemption. Backwards Compatibility Considerations ====================================== This PEP does *not* grant any general exemptions to the usual backwards compatibility policy for maintenance releases. Instead, by explicitly encouraging the use of feature based checks and explicitly opting in to less secure configurations, it is designed to make it easier to provide more "secure by default" behaviour in future feature releases, while still limiting the risk of breaking currently working software when upgrading to a new maintenance release. In *all* cases where this policy is applied to backport enhancements to maintenance releases, it MUST be possible to write cross-version compatible code that operates by "feature detection" (for example, checking for particular attributes in the module), without needing to explicitly check the Python version. It is then up to library and framework code to provide an appropriate warning and fallback behaviour if a desired feature is found to be missing. While some especially security sensitive software MAY fail outright if a desired security feature is unavailable, most software SHOULD instead emit a warning and continue operating using a slightly degraded security configuration. Affected APIs SHOULD be designed to allow library and application code to perform the following actions after detecting the presence of a relevant network security related feature: * explicitly opt in to more secure settings (to allow the use of enhanced security features in older maintenance releases of Python) * explicitly opt in to less secure settings (to allow the use of newer Python feature releases in lower security environments) * determine the default setting for the feature (this MAY require explicit Python version checks to determine the Python feature release, but MUST NOT require checking for a specific maintenance release) Security related changes to other modules (such as higher level networking libraries and data format processing libraries) will continue to be made available as backports and new modules on the Python Package Index, as independent distribution remains the preferred approach to handling software that must continue to evolve to handle changing development requirements independently of the Python 2 standard library. Refer to the `Motivation and Rationale`_ section for a review of the characteristics that make the secure networking infrastructure worthy of special consideration. OpenSSL compatibility --------------------- Under this policy, OpenSSL may be upgraded to more recent feature releases in Python 2.7 maintenance releases. On Linux and most other POSIX systems, the specific version of OpenSSL used already varies, as Python dynamically links to the system provided OpenSSL library by default. For the Windows binary installers, the ``_ssl`` and ``_hashlib`` modules are statically linked with OpenSSL and the associated symbols are not exported. Marc-Andre Lemburg indicates that updating to newer OpenSSL releases in the ``egenix-pyopenssl`` binaries has not resulted in any reported compatibility issues [3]_ The Mac OS X binary installers historically followed the same policy as other POSIX installations and dynamically linked to the Apple provided OpenSSL libraries. However, Apple has now ceased updating these cross-platform libraries, instead requiring that even cross-platform developers adopt Mac OS X specific interfaces to access up to date security infrastructure on their platform. Accordingly, and independently of this PEP, the Mac OS X binary installers were already going to be switched to statically linker newer versions of OpenSSL [4]_ Other Considerations ==================== Maintainability --------------- This policy does NOT represent a commitment by volunteer contributors to actually backport network security related changes from the Python 3 series to the Python 2 series. Rather, it is intended to send a clear signal to potential corporate contributors that the core development team are willing to accept offers of corporate assistance in putting this policy into effect and handling the resulting increase in the Python 2 maintenance load. Backporting security related fixes and enhancements to earlier versions is a common service for commercial redistributors to offer to their customers. This policy represents an explicit invitation to contribute some of those changes back to the upstream community in cases where they are likely to have a broad impact that helps improve the security of the internet as a whole, rather than sitting back and waiting for unpaid volunteers to do it for them. Documentation ------------- All modules covered by this policy MUST include a "Security Considerations" section in their documentation. In addition to any other module specific contents, this section MUST enumerate key security enhancements and fixes (with CVE identifiers where applicable), along with the feature and maintenance releases that first included them. Security releases ----------------- This PEP does not propose any changes to the handling of security releases - those will continue to be source only releases that include only critical security fixes. However, the recommendations for library and application developers are deliberately designed to accommodate commercial redistributors that choose to apply this policy to additional Python release series that are either in security fix only mode, or have been declared "end of life" by the core development team. Whether or not redistributors choose to exercise that option will be up to the individual redistributor. Integration testing ------------------- Third party integration testing services should offer users the ability to test against both the latest Python 2.7 maintenance release and the latest "Python 2.7 with legacy SSL infrastructure" release, to ensure that libraries, frameworks and applications handle the legacy security infrastructure correctly (either failing or degrading gracefully, depending on the security sensitivity of the software). Handling lower security environments with low risk tolerance ------------------------------------------------------------ For better or for worse (mostly worse), there are some environments where the risk of latent security defects is more tolerated than the risk of regressions in maintenance releases. This policy largely excludes these environments from consideration where the modules covered by the exemption are concerned. However, one concession is made for the benefit of such environments: while the main ``2.7`` branch in Mercurial will include the updated network security infrastructure, the development process will be updated to include a ``2.7-legacy-ssl`` branch with the more limited feature set of the original 2.7 network security infrastructure, allowing downstream redistributors to continue to provide Python 2.7 with the legacy SSL infrastructure if they choose to do so. This branch will be tested on the CPython continuous integration infrastructure, but no releases will be made from it by the core development team. As noted above, corporate redistributors and users are expected to provide the additional development effort needed to make this practical. It is not acceptable to expect volunteer contributors to resolve a problem created largely by conservative corporate development practices. Evolution of this Policy ======================== The key requirement for a module to be considered for inclusion in this policy (whether under a blanket or conditional exemption) is that it must have security implications *beyond* the specific application that is written in Python and the system that application is running on. Thus the focus on network security protocols and related cryptographic infrastructure - Python is a popular choice for the development of web services and clients, and thus the capabilities of widely used Python versions have implications for the security design of other services that may themselves be using newer versions of Python or other development languages, but need to interoperate with clients or servers written using older versions of Python. The intent behind this requirement is to minimise any impact that the introduction of this policy may have on the stability and compatibility of maintenance releases. It would be thoroughly counterproductive if end users became as cautious about updating to new Python maintenance releases as they are about updating to new feature releases. Motivation and Rationale ======================== This PEP can be seen as a more targeted version of the "faster standard library release cycle" proposals discussed in PEP 407 and PEP 413, focusing specifically on those areas which have implications beyond the Python community. Background ---------- The creation of this PEP was prompted primarily by the aging SSL support in the Python 2 series. As of March 2014, the Python 2.7 SSL module is approaching four years of age, and the SSL support in the still popular Python 2.6 release had its feature set locked six years ago. These are simply too old to provide a foundation that can be recommended in good conscience for secure networking software that operates over the public internet, especially in an era where it is becoming quite clearly evident that advanced persistent security threats are even more widespread and more indiscriminate in their targeting than had previously been understood. While they represented reasonable security infrastructure in their time, the state of the art has moved on, and we need to investigate mechanisms for effectively providing more up to date network security infrastructure for users that, for whatever reason, are not currently in a position to migrate to Python 3. While the use of the system OpenSSL installation addresses many of these concerns on Linux platforms, it doesn't address all of them, and in the case of the binary installers for Windows and Mac OS X that are published on python.org, the version of OpenSSL used is entirely within the control of the Python core development team, and currently limited to OpenSSL maintenance releases for the version initially shipped with the corresponding Python feature release. With increased popularity comes increased responsibility, and this policy aims to acknowledge the fact that Python's popularity and adoption has now reached a level where some of our design and policy decisions have significant implications beyond the Python development community. As one example, the Python 2 ``ssl`` module does not support the Server Name Identification standard. While it is possible to obtain SNI support by using the third party ``requests`` client library, actually doing so currently requires using not only ``requests`` and its embedded dependencies, but also half a dozen or more additional libraries. The lack of support in the Python 2 series thus serves as an impediment to making effective use of SNI on servers, as Python 2 clients will frequently fail to handle it correctly. Another more critical example is the lack of SSL hostname matching in the Python 2 standard library - it is currently necessary to rely on a third party library, such as ``requests`` or ``backports.ssl_match_hostname`` to obtain that functionality in Python 2. The Python 2 series also remains more vulnerable to remote timing attacks on security sensitive comparisons than the Python 3 series, as it lacks a standard library equivalent to the timing attack resistant ``hmac.compare_digest()`` function. While appropriate secure comparison functions can be implemented in third party extensions, may users don't even consider the issue and use ordinary equality comparisons instead - while a standard library solution doesn't automatically fix that problem, it *does* make the barrier to resolution much lower once the problem is pointed out. My position on the ongoing transition from Python 2 to Python 3 has long been that Python 2 remains a supported platform for the core development team, and that commercial support will remain available well after upstream maintenance ends. However, in the absence of this network security enhancement policy, that position is difficult to justify when it comes to software that operates over the public internet. Just as many developers consider it too difficult to develop truly secure modern networked software in C/C++ (largely due to the challenges associated with manual memory management), I anticipate that in the not too distant future, it will be considered too difficult to develop truly secure modern networked software using the Python 2 series (some developers would argue that we have already reached that point). Alternative: advise developers of networked software to migrate to Python 3 --------------------------------------------------------------------------- This alternative represents the status quo. Unfortunately, it has proven to be unworkable in practice, as the backwards compatibility implications mean that this is a non-trivial migration process for large applications and integration projects. While the tools for migration have evolved to a point where it is possible to migrate even large applications opportunistically and incrementally (rather than all at once) by updating code to run in the large common subset of Python 2 and Python 3, using the most recent technology often isn't a priority in commercial environments. Previously, this was considered an acceptable harm, as while it was an unfortunate problem for the affected developers to have to face, it was seen as an issue between them and their management chain to make the case for infrastructure modernisation, and this case would become naturally more compelling as the Python 3 series evolved. However, now that we're fully aware of the impact the limitations of the Python 2 standard library may be having on the evolution of internet security standards, I no longer believe that it is reasonable to expect platform and application developers to resolve all of the latent defects in an application's Unicode correctness solely in order to gain access to the network security enhancements already available in Python 3. While Ubuntu (and to some extent Debian as well) are committed to porting all default system services and scripts to Python 3, and to removing Python 2 from its default distribution images (but not from its archives), this is a mammoth task and won't be completed for the Ubuntu 14.04 LTS release (at least for the desktop image - it may be achieved for the mobile and server images). Fedora has even more work to do to migrate, and it will take a non-trivial amount of time to migrate the relevant infrastructure components. While Red Hat are also actively working to make it easier for users to use more recent versions of Python on our stable platforms, it's going to take time for those efforts to start having an impact on end users' choice of version, and any such changes also don't benefit the core platform infrastructure that runs in the integrated system Python by necessity. The OpenStack migration to Python 3 is also still in its infancy, and even though that's a project with an extensive and relatively robust automated test suite, it's still large enough that it is going to take quite some time to migrate. And that's just three of the highest profile open source projects that make heavy use of Python. Given the likely existence of large amounts of legacy code that lacks the kind of automated regression test suite needed to help support a migration from Python 2 to Python 3, there are likely to be many cases where reimplementation (perhaps even in Python 3) proves easier than migration. The key point of this PEP is that those situations affect more people than just the developers and users of the affected application: the existence of clients and servers with outdated network security infrastructure becomes something that developers of secure networked services need to take into account as part of their security design, and that's a problem that inhibits the adoption of better security standards. As Terry Reedy noted, if we try to persist with the status quo, the likely outcome is that commercial redistributors will attempt to do something like this on behalf of their customers *anyway*, but in a potentially inconsistent and ad hoc manner. By drawing the scope definition process into the upstream project we are in a better position to influence the approach taken to address the situation and to help ensure some consistency across redistributors. The problem is real, so *something* needs to change, and this PEP describes my currently preferred approach to addressing the situation. Alternative: create and release Python 2.8 ------------------------------------------ With sufficient corporate support, it likely *would* be possible to create and release Python 2.8 (it's highly unlikely such a project would garner enough interest to be achievable with only volunteers). However, this wouldn't actually solve the problem, as the aim is to provide a *relatively low impact* way to incorporate enhanced security features into integrated products and deployments that make use of Python 2. Upgrading to a new Python feature release would mean both more work for the core development team, as well as a more disruptive update that most potential end users would likely just skip entirely. Attempting to create a Python 2.8 release would also bring in suggestions to backport many additional features from Python 3 (such as ``tracemalloc`` and the improved coroutine support), making the migration from Python 2.7 to this hypothetical 2.8 release even riskier and more disruptive. This is not a recommended approach, as it would involve substantial additional work for a result that is actually less effective in achieving the original aim (which is to eliminate the current widespread use of the aging network security infrastructure in the Python 2 series). Alternative: distribute the security enhancements via PyPI ---------------------------------------------------------- While this initially appears to be an attractive and easier to manage approach, it actually suffers from several significant problems. Firstly, this is complex, low level, cross-platform code that integrates with the underlying operating system across a variety of POSIX platforms (including Mac OS X) and Windows. The CPython BuildBot fleet is already set up to handle continuous integration in that context, but most of the freely available continuous integration services just offer Linux, and perhaps paid access to Windows. Those services work reasonably well for software that largely runs on the abstraction layers offered by Python and other dynamic languages, as well as the more comprehensive abstraction offered by the JVM, but won't suffice for the kind of code involved here. The OpenSSL dependency for the network security support also qualifies as the kind of "complex binary dependency" that isn't yet handled well by the ``pip`` based software distribution ecosystem. Relying on a third party binary dependency also creates potential compatibility problems for ``pip`` when running on other interpreters like ``PyPy``. Another practical problem with the idea is the fact that ``pip`` itself relies on the ``ssl`` support in the standard library (with some additional support from a bundled copy of ``requests``, which in turn bundles ``backport.ssl_match_hostname``), and hence would require any replacement module to also be bundled within ``pip``. This wouldn't pose any insurmountable difficulties (it's just another dependency to vendor), but it *would* mean yet another copy of OpenSSL to keep up to date. This approach also has the same flaw as all other "improve security by renaming things" approaches: they completely miss the users who most need help, and raise significant barriers against being able to encourage users to do the right thing when their infrastructure supports it (since "use this other module" is a much higher impact change than "turn on this higher security setting"). Deprecating the aging SSL infrastructure in the standard library in favour of an external module would be even more user hostile than accepting the slightly increased risk of regressions associated with upgrading it in place. Last, but certainly not least, this approach suffers from the same problem as the idea of doing a Python 2.8 release: likely not solving the actual problem. Commercial redistributors of Python are set up to redistribute *Python*, and a pre-existing set of additional packages. Getting new packages added to the pre-existing set *can* be done, but means approaching each and every redistributor and asking them to update their repackaging process accordingly. By contrast, the approach described in this PEP would require redistributors to deliberately *opt out* of the security enhancements (by switching to redistributing directly from the ``2.7-legacy-ssl`` branch rather than the main ``2.7`` branch), which most of them are unlikely to do. Open Questions ============== * I believe I've addressed all the technical and scope questions I had, or others raised. That just leaves the question of "If we agree to this plan, who is actually going to handle all the extra work involved?" :) Disclosure of Interest ====================== The author of this PEP currently works for Red Hat on test automation tools. If this proposal is accepted, I will be strongly encouraging Red Hat to take advantage of the resulting opportunity to help improve the overall security of the Python ecosystem. However, I do not speak for Red Hat in this matter, and cannot make any commitments on Red Hat's behalf. Acknowledgements ================ Thanks to Christian Heimes for his recent efforts on greatly improving Python's SSL support in the Python 3 series, and a variety of members of the Python community for helping me to better understand the implications of the default settings we provide in our SSL modules, and the impact that tolerating the use of SSL infrastructure that was defined in 2010 (Python 2.7) or even 2008 (Python 2.6) potentially has for the security of the web as a whole. Christian and Donald Stufft also provided valuable feedback on a preliminary draft of this proposal. Thanks also to participants in the python-dev mailing list threads [1,2]_ References ========== .. [1] https://mail.python.org/pipermail/python-dev/2014-March/133334.html .. [2] https://mail.python.org/pipermail/python-dev/2014-March/133389.html .. [3] https://mail.python.org/pipermail/python-dev/2014-March/133438.html .. [4] https://mail.python.org/pipermail/python-dev/2014-March/133347.html Copyright ========= This document has been placed in the public domain. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

7 years, 4 months

Re: [Python-Dev] cpython (3.3): Make the various iterators' "setstate" sliently and consistently clip the

by Kristján Valur Jónsson

Hi there. I didn’t see the original email in python-dev, sorry about that. The “setstate” of the iterators is primarily used when unpickling them. This is code that was added during the PyCon sprints 2012, IIRC. Some iterators already did the silent clipping. One did not (rangeiter), it raised a valueerror, but it did so at the wrong index, so that an iterator could not be set to the “exhausted” state. Others did no checking, allowing the value to be set to an state that would cause undefined behavior. The change is to prevent the last case. It is there purely for paranoid reasons. There should be no reason why a iterator should be unpickled such that its range and position would be mismatching and no reason to bloat the code with diagnostic error code for that, but still, guarding us from undefined states is essential. If you think I should be adding exceptions for this, then I can do that. The reason this didn’t go through the tracker is that this is code from myself and the Stackless sprint that didn’t itself go through the tracker at the time. There really Is no one more qualified to verify this code than myself ☺ K From: Larry Hastings [mailto:larry@midwinter.com] On Behalf Of Larry Hastings Sent: 24. mars 2014 01:33 To: Kristján Valur Jónsson Subject: Fwd: Re: [Python-Dev] cpython (3.3): Make the various iterators' "setstate" sliently and consistently clip the Still no reply on this...? I'd like to see your answer too. /arry -------- Original Message -------- Subject: Re: [Python-Dev] cpython (3.3): Make the various iterators' "setstate" sliently and consistently clip the Date: Sat, 08 Mar 2014 08:01:23 +0100 From: Georg Brandl <g.brandl(a)gmx.net><mailto:g.brandl@gmx.net> To: python-dev(a)python.org<mailto:python-dev@python.org> Am 06.03.2014 09:02, schrieb Serhiy Storchaka: > 05.03.14 17:24, kristjan.jonsson написав(ла): >> http://hg.python.org/cpython/rev/3b2c28061184 >> changeset: 89477:3b2c28061184 >> branch: 3.3 >> parent: 89475:24d4e52f4f87 >> user: Kristján Valur Jónsson <sweskman(a)gmail.com><mailto:sweskman@gmail.com> >> date: Wed Mar 05 13:47:57 2014 +0000 >> summary: >> Make the various iterators' "setstate" sliently and consistently clip the >> index. This avoids the possibility of setting an iterator to an invalid >> state. > > Why indexes are silently clipped instead of raising an exception? > >> files: >> Lib/test/test_range.py | 12 ++++++++++ >> Modules/arraymodule.c | 2 + >> Objects/bytearrayobject.c | 10 ++++++-- >> Objects/bytesobject.c | 10 ++++++-- >> Objects/listobject.c | 2 + >> Objects/rangeobject.c | 31 +++++++++++++++++++++++--- >> Objects/tupleobject.c | 4 +- >> Objects/unicodeobject.c | 10 ++++++-- >> 8 files changed, 66 insertions(+), 15 deletions(-) > > And it would be better first discuss and review such large changes on > the bugtracker. Agreed. Kristjan, could you please explain a bit more about this change and use the tracker in the future? Georg _______________________________________________ Python-Dev mailing list Python-Dev(a)python.org<mailto:Python-Dev@python.org> https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/larry%40hastings.org

7 years, 4 months

python 3.4 and pywin32

by Thomas Heller

With python 3.4 and pywin32 version 218 it is only possible to import win32com or win32api when pywintypes has been imported before. I have no idea if this is a bug in pywin32 or in Python 3.4. Does anyone know more? Thanks, Thomas

7 years, 4 months

Re: [Python-Dev] cpython: #20145: assert[Raises|Warns]Regex now raise TypeError on bad regex.

by Antoine Pitrou

On Sun, 23 Mar 2014 20:47:28 +0100 (CET) r.david.murray <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/ec556e45641a > changeset: 89936:ec556e45641a > user: R David Murray <rdmurray(a)bitdance.com> > date: Sun Mar 23 15:08:43 2014 -0400 > summary: > #20145: assert[Raises|Warns]Regex now raise TypeError on bad regex. > > Previously a non-string, non-regex second argument could cause the test > to always pass. It seems like this would be useful to fix in 3.4 too. Regards Antoine.

7 years, 4 months

On porting to Python 3 as the answer

by Guido van Rossum

This really upset me: On Sun, Mar 23, 2014 at 3:17 AM, <martin(a)v.loewis.de> wrote: > I think asking developers to make significant modifications to their > code is besides the point of the PEP. However, if they are willing > to make changes, I'd still recommend that they port their code to > Python 3, as that is the better long-term investment. > This is a completely unrealistic form of wishful thinking, and repeating it won't make it more true. At Dropbox I work with a large group of very capable developers on several large code bases that are currently in 2.7. We are constantly changing our code to make it more secure (there are several teams specifically in charge of that). And yet porting to Python 3 is completely out of scope, for a variety of reasons. Please stop your wishful thinking. (TBH, I expect that none of the changes to Python 2.7 under consideration would make any difference for the security of Dropbox. But neither would switching to Python 3.) -- --Guido van Rossum (python.org/~guido)

7 years, 4 months

PEP 453 (Explicit bootstrapping of pip in Python installations) - slight typo

by Jurko Gospodnetić

Hi. Not really sure where to report this - missing closing parentheses in the PEP text at the end of the second paragraph in section 'Implementation strategy' http://legacy.python.org/dev/peps/pep-0453/#id35 > and would not try to contact PyPI (instead installing directly > from the private wheel files. Hope this helps. Best regards, Jurko Gospodnetić

7 years, 4 months

Intricacies of calling __eq__

by Maciej Fijalkowski

Hi I have a question about calling __eq__ in some cases. We're thinking about doing an optimization where say: if x in d: return d[x] where d is a dict would result in only one dict lookup (the second one being constant folded away). The question is whether it's ok to do it, despite the fact that it changes the semantics on how many times __eq__ is called on x. Cheers, fijal

7 years, 4 months

Summary of Python tracker Issues

by Python tracker

ACTIVITY SUMMARY (2014-03-14 - 2014-03-21) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 4511 (+25) closed 28273 (+60) total 32784 (+85) Open issues with patches: 2085 Issues opened (53) ================== #1350: IDLE - CallTips enhancement - show full doc-string in new wind http://bugs.python.org/issue1350 reopened by terry.reedy #19690: test_logging test_race failed with PermissionError http://bugs.python.org/issue19690 reopened by ned.deily #20574: Implement incremental decoder for cp65001 http://bugs.python.org/issue20574 reopened by haypo #20928: xml.etree.ElementInclude does not include nested xincludes http://bugs.python.org/issue20928 opened by James.Bailey #20932: Undefined behavior flagged by Clang 3.4 (Python 3.5 from hg) http://bugs.python.org/issue20932 opened by Jeffrey.Walton #20934: test_multiprocessing is broken by design http://bugs.python.org/issue20934 opened by schwab #20935: Support building Python with Clang sanitizer rules http://bugs.python.org/issue20935 opened by Jeffrey.Walton #20936: test_strftime: enormous allocation, fails under Clang sanitize http://bugs.python.org/issue20936 opened by Jeffrey.Walton #20937: test_socket: buffer overflow in sock_recvmsg_guts http://bugs.python.org/issue20937 opened by Jeffrey.Walton #20939: test_geturl of test_urllibnet fails with 'https://www.python.o http://bugs.python.org/issue20939 opened by ned.deily #20941: pytime.c:184 and pytime.c:218: runtime error, outside the rang http://bugs.python.org/issue20941 opened by Jeffrey.Walton #20942: _frozen_importlib should not have a __file__ attribute http://bugs.python.org/issue20942 opened by ncoghlan #20947: -Wstrict-overflow findings http://bugs.python.org/issue20947 opened by Jeffrey.Walton #20948: -Wformat=2 -Wformat-security findings http://bugs.python.org/issue20948 opened by Jeffrey.Walton #20949: Missing platform security integrations http://bugs.python.org/issue20949 opened by Jeffrey.Walton #20951: SSLSocket.send() returns 0 for non-blocking socket http://bugs.python.org/issue20951 opened by nikratio #20952: OpenSSL and RDRAND http://bugs.python.org/issue20952 opened by Jeffrey.Walton #20953: heap-buffer-overflow in obmalloc.c:987 http://bugs.python.org/issue20953 opened by Jeffrey.Walton #20954: Bug in subprocess._args_from_interpreter_flags causes MemoryEr http://bugs.python.org/issue20954 opened by schlamar #20956: tokenize module claims tokenize.tokenize returns namedtuple, b http://bugs.python.org/issue20956 opened by FunkyBob #20957: test_smptnet Fail instead of Skip if SSL-port is unavailable http://bugs.python.org/issue20957 opened by ebfe #20961: Fix usages of the note directive in the documentation http://bugs.python.org/issue20961 opened by berker.peksag #20962: Rather modest chunk size in gzip.GzipFile http://bugs.python.org/issue20962 opened by skip.montanaro #20964: Add support.check_time_delta() http://bugs.python.org/issue20964 opened by haypo #20968: mock.MagicMock does not mock __truediv__ http://bugs.python.org/issue20968 opened by Johannes.Baiter #20969: Author of EPUB version of Python docs is set to Unknown instea http://bugs.python.org/issue20969 opened by Christian.Clauss #20970: contradictory documentation for prog option of argparse http://bugs.python.org/issue20970 opened by Aaron.Meurer #20971: HTML output of difflib http://bugs.python.org/issue20971 opened by Jasvir.Singh #20973: Implement proper comparison operations for in _TotalOrderingMi http://bugs.python.org/issue20973 opened by OrangeTux #20974: email module docs say not compatible with current python versi http://bugs.python.org/issue20974 opened by Jim.Jewett #20975: Python 3.4 build info wrong in code snippet http://bugs.python.org/issue20975 opened by Zvezdoslovec #20977: pyflakes: undefined "ctype" in 2 except blocks in the email mo http://bugs.python.org/issue20977 opened by haypo #20979: Calling getdents()/readdir64() repeatedly while closing descri http://bugs.python.org/issue20979 opened by mmarkk #20980: In multiprocessing.pool, ExceptionWithTraceback should derive http://bugs.python.org/issue20980 opened by myint #20981: ssl doesn't build anymore with OpenSSL 0.9.7 or older: X509_ch http://bugs.python.org/issue20981 opened by haypo #20983: Python 3.4 'repair' Windows installation does not install pip http://bugs.python.org/issue20983 opened by Jurko.Gospodnetić #20984: 'Add/Remove Programs' dialog missing entries for 32-bit CPytho http://bugs.python.org/issue20984 opened by Jurko.Gospodnetić #20986: test_startup_imports fails in test_site when executed inside v http://bugs.python.org/issue20986 opened by finitemachine #20989: XML File I/O Misbehavior with open() when the flag is 'r+' http://bugs.python.org/issue20989 opened by rexperience7 #20990: pyflakes: undefined names, get_context() and main(), in multip http://bugs.python.org/issue20990 opened by haypo #20992: reading individual bytes of multiple binary files using the Py http://bugs.python.org/issue20992 opened by Tommy.Carstensen #20994: Disable TLS Compression http://bugs.python.org/issue20994 opened by dstufft #20995: Use Better Default Ciphers for the SSL Module http://bugs.python.org/issue20995 opened by dstufft #20996: Backport TLS 1.1 and 1.2 support for ssl_version http://bugs.python.org/issue20996 opened by dstufft #20997: Wrong URL fragment identifier in search result http://bugs.python.org/issue20997 opened by bmispelon #20998: fullmatch isn't matching correctly under re.IGNORECASE http://bugs.python.org/issue20998 opened by Lucretiel #20999: setlocale, getlocale succession --> ValueError or (None, None) http://bugs.python.org/issue20999 opened by albertjan #21000: json.tool ought to have a help flag http://bugs.python.org/issue21000 opened by benjamin.peterson #21002: _sre.SRE_Scanner object should have a fullmatch() method http://bugs.python.org/issue21002 opened by Gareth.Gouldstone #21006: asyncio.docs : create_subprocess_exec example does not work on http://bugs.python.org/issue21006 opened by ajaborsk #21009: Potential deadlock in concurrent futures when garbage collecti http://bugs.python.org/issue21009 opened by simon.jagoe #21011: PyArg_ParseTupleAndKeywords doesn't take const char *keywords[ http://bugs.python.org/issue21011 opened by h.venev #21012: Figure out how to best leverage pip in devinabox http://bugs.python.org/issue21012 opened by brett.cannon Most recent 15 issues with no replies (15) ========================================== #21012: Figure out how to best leverage pip in devinabox http://bugs.python.org/issue21012 #21011: PyArg_ParseTupleAndKeywords doesn't take const char *keywords[ http://bugs.python.org/issue21011 #21009: Potential deadlock in concurrent futures when garbage collecti http://bugs.python.org/issue21009 #20997: Wrong URL fragment identifier in search result http://bugs.python.org/issue20997 #20992: reading individual bytes of multiple binary files using the Py http://bugs.python.org/issue20992 #20977: pyflakes: undefined "ctype" in 2 except blocks in the email mo http://bugs.python.org/issue20977 #20969: Author of EPUB version of Python docs is set to Unknown instea http://bugs.python.org/issue20969 #20962: Rather modest chunk size in gzip.GzipFile http://bugs.python.org/issue20962 #20961: Fix usages of the note directive in the documentation http://bugs.python.org/issue20961 #20953: heap-buffer-overflow in obmalloc.c:987 http://bugs.python.org/issue20953 #20947: -Wstrict-overflow findings http://bugs.python.org/issue20947 #20942: _frozen_importlib should not have a __file__ attribute http://bugs.python.org/issue20942 #20936: test_strftime: enormous allocation, fails under Clang sanitize http://bugs.python.org/issue20936 #20912: [zipfile.py]: Make zip directory attributes more friendly for http://bugs.python.org/issue20912 #20911: urllib 'headers' is not a well defined data type http://bugs.python.org/issue20911 Most recent 15 issues waiting for review (15) ============================================= #21006: asyncio.docs : create_subprocess_exec example does not work on http://bugs.python.org/issue21006 #21000: json.tool ought to have a help flag http://bugs.python.org/issue21000 #20998: fullmatch isn't matching correctly under re.IGNORECASE http://bugs.python.org/issue20998 #20995: Use Better Default Ciphers for the SSL Module http://bugs.python.org/issue20995 #20994: Disable TLS Compression http://bugs.python.org/issue20994 #20980: In multiprocessing.pool, ExceptionWithTraceback should derive http://bugs.python.org/issue20980 #20974: email module docs say not compatible with current python versi http://bugs.python.org/issue20974 #20970: contradictory documentation for prog option of argparse http://bugs.python.org/issue20970 #20968: mock.MagicMock does not mock __truediv__ http://bugs.python.org/issue20968 #20964: Add support.check_time_delta() http://bugs.python.org/issue20964 #20961: Fix usages of the note directive in the documentation http://bugs.python.org/issue20961 #20957: test_smptnet Fail instead of Skip if SSL-port is unavailable http://bugs.python.org/issue20957 #20954: Bug in subprocess._args_from_interpreter_flags causes MemoryEr http://bugs.python.org/issue20954 #20951: SSLSocket.send() returns 0 for non-blocking socket http://bugs.python.org/issue20951 #20939: test_geturl of test_urllibnet fails with 'https://www.python.o http://bugs.python.org/issue20939 Top 10 most discussed issues (10) ================================= #20995: Use Better Default Ciphers for the SSL Module http://bugs.python.org/issue20995 42 msgs #20927: Different behaviour on Posix and Windows when using subprocess http://bugs.python.org/issue20927 15 msgs #20951: SSLSocket.send() returns 0 for non-blocking socket http://bugs.python.org/issue20951 12 msgs #17846: Building Python on Windows - Supplementary info http://bugs.python.org/issue17846 11 msgs #20906: Issues in Unicode HOWTO http://bugs.python.org/issue20906 10 msgs #20970: contradictory documentation for prog option of argparse http://bugs.python.org/issue20970 10 msgs #10141: SocketCan support http://bugs.python.org/issue10141 7 msgs #20062: Remove emacs page from devguide http://bugs.python.org/issue20062 7 msgs #20265: Bring Windows docs up to date http://bugs.python.org/issue20265 7 msgs #20935: Support building Python with Clang sanitizer rules http://bugs.python.org/issue20935 7 msgs Issues closed (60) ================== #11362: image/webp missing from mimetypes.py http://bugs.python.org/issue11362 closed by serhiy.storchaka #11448: docs for HTTPConnection.set_tunnel are ambiguous http://bugs.python.org/issue11448 closed by python-dev #13437: Provide links to the source code for every module in the docum http://bugs.python.org/issue13437 closed by akuchling #14332: Better explain "junk" concept in difflib doc http://bugs.python.org/issue14332 closed by akuchling #16245: Update html.entities.html5 dictionary and parseentities.py http://bugs.python.org/issue16245 closed by eric.araujo #16665: doc for builtin hex() is poor http://bugs.python.org/issue16665 closed by python-dev #18931: new selectors module should support devpoll on Solaris http://bugs.python.org/issue18931 closed by giampaolo.rodola #19009: Enhance HTTPResponse.readline() performance http://bugs.python.org/issue19009 closed by kristjan.jonsson #19165: Change formatter warning to DeprecationWarning in 3.5 http://bugs.python.org/issue19165 closed by brett.cannon #19255: Don't "wipe" builtins at shutdown http://bugs.python.org/issue19255 closed by serhiy.storchaka #19861: Update What's New for Python 3.4 http://bugs.python.org/issue19861 closed by r.david.murray #20379: help(instance_of_builtin_class.method) does not display self http://bugs.python.org/issue20379 closed by larry #20444: Reduce logging.config.Converting duplication of code http://bugs.python.org/issue20444 closed by python-dev #20558: ECONNRESET value in logging.config is valid with Linux [distro http://bugs.python.org/issue20558 closed by python-dev #20627: Add context manager support to xmlrpc.client.ServerProxy http://bugs.python.org/issue20627 closed by brett.cannon #20671: test_create_at_shutdown_with_encoding() of test_io hangs on "S http://bugs.python.org/issue20671 closed by haypo #20744: shutil should not use distutils http://bugs.python.org/issue20744 closed by akuchling #20879: base64 module of Python 3.4 uses 920 kB of memory http://bugs.python.org/issue20879 closed by haypo #20897: @abstractmethod does not enforce method signatures http://bugs.python.org/issue20897 closed by r.david.murray #20902: Which operand is preferred by set operations? Missing informat http://bugs.python.org/issue20902 closed by rhettinger #20909: 3.4 cherry pick: d22ef969cb82 & f5be4ea5b43e & 25dc02a2acae n http://bugs.python.org/issue20909 closed by larry #20920: Turtle module transparency. http://bugs.python.org/issue20920 closed by terry.reedy #20921: DeprecationWarning: The Windows bytes API has been deprecated, http://bugs.python.org/issue20921 closed by r.david.murray #20923: ConfigParser should nested [] in section names. http://bugs.python.org/issue20923 closed by terry.reedy #20926: Devguide: Enhance Quick Start portion of instructions for Wind http://bugs.python.org/issue20926 closed by pitrou #20929: Undefined behavior flagged by Clang 3.4 (Python 3.4-RC3) http://bugs.python.org/issue20929 closed by benjamin.peterson #20930: Debian 7.3: This platform's pyconfig.h needs to define PY_FORM http://bugs.python.org/issue20930 closed by benjamin.peterson #20931: Confusing section title "New Expected Features for Python Impl http://bugs.python.org/issue20931 closed by python-dev #20933: bad test case in test_osx_proxy_bypass (test.test_urllib2.Hand http://bugs.python.org/issue20933 closed by r.david.murray #20938: Broken link to editors page in General FAQ http://bugs.python.org/issue20938 closed by benjamin.peterson #20940: Test 239: buffer overflow in sock_recvmsg_guts http://bugs.python.org/issue20940 closed by neologix #20943: configparser - add 'getDict' function http://bugs.python.org/issue20943 closed by lukasz.langa #20944: Engineering Process Improvements http://bugs.python.org/issue20944 closed by r.david.murray #20945: why save the item to be replaced as olditem in PyTuple_SetItem http://bugs.python.org/issue20945 closed by benjamin.peterson #20946: ctypes test fixes http://bugs.python.org/issue20946 closed by python-dev #20950: asyncio.docs : asyncio.subprocess.Process.wait() method typo http://bugs.python.org/issue20950 closed by haypo #20955: Unexpected behavior in sqlite3.Connection.set_progress_handler http://bugs.python.org/issue20955 closed by berker.peksag #20958: Undefined behavior flagged by Clang 3.4 (Python 3.4.0) http://bugs.python.org/issue20958 closed by zach.ware #20959: print gives wrong error when printing *generator http://bugs.python.org/issue20959 closed by ned.deily #20960: Fix usage of the versionchanged directive in the sys.hash_info http://bugs.python.org/issue20960 closed by python-dev #20963: side_effects swapped in Mock example http://bugs.python.org/issue20963 closed by eric.araujo #20965: Clang devguide update http://bugs.python.org/issue20965 closed by python-dev #20966: Documentation Link for "Python Tkinter Resources" is currently http://bugs.python.org/issue20966 closed by python-dev #20967: hashlib memory leak http://bugs.python.org/issue20967 closed by brett.cannon #20972: python34.dll not in System32 or SysWOW64 folders after install http://bugs.python.org/issue20972 closed by mifik #20976: pyflakes: remove unused imports http://bugs.python.org/issue20976 closed by haypo #20978: pyflakes: undefined names http://bugs.python.org/issue20978 closed by haypo #20982: http://www.python.org used in unit test is directed to HTTPS u http://bugs.python.org/issue20982 closed by ned.deily #20985: Add new style formatting to logging.config.fileConfig http://bugs.python.org/issue20985 closed by vinay.sajip #20987: Python for AS/400 (OS/400) is actually 2.7 http://bugs.python.org/issue20987 closed by ned.deily #20988: Recommend ssl.create_default_context() in "Security considerat http://bugs.python.org/issue20988 closed by pitrou #20991: Issues about relative& absolute import way for Portingfrom pyt http://bugs.python.org/issue20991 closed by brett.cannon #20993: Quicklink to PEPs is wrong. http://bugs.python.org/issue20993 closed by zach.ware #21001: Python 3.4 MSI installer doesn't work http://bugs.python.org/issue21001 closed by zach.ware #21003: how to do batch processing using python http://bugs.python.org/issue21003 closed by eric.smith #21004: how to store json data into postgresql using python script http://bugs.python.org/issue21004 closed by eric.smith #21005: asyncio.docs : asyncio.subprocess.DEVNULL doc inadequate http://bugs.python.org/issue21005 closed by python-dev #21007: List of development releases in PEPs like 429 should be links http://bugs.python.org/issue21007 closed by benjamin.peterson #21008: Update devinabox for Python 3.4 http://bugs.python.org/issue21008 closed by brett.cannon #21010: asyncio doc typo http://bugs.python.org/issue21010 closed by python-dev

7 years, 4 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev March 2014