Mailman 3 October 2013 - Python-Dev

About 'superobject' and descriptors
by hakril lse 23 Oct '13

23 Oct '13

Hi, I have a question about a choice of implementation concerning 'superobject' with the descriptors. When a 'superobject' looks for a given attribute, it runs through the mro of the object. If it finds a descriptor, the 'superobject' calls the __get__ method with 'starttype = su->obj_type' as third argument (in typeobject.c: super_getattro). So, the 'type' argument of __get__ does not give more information about the 'real calling type' in this case. It seems that this is just a redundant information of inst.__class__. For example: # A.descr is a descriptor # B inherit from A # C inherit from B c = C() c.descr super(C, c).descr super(B, c).descr In these 3 cases the __get__ method is called with the same arguments that are : __get__(descr, c, C). If this behavior is really expected: Could you explain why ? because it means that I am missing something obvious. Because, at first sight, the 'type' argument seems to be the perfect place to get the type of the 'real calling class'. Thank you, -- hakril

3 2

Re: [Python-Dev] [Python-checkins] cpython: Switch subprocess stdin to a socketpair, attempting to fix issue #19293 (AIX
by Victor Stinner 23 Oct '13

23 Oct '13

Hi, Would it be possible to use os.pipe() on all OSes except AIX? Pipes and socket pairs may have minor differences, but some applications may rely on these minor differences. For example, is the buffer size the same? For example, in test.support, we have two constants: PIPE_MAX_SIZE (4 MB) and SOCK_MAX_SIZE (16 MB). Victor 2013/10/22 guido.van.rossum <python-checkins(a)python.org>: > http://hg.python.org/cpython/rev/2a0bda8d283d > changeset: 86557:2a0bda8d283d > user: Guido van Rossum <guido(a)dropbox.com> > date: Mon Oct 21 20:37:14 2013 -0700 > summary: > Switch subprocess stdin to a socketpair, attempting to fix issue #19293 (AIX hang). > > files: > Lib/asyncio/unix_events.py | 29 +++++++++- > Lib/test/test_asyncio/test_unix_events.py | 7 ++ > 2 files changed, 32 insertions(+), 4 deletions(-) > > > diff --git a/Lib/asyncio/unix_events.py b/Lib/asyncio/unix_events.py > --- a/Lib/asyncio/unix_events.py > +++ b/Lib/asyncio/unix_events.py > if stdin == subprocess.PIPE: > self._pipes[STDIN] = None > + # Use a socket pair for stdin, since not all platforms > + # support selecting read events on the write end of a > + # socket (which we use in order to detect closing of the > + # other end). Notably this is needed on AIX, and works > + # just fine on other platforms. > + stdin, stdin_w = self._loop._socketpair() > if stdout == subprocess.PIPE: > self._pipes[STDOUT] = None > if stderr == subprocess.PIPE:

3 4

Usefulness of site-python?
by Antoine Pitrou 23 Oct '13

23 Oct '13

Hello, I've just discovered there is a little-known feature in site.py: if a $PREFIX/lib/site-python exists (e.g. /usr/lib/site-python), it is added to sys.path in addition to the versioned site-packages. But only under Unix ("if os.sep == '/'"). Has anyone seen that feature in the real world? Debian doesn't use site-python, but its own /usr/share/pyshared. For the record, it was added in b53347c8260e with the following commit message: user: Guido van Rossum <guido(a)python.org> date: Wed Sep 03 21:41:30 1997 +0000 files: Lib/site.py description: Give in to Mike Meyer -- add *both* lib/python1.5/packages and lib/site-python to the path (if they exist). This is a reasonable compromise. Regards Antoine.

2 1

PyCon US 2014
by Eric Snow 22 Oct '13

22 Oct '13

Registration is now open for PyCon US 2014. Are there any plans yet for the language summit? Just the day (e.g. Thursday April 10) will suffice. Then we can make arrangements appropriately. Thanks. -eric

3 2

compile python 3.3 with bz2 support
by Isml 22 Oct '13

22 Oct '13

hi, everyone: I want to compile python 3.3 with bz2 support on RedHat 5.5 but fail to do that. Here is how I do it: 1、download bzip2 and compile it(make、make -f Makefile_libbz2_so、make install) 2、chang to python 3.3 source directory : ./configure --with-bz2=/usr/local/include 3、make 4、make install after installation complete, I test it： [root@localhost Python-3.3.0]# python3 -c "import bz2" Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/local/lib/python3.3/bz2.py", line 21, in <module> from _bz2 import BZ2Compressor, BZ2Decompressor ImportError: No module named '_bz2' By the way, RedHat 5.5 has a built-in python 2.4.3. Would it be a problem?

3 2

PEP 453 (ensurepip) updated
by Nick Coghlan 22 Oct '13

22 Oct '13

I have posted the latest version of PEP 453 to python.org. It is available in the usual place: http://www.python.org/dev/peps/pep-0453/ Three significant changes have been made since the last posted version: * removed the proposal to change the script installation directory on Windows, due to a backwards compatibility issue identified for Windows package installers created with earlier versions of Python (and vice-versa when attempting to use installers created with Python 3.4 on older versions) * noted the current certificate verification concerns for the requests project, and made resolution of that a requirement for inclusion of ensurepip in the final release of Python 3.4 * added an integration timeline, including a December 29th deadline for the inclusion of pip 1.5 (or a subsequent maintenance release) that includes a resolution of the certificate verification issues in requests Rather than posting the whole document again, I have just quoted the most relevant sections for these changes: <snip> Explicit bootstrapping mechanism ================================ <snip> Security considerations ----------------------- The design in this PEP has been deliberately chosen to avoid making any significant changes to the trust model of CPython for end users that do not subsequently run the command ``pip install --upgrade pip``. The installers will contain all the components of a fully functioning version of Python, including the ``pip`` installer. The installation process will *not* require network access, and will *not* rely on trusting the security of the network connection established between ``pip`` and the Python package index. Only users that choose to use ``pip`` to communicate with PyPI will need to pay attention to the additional security considerations that come with doing so. However, the core CPython team will still assist with reviewing and resolving at least the `certificate update management issue <https://github.com/kennethreitz/requests/issues/1659>`__ currently affecting the ``requests`` project (and hence ``pip``), and may also be able to offer assistance in resolving other identified security concerns [#cert-verification]_. <snip> Integration timeline -------------------- If this PEP is accepted, the proposed time frame for integration of ``pip`` into the CPython release is as follows: * as soon as possible after the release of 3.4.0 alpha 4 * Documentation updated and ``ensurepip`` implemented based on a pre-release version of ``pip`` 1.5. * All other proposed functional changes for Python 3.4 implemented, including the installer updates to invoke ``ensurepip``. * by November 20th (3 days prior to the scheduled date of 3.4.0 beta 1) * ``ensurepip`` updated to use a ``pip`` 1.5 release candidate. * PEP 101 updated to cover ensuring the bundled version of ``pip`` is up to date. * by November 24th (scheduled date of 3.4.0 beta 1) * As with any other new feature, all proposed functional changes for Python 3.4 must be implemented prior to the beta feature freeze. * by December 29th (1 week prior to the scheduled date of 3.4.0 beta 2) * ``requests`` certificate management issue resolved * ``ensurepip`` updated to the final release of ``pip`` 1.5, or a subsequent maintenance release (including a suitably updated vendored copy of ``requests``) (See PEP 429 for the current official scheduled dates of each release. Dates listed above are accurate as of October 20th, 2013.) If there is no final or maintenance release of ``pip`` 1.5 with a suitable updated version of ``requests`` available by one week before the scheduled Python 3.4 beta 2 release, then implementation of this PEP will be deferred to Python 3.5. Note that this scenario is considered unlikely - the tentative date for the ``pip`` 1.5 release is currently December 1st. In future CPython releases, this kind of coordinated scheduling shouldn't be needed: the CPython release manager will be able to just update to the latest released version of ``pip``. However, in this case, some fixes are needed in ``pip`` in order to allow the bundling to work correctly, and the certificate update mechanism for ``requests`` needs to be improved, so the ``pip`` 1.5 release cycle needs to be properly aligned with the CPython 3.4 beta releases. <snip> Appendix: Rejected Proposals ============================ Changing the name of the scripts directory on Windows ----------------------------------------------------- Earlier versions of this PEP proposed changing the name of the script installation directory on Windows from "Scripts" to "bin" in order to improve the cross-platform consistency of the virtual environments created by ``pyvenv``. However, Paul Moore determined that this change was likely backwards incompatible with cross-version Windows installers created with previous versions of Python, so the change has been removed from this PEP [#windows-incompatibility]_. <snip> -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

4 4

#19335 is a codeop, not Idle issue
by Terry Reedy 21 Oct '13

21 Oct '13

I know that many core devs subscribe to the new tracker issues list. If you skipped over http://bugs.python.org/issue19335 because it was (mis) titled as an Idle issue (as I presume most would), you might want to reconsider as it is actually a code and in particular, a codeop issue. Consider the real interpreter. C:\Programs\Python33>python Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> def a(): ... def b(): ... nonlocal c ... _ <blinkin> It waits to see if one enters a blank line (to which it properly responds SyntaxError), or continues with something that makes the statement syntactically valid. ... c = 1 ... >>> The 'close simulation' in the code module acts differently. C:\Programs\Python33>python -m code Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> def a(): ... def b(): ... nonlocal c File "<string>", line None SyntaxError: no binding for nonlocal 'c' found It prematurely acts as if one had entered a fourth, blank line. InteractiveConsole subclasses InteractiveInterpreter (as does Idle, hence the same behavior). II.runsource compiles with codeop.CommandCompile, which wraps codeop._maybe_compile, which returns None (src incomplete), raises (src complete and bad), or returns code (complete and ok) to be executed. For the above code, it re-raises SyntaxError instead of returning None. The issue needs someone who can find and read the C equivalent used by the real interpreter. Perhaps the latter was adjusted when nonlocal was introduced, while codeop was not. -- Terry Jan Reedy

1 0

Hashes on same site as download?
by Dan Stromberg 21 Oct '13

21 Oct '13

I may be missing something, but it seems the Python tarballs and hashes are on the same host, and this is not an entirely good thing for security. The way things are now, an attacker breaks into one host, doctors up a tarball, changes the hashes in the same host, and people download without noticing, even if they verify hashes. If you put the hashes on a different host from the tarballs, the attacker has to break into two machines. In this scenario, the hashes add more strength. ISTR I first learned of this issue from an article by Bruce Schneier, though I don't think it was in the context of Python.

3 3

Coding practice for context managers
by Raymond Hettinger 21 Oct '13

21 Oct '13

Two of the new context managers in contextlib are now wrapped in pass-through factory functions. The intent is to make the help() look cleaner. This practice does have downsides however. The usual way to detect whether something is usable with a with-statement is to check the presence of the __enter__ and __exit__ methods. Wrapping the CM in a pass-through function defeats this and other forms of introspection. Also, the help() output itself is worse-off. When you run help on a CM(), you're trying to find-out what happens on entry and what happens on exit. If those methods had docstrings, the question would be answered directly. The wrapper (intentionally) hides how it works. Since I teach intermediate and advanced python classes to experienced Python users, I've become more sensitive to problems this practice will create. Defeating introspection can make the help look nicer, but it isn't a clean coding practice and is something I hope doesn't catch on. To the extent there is a problem with the output of help(), I think efforts should be directed at making help() better. A lot of work needs to be done on that end -- for example abstract base classes also don't look great in help(). There are a couple of other minor issues as well. One is that the wrapper function hides the class, making it harder to do type checks such as "isinstance(x, suppress)". The other issue is that wrappers cause extra jumping around for people who are tracing code through a debugger or using a visualization tool such as pythontutor. These aren't terribly important issues, but it does support the notion that usually the cleanest code is the best code. In short, I recommend that efforts be directed at improving help() rather than limiting introspection by way of less clean coding practices. Raymond -------- current code for suppress() -------- class _SuppressExceptions: """Helper for suppress.""" def __init__(self, *exceptions): self._exceptions = exceptions def __enter__(self): pass def __exit__(self, exctype, excinst, exctb): return exctype is not None and issubclass(exctype, self._exceptions) # Use a wrapper function since we don't care about supporting inheritance # and a function gives much cleaner output in help() def suppress(*exceptions): """Context manager to suppress specified exceptions After the exception is suppressed, execution proceeds with the next statement following the with statement. with suppress(FileNotFoundError): os.remove(somefile) # Execution still resumes here if the file was already removed """ return _SuppressExceptions(*exceptions) -------- current help() output for suppress() -------- Help on function suppress in module contextlib: suppress(*exceptions) Context manager to suppress specified exceptions After the exception is suppressed, execution proceeds with the next statement following the with statement. with suppress(FileNotFoundError): os.remove(somefile) # Execution still resumes here if the file was already removed -------- current help() output for closing() with does not have a function wrapper -------- Help on class closing in module contextlib: class closing(builtins.object) | Context to automatically close something at the end of a block. | | Code like this: | | with closing(<module>.open(<arguments>)) as f: | <block> | | is equivalent to this: | | f = <module>.open(<arguments>) | try: | <block> | finally: | f.close() | | Methods defined here: | | __enter__(self) | | __exit__(self, *exc_info) | | __init__(self, thing) | | ---------------------------------------------------------------------- | Data descriptors defined here: | | __dict__ | dictionary for instance variables (if defined) | | __weakref__ | list of weak references to the object (if defined)

7 13

Python 2.6.9 final final due out 28 October 2013
by Barry Warsaw 21 Oct '13

21 Oct '13

This is a reminder that Python 2.6.9 final - and by that I mean *really* final as it will be the last supported version of Python 2.6 - is scheduled for release one week from today, on October 28, 2013. All known showstopper security bugs have been applied to the branch. If you know of anything that should go into Python 2.6 but has not yet, please contact me asap. Please test rc1 on your platforms and code, and let me know if you have any problems. Barring any showstoppers, I will likely cut the release AM my local time. Cheers, -Barry

1 0