Mailman 3 May 2007 - Python-Dev

Module cleanup improvement
by Alan McIntyre May 23, 2007

May 23, 2007

Hi all, Bug #1717900 has an example of a script that causes a (cryptic, IMO) error during module cleanup since instances of a class just happen to get destroyed after their class is destroyed, and the __del__ method manipulates a class attribute. As I understand it this is expected under the behavior outlined here: http://www.python.org/doc/essays/cleanup/ Adding a step C1.5 which removes only objects that return true for PyInstance_Check seems to prevent the problem exhibited by this bug (I tried it out locally on the trunk and it doesn't cause any problems with the regression test suite). Is there any reason that adding such a step to module cleanup would be a bad idea? Alan

5 4

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser May 22, 2007

May 22, 2007

Patch / Bug Summary ___________________ Patches : 364 open ( +2) / 3769 closed ( +3) / 4133 total ( +5) Bugs : 986 open (+18) / 6701 closed ( +9) / 7687 total (+27) RFE : 258 open ( +2) / 287 closed ( +1) / 545 total ( +3) New / Reopened Patches ______________________ syslog syscall support for SysLogLogger (2007-05-02) http://python.org/sf/1711603 reopened by luke-jr Remove backslash escapes from tokanize.c. (2007-05-16) http://python.org/sf/1720390 opened by Ron Adam Allow T_BOOL in PyMemberDef definitions (2007-05-17) http://python.org/sf/1720595 opened by Angelo Mottola fix 1668596: copy datafiles properly when package_dir is ' ' (2007-05-17) http://python.org/sf/1720897 opened by Raghuram Devarakonda Build on QNX (2007-05-20) http://python.org/sf/1722225 opened by Matt Kraai Curses Menu (2007-05-21) http://python.org/sf/1723038 opened by Fabian Frederick Patches Closed ______________ Removal of Tuple Parameter Unpacking [PEP3113] (2007-03-10) http://python.org/sf/1678060 closed by bcannon Class Decorators (2007-02-28) http://python.org/sf/1671208 closed by jackdied Allow any mapping after ** in calls (2007-03-23) http://python.org/sf/1686487 closed by gbrandl New / Reopened Bugs ___________________ build_clib --build-clib/--build-temp option bugs (2007-05-14) http://python.org/sf/1718574 opened by Pearu Peterson glibc error: corrupted double linked list (CPython 2.5.1) (2007-05-14) http://python.org/sf/1718942 opened by Yang Zhang new functools (2007-05-15) http://python.org/sf/1719222 opened by Aaron Brady Python package support not properly documented (2007-05-15) http://python.org/sf/1719423 opened by Michael Abbott tarfile stops expanding with long filenames (2007-05-16) http://python.org/sf/1719898 opened by Christian Zagrodnick No docs for PyEval_EvalCode and related functions (2007-05-16) http://python.org/sf/1719933 opened by Joseph Eagar sets module documentation: example uses deprecated method (2007-05-16) CLOSED http://python.org/sf/1719995 opened by Jens Quade Compiler is not thread safe? (2007-05-16) http://python.org/sf/1720241 opened by ??PC?? PyGILState_Ensure does not acquires GIL (2007-05-16) http://python.org/sf/1720250 opened by Kuno Ospald Tkinter + thread + urllib => crashes? (2007-05-17) http://python.org/sf/1720705 opened by Hirokazu Yamamoto docu enhancement for logging.handlers.SysLogHandler (2007-05-17) http://python.org/sf/1720726 opened by rhunger Please make sqlite3.Row iterable (2007-05-17) CLOSED http://python.org/sf/1720959 opened by phil automatic imports (2007-05-17) http://python.org/sf/1720992 opened by Juan Manuel Borges Caño ERROR - Microsoft Visual C++ Runtime Library (2007-05-18) http://python.org/sf/1721161 reopened by dariounipd ERROR - Microsoft Visual C++ Runtime Library (2007-05-18) http://python.org/sf/1721161 opened by darioUniPD code that writes the PKG-INFO file doesnt handle unicode (2007-05-18) http://python.org/sf/1721241 opened by Matthias Klose make testall shows many glibc detected malloc corruptions (2007-05-18) http://python.org/sf/1721309 reopened by gbrandl make testall shows many glibc detected malloc corruptions (2007-05-18) http://python.org/sf/1721309 opened by David Favor test_bsddb3 malloc corruption (2007-05-18) CLOSED http://python.org/sf/1721313 opened by David Favor emphasize iteration volatility for dict (2007-05-18) CLOSED http://python.org/sf/1721368 opened by Alan emphasize iteration volatility for set (2007-05-18) CLOSED http://python.org/sf/1721372 opened by Alan Small case which hangs (2007-05-18) http://python.org/sf/1721518 opened by Julian Todd A subclass of set doesn't always have __init__ called. (2007-05-19) http://python.org/sf/1721812 opened by David Benbennick email.FeedParser.BufferedSubFile improperly handles "\r\n" (2007-05-19) http://python.org/sf/1721862 opened by Sye van der Veen IDLE hangs in popup method completion (2007-05-19) http://python.org/sf/1721890 opened by Andy Harrington NamedTuple security issue (2007-05-20) CLOSED http://python.org/sf/1722239 reopened by tiran NamedTuple security issue (2007-05-20) CLOSED http://python.org/sf/1722239 opened by Christian Heimes Thread shutdown exception in Thread.notify() (2007-05-20) http://python.org/sf/1722344 opened by Yang Zhang urlparse.urlunparse forms file urls incorrectly (2007-05-20) http://python.org/sf/1722348 opened by Thomas Folz-Donahue Option -OO doesn't remove docstrings (2007-05-21) http://python.org/sf/1722485 opened by Grzegorz Adam Hankiewicz x = [[]]*2; x[0].append doesn't work (2007-05-21) CLOSED http://python.org/sf/1722956 opened by Jeff Britton Crash in ctypes callproc function with unicode string arg (2007-05-22) http://python.org/sf/1723338 opened by Colin Laplace Bugs Closed ___________ sets module documentation: example uses deprecated method (2007-05-16) http://python.org/sf/1719995 closed by gbrandl Please make sqlite3.Row iterable (2007-05-17) http://python.org/sf/1720959 closed by ghaering make testall shows many glibc detected malloc corruptions (2007-05-18) http://python.org/sf/1721309 closed by nnorwitz test_bsddb3 malloc corruption (2007-05-18) http://python.org/sf/1721313 closed by gbrandl emphasize iteration volatility for dict (2007-05-18) http://python.org/sf/1721368 closed by rhettinger emphasize iteration volatility for set (2007-05-18) http://python.org/sf/1721372 closed by rhettinger __getslice__ changes integer arguments (2007-05-03) http://python.org/sf/1712236 closed by rhettinger Docstring for site.addpackage() is incorrect (2007-04-09) http://python.org/sf/1697215 closed by gbrandl yield+break stops tracing (2006-10-24) http://python.org/sf/1583862 closed by luks NamedTuple security issue (2007-05-20) http://python.org/sf/1722239 closed by rhettinger NamedTuple security issue (2007-05-20) http://python.org/sf/1722239 closed by rhettinger x = [[]]*2; x[0].append doesn't work (2007-05-21) http://python.org/sf/1722956 closed by gbrandl New / Reopened RFE __________________ Add File - Reload (2007-05-17) http://python.org/sf/1721083 opened by Raymond Hettinger RFE Closed __________ Cannot use dict with unicode keys as keyword arguments (2007-05-03) http://python.org/sf/1712419 closed by gbrandl

1 0

The docs, reloaded
by Jim Jewett May 22, 2007

May 22, 2007

Martin v. Löwis schrieb: > That docutils happens to be written in Python should make little > difference - it's *not* part of the Python language project, > and is just a tool for us, very much like latex and latex2html. Not entirely. When I first started looking at python, I read a lot of documentation. Now I don't read it so much; the time when I could easily suggest doc changes without explicitly setting time aside has passed. At that time, the barriers to submitting were fairly large; these are the ones I remember: (1) Not realizing that I *could* submit changes, and they would be welcome. (2) Not understanding it well enough to document it correctly. (3) Not having easy access to the source -- I didn't want to to retype it, or to edit html only to find out it was maintained in some other format. Even once I found the cvs repository, the docs weren't in the main area. (4) Not having an easy way to submit the changes quickly. (5) Wanting to check my work, in case I was wrong. I have no idea how to fix (1) and (2). Putting them on a wiki improves the situation with (3) and (4). (5) is at least helped by keeping the formatting requirements as simple as possible (not sure if ReST does this or not) and by letting me verify them before I submit. Getting docutils is already a barrier; I would like to see a stdlib module (not script hidden off to the side) for verification and conversion. I don't think I installed docutils myself until I started to write a PEP. But once I did download and install and figure out how to call it ... at least it generally worked, and ran with something (python) I was already using. Getting a 3rd party tool that ends up requiring fourth party tools (such as LaTex, but then I need to a viewer, or the old toolchain that required me to install Perl) ... took longer than my attention span. This was despite the fact that I had already used all the needed tools in previous years; they just weren't installed on the machines I had at the time ... and installing them on windows was something that would *probably* work *eventually*. If I had been new to programming, it would have been even more intimidating. -jJ

1 0

PEP 0365: Adding the pkg_resources module
by Phillip J. Eby May 21, 2007

May 21, 2007

I wanted to get this in before the Py3K PEP deadline, since this is a Python 2.6 PEP that would presumably impact 3.x as well. Feedback welcome. PEP: 365 Title: Adding the pkg_resources module Version: $Revision: 55032 $ Last-Modified: $Date: 2007-04-30 20:24:48 -0400 (Mon, 30 Apr 2007) $ Author: Phillip J. Eby <pje(a)telecommunity.com> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 30-Apr-2007 Post-History: 30-Apr-2007 Abstract ======== This PEP proposes adding an enhanced version of the ``pkg_resources`` module to the standard library. ``pkg_resources`` is a module used to find and manage Python package/version dependencies and access bundled files and resources, including those inside of zipped ``.egg`` files. Currently, ``pkg_resources`` is only available through installing the entire ``setuptools`` distribution, but it does not depend on any other part of setuptools; in effect, it comprises the entire runtime support library for Python Eggs, and is independently useful. In addition, with one feature addition, this module could support easy bootstrap installation of several Python package management tools, including ``setuptools``, ``workingenv``, and ``zc.buildout``. Proposal ======== Rather than proposing to include ``setuptools`` in the standard library, this PEP proposes only that ``pkg_resources`` be added to the standard library for Python 2.6 and 3.0. ``pkg_resources`` is considerably more stable than the rest of setuptools, with virtually no new features being added in the last 12 months. However, this PEP also proposes that a new feature be added to ``pkg_resources``, before being added to the stdlib. Specifically, it should be possible to do something like:: python -m pkg_resources SomePackage==1.2 to request downloading and installation of ``SomePackage`` from PyPI. This feature would *not* be a replacement for ``easy_install``; instead, it would rely on ``SomePackage`` having pure-Python ``.egg`` files listed for download via the PyPI XML-RPC API, and the eggs would be placed in the ``$PYTHONEGGS`` cache, where they would **not** be importable by default. (And no scripts would be installed) However, if the download egg contains installation bootstrap code, it will be given a chance to run. These restrictions would allow the code to be extremely simple, yet still powerful enough to support users downloading package management tools such as ``setuptools``, ``workingenv`` and ``zc.buildout``, simply by supplying the tool's name on the command line. Rationale ========= Many users have requested that ``setuptools`` be included in the standard library, to save users needing to go through the awkward process of bootstrapping it. However, most of the bootstrapping complexity comes from the fact that setuptools-installed code cannot use the ``pkg_resources`` runtime module unless setuptools is already installed. Thus, installing setuptools requires (in a sense) that setuptools already be installed. Other Python package management tools, such as ``workingenv`` and ``zc.buildout``, have similar bootstrapping issues, since they both make use of setuptools, but also want to provide users with something approaching a "one-step install". The complexity of creating bootstrap utilities for these and any other such tools that arise in future, is greatly reduced if ``pkg_resources`` is already present, and is also able to download pre-packaged eggs from PyPI. (It would also mean that setuptools would not need to be installed in order to simply *use* eggs, as opposed to building them.) Finally, in addition to providing access to eggs built via setuptools or other packaging tools, it should be noted that since Python 2.5, the distutils install package metadata (aka ``PKG-INFO``) files that can be read by ``pkg_resources`` to identify what distributions are already on ``sys.path``. In environments where Python packages are installed using system package tools (like RPM), the ``pkg_resources`` module provides an API for detecting what versions of what packages are installed, even if those packages were installed via the distutils instead of setuptools. Implementation and Documentation ================================ The ``pkg_resources`` implementation is maintained in the Python SVN repository under ``/sandbox/trunk/setuptools/``; see ``pkg_resources.py`` and ``pkg_resources.txt``. Documentation for the egg format(s) supported by ``pkg_resources`` can be found in ``doc/formats.txt``. HTML versions of these documents are available at: * http://peak.telecommunity.com/DevCenter/PkgResources and * http://peak.telecommunity.com/DevCenter/EggFormats (These HTML versions are for setuptools 0.6; they may not reflect all of the changes found in the Subversion trunk's ``.txt`` versions.) Copyright ========= This document has been placed in the public domain.

3 10

Re: [Python-Dev] [Python-3000] PEP 367: New Super
by Tim Delaney May 21, 2007

May 21, 2007

Tim Delaney wrote: > Phillip J. Eby wrote: >> At 05:23 PM 5/14/2007 +1000, Tim Delaney wrote: >>> Determining the class object to use >>> ''''''''''''''''''''''''''''''''''' >>> >>> The exact mechanism for associating the method with the defining >>> class is not >>> specified in this PEP, and should be chosen for maximum performance. >>> For CPython, it is suggested that the class instance be held in a >>> C-level variable >>> on the function object which is bound to one of ``NULL`` (not part >>> of a class), >>> ``Py_None`` (static method) or a class object (instance or class >>> method). >> >> Another open issue here: is the decorated class used, or the >> undecorated class? > > Sorry I've taken so long to get back to you about this - had email > problems. > I'm not sure what you're getting at here - are you referring to the > decorators for classes PEP? In that case, the decorator is applied > after the class is constructed, so it would be the undecorated class. > > Are class decorators going to update the MRO? I see nothing about > that in PEP 3129, so using the undecorated class would match the > current super(cls, self) behaviour. Duh - I'm an idiot. Of course, the current behaviour uses name lookup, so it would use the decorated class. So the question is, should the method store the class, or the name? Looking up by name could pick up a totally unrelated class, but storing the undecorated class could miss something important in the decoration. Tim Delaney

3 3

PEP 367: New Super
by Tim Delaney May 21, 2007

May 21, 2007

Here is my modified version of PEP 367. The reference implementation in it is pretty long, and should probably be split out to somewhere else (esp. since it can't fully implement the semantics). Cheers, Tim Delaney PEP: 367 Title: New Super Version: $Revision$ Last-Modified: $Date$ Author: Calvin Spealman <ironfroggy(a)gmail.com> Author: Tim Delaney <timothy.c.delaney(a)gmail.com> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 28-Apr-2007 Python-Version: 2.6 Post-History: 28-Apr-2007, 29-Apr-2007 (1), 29-Apr-2007 (2), 14-May-2007 Abstract ======== This PEP proposes syntactic sugar for use of the ``super`` type to automatically construct instances of the super type binding to the class that a method was defined in, and the instance (or class object for classmethods) that the method is currently acting upon. The premise of the new super usage suggested is as follows:: super.foo(1, 2) to replace the old:: super(Foo, self).foo(1, 2) and the current ``__builtin__.super`` be aliased to ``__builtin__.__super__`` (with ``__builtin__.super`` to be removed in Python 3.0). It is further proposed that assignment to ``super`` become a ``SyntaxError``, similar to the behaviour of ``None``. Rationale ========= The current usage of super requires an explicit passing of both the class and instance it must operate from, requiring a breaking of the DRY (Don't Repeat Yourself) rule. This hinders any change in class name, and is often considered a wart by many. Specification ============= Within the specification section, some special terminology will be used to distinguish similar and closely related concepts. "super type" will refer to the actual builtin type named "super". A "super instance" is simply an instance of the super type, which is associated with a class and possibly with an instance of that class. Because the new ``super`` semantics are not backwards compatible with Python 2.5, the new semantics will require a ``__future__`` import:: from __future__ import new_super The current ``__builtin__.super`` will be aliased to ``__builtin__.__super__``. This will occur regardless of whether the new ``super`` semantics are active. It is not possible to simply rename ``__builtin__.super``, as that would affect modules that do not use the new ``super`` semantics. In Python 3.0 it is proposed that the name ``__builtin__.super`` will be removed. Replacing the old usage of super, calls to the next class in the MRO (method resolution order) can be made without explicitly creating a ``super`` instance (although doing so will still be supported via ``__super__``). Every function will have an implicit local named ``super``. This name behaves identically to a normal local, including use by inner functions via a cell, with the following exceptions: 1. Assigning to the name ``super`` will raise a ``SyntaxError`` at compile time; 2. Calling a static method or normal function that accesses the name ``super`` will raise a ``TypeError`` at runtime. Every function that uses the name ``super``, or has an inner function that uses the name ``super``, will include a preamble that performs the equivalent of:: super = __builtin__.__super__(<class>, <instance>) where ``<class>`` is the class that the method was defined in, and ``<instance>`` is the first parameter of the method (normally ``self`` for instance methods, and ``cls`` for class methods). For static methods and normal functions, ``<class>`` will be ``None``, resulting in a ``TypeError`` being raised during the preamble. Note: The relationship between ``super`` and ``__super__`` is similar to that between ``import`` and ``__import__``. Much of this was discussed in the thread of the python-dev list, "Fixing super anyone?" [1]_. Open Issues ----------- Determining the class object to use ''''''''''''''''''''''''''''''''''' The exact mechanism for associating the method with the defining class is not specified in this PEP, and should be chosen for maximum performance. For CPython, it is suggested that the class instance be held in a C-level variable on the function object which is bound to one of ``NULL`` (not part of a class), ``Py_None`` (static method) or a class object (instance or class method). Should ``super`` actually become a keyword? ''''''''''''''''''''''''''''''''''''''''''' With this proposal, ``super`` would become a keyword to the same extent that ``None`` is a keyword. It is possible that further restricting the ``super`` name may simplify implementation, however some are against the actual keyword- ization of super. The simplest solution is often the correct solution and the simplest solution may well not be adding additional keywords to the language when they are not needed. Still, it may solve other open issues. Closed Issues ------------- super used with __call__ attributes ''''''''''''''''''''''''''''''''''' It was considered that it might be a problem that instantiating super instances the classic way, because calling it would lookup the __call__ attribute and thus try to perform an automatic super lookup to the next class in the MRO. However, this was found to be false, because calling an object only looks up the __call__ method directly on the object's type. The following example shows this in action. :: class A(object): def __call__(self): return '__call__' def __getattribute__(self, attr): if attr == '__call__': return lambda: '__getattribute__' a = A() assert a() == '__call__' assert a.__call__() == '__getattribute__' In any case, with the renaming of ``__builtin__.super`` to ``__builtin__.__super__`` this issue goes away entirely. Reference Implementation ======================== It is impossible to implement the above specification entirely in Python. This reference implementation has the following differences to the specification: 1. New ``super`` semantics are implemented using bytecode hacking. 2. Assignment to ``super`` is not a ``SyntaxError``. Also see point #4. 3. Classes must either use the metaclass ``autosuper_meta`` or inherit from the base class ``autosuper`` to acquire the new ``super`` semantics. 4. ``super`` is not an implicit local variable. In particular, for inner functions to be able to use the super instance, there must be an assignment of the form ``super = super`` in the method. The reference implementation assumes that it is being run on Python 2.5+. :: #!/usr/bin/env python # # autosuper.py from array import array import dis import new import types import __builtin__ __builtin__.__super__ = __builtin__.super del __builtin__.super # We need these for modifying bytecode from opcode import opmap, HAVE_ARGUMENT, EXTENDED_ARG LOAD_GLOBAL = opmap['LOAD_GLOBAL'] LOAD_NAME = opmap['LOAD_NAME'] LOAD_CONST = opmap['LOAD_CONST'] LOAD_FAST = opmap['LOAD_FAST'] LOAD_ATTR = opmap['LOAD_ATTR'] STORE_FAST = opmap['STORE_FAST'] LOAD_DEREF = opmap['LOAD_DEREF'] STORE_DEREF = opmap['STORE_DEREF'] CALL_FUNCTION = opmap['CALL_FUNCTION'] STORE_GLOBAL = opmap['STORE_GLOBAL'] DUP_TOP = opmap['DUP_TOP'] POP_TOP = opmap['POP_TOP'] NOP = opmap['NOP'] JUMP_FORWARD = opmap['JUMP_FORWARD'] ABSOLUTE_TARGET = dis.hasjabs def _oparg(code, opcode_pos): return code[opcode_pos+1] + (code[opcode_pos+2] << 8) def _bind_autosuper(func, cls): co = func.func_code name = func.func_name newcode = array('B', co.co_code) codelen = len(newcode) newconsts = list(co.co_consts) newvarnames = list(co.co_varnames) # Check if the global 'super' keyword is already present try: sn_pos = list(co.co_names).index('super') except ValueError: sn_pos = None # Check if the varname 'super' keyword is already present try: sv_pos = newvarnames.index('super') except ValueError: sv_pos = None # Check if the callvar 'super' keyword is already present try: sc_pos = list(co.co_cellvars).index('super') except ValueError: sc_pos = None # If 'super' isn't used anywhere in the function, we don't have anything to do if sn_pos is None and sv_pos is None and sc_pos is None: return func c_pos = None s_pos = None n_pos = None # Check if the 'cls_name' and 'super' objects are already in the constants for pos, o in enumerate(newconsts): if o is cls: c_pos = pos if o is __super__: s_pos = pos if o == name: n_pos = pos # Add in any missing objects to constants and varnames if c_pos is None: c_pos = len(newconsts) newconsts.append(cls) if n_pos is None: n_pos = len(newconsts) newconsts.append(name) if s_pos is None: s_pos = len(newconsts) newconsts.append(__super__) if sv_pos is None: sv_pos = len(newvarnames) newvarnames.append('super') # This goes at the start of the function. It is: # # super = __super__(cls, self) # # If 'super' is a cell variable, we store to both the # local and cell variables (i.e. STORE_FAST and STORE_DEREF). # preamble = [ LOAD_CONST, s_pos & 0xFF, s_pos >> 8, LOAD_CONST, c_pos & 0xFF, c_pos >> 8, LOAD_FAST, 0, 0, CALL_FUNCTION, 2, 0, ] if sc_pos is None: # 'super' is not a cell variable - we can just use the local variable preamble += [ STORE_FAST, sv_pos & 0xFF, sv_pos >> 8, ] else: # If 'super' is a cell variable, we need to handle LOAD_DEREF. preamble += [ DUP_TOP, STORE_FAST, sv_pos & 0xFF, sv_pos >> 8, STORE_DEREF, sc_pos & 0xFF, sc_pos >> 8, ] preamble = array('B', preamble) # Bytecode for loading the local 'super' variable. load_super = array('B', [ LOAD_FAST, sv_pos & 0xFF, sv_pos >> 8, ]) preamble_len = len(preamble) need_preamble = False i = 0 while i < codelen: opcode = newcode[i] need_load = False remove_store = False if opcode == EXTENDED_ARG: raise TypeError("Cannot use 'super' in function with EXTENDED_ARG opcode") # If the opcode is an absolute target it needs to be adjusted # to take into account the preamble. elif opcode in ABSOLUTE_TARGET: oparg = _oparg(newcode, i) + preamble_len newcode[i+1] = oparg & 0xFF newcode[i+2] = oparg >> 8 # If LOAD_GLOBAL(super) or LOAD_NAME(super) then we want to change it into # LOAD_FAST(super) elif (opcode == LOAD_GLOBAL or opcode == LOAD_NAME) and _oparg(newcode, i) == sn_pos: need_preamble = need_load = True # If LOAD_FAST(super) then we just need to add the preamble elif opcode == LOAD_FAST and _oparg(newcode, i) == sv_pos: need_preamble = need_load = True # If LOAD_DEREF(super) then we change it into LOAD_FAST(super) because # it's slightly faster. elif opcode == LOAD_DEREF and _oparg(newcode, i) == sc_pos: need_preamble = need_load = True if need_load: newcode[i:i+3] = load_super i += 1 if opcode >= HAVE_ARGUMENT: i += 2 # No changes needed - get out. if not need_preamble: return func # Our preamble will have 3 things on the stack co_stacksize = max(3, co.co_stacksize) # Conceptually, our preamble is on the `def` line. co_lnotab = array('B', co.co_lnotab) if co_lnotab: co_lnotab[0] += preamble_len co_lnotab = co_lnotab.tostring() # Our code consists of the preamble and the modified code. codestr = (preamble + newcode).tostring() codeobj = new.code(co.co_argcount, len(newvarnames), co_stacksize, co.co_flags, codestr, tuple(newconsts), co.co_names, tuple(newvarnames), co.co_filename, co.co_name, co.co_firstlineno, co_lnotab, co.co_freevars, co.co_cellvars) func.func_code = codeobj func.func_class = cls return func class autosuper_meta(type): def __init__(cls, name, bases, clsdict): UnboundMethodType = types.UnboundMethodType for v in vars(cls): o = getattr(cls, v) if isinstance(o, UnboundMethodType): _bind_autosuper(o.im_func, cls) class autosuper(object): __metaclass__ = autosuper_meta if __name__ == '__main__': class A(autosuper): def f(self): return 'A' class B(A): def f(self): return 'B' + super.f() class C(A): def f(self): def inner(): return 'C' + super.f() # Needed to put 'super' into a cell super = super return inner() class D(B, C): def f(self, arg=None): var = None return 'D' + super.f() assert D().f() == 'DBCA' Disassembly of B.f and C.f reveals the different preambles used when ``super`` is simply a local variable compared to when it is used by an inner function. :: >>> dis.dis(B.f) 214 0 LOAD_CONST 4 (<type 'super'>) 3 LOAD_CONST 2 (<class '__main__.B'>) 6 LOAD_FAST 0 (self) 9 CALL_FUNCTION 2 12 STORE_FAST 1 (super) 215 15 LOAD_CONST 1 ('B') 18 LOAD_FAST 1 (super) 21 LOAD_ATTR 1 (f) 24 CALL_FUNCTION 0 27 BINARY_ADD 28 RETURN_VALUE :: >>> dis.dis(C.f) 218 0 LOAD_CONST 4 (<type 'super'>) 3 LOAD_CONST 2 (<class '__main__.C'>) 6 LOAD_FAST 0 (self) 9 CALL_FUNCTION 2 12 DUP_TOP 13 STORE_FAST 1 (super) 16 STORE_DEREF 0 (super) 219 19 LOAD_CLOSURE 0 (super) 22 LOAD_CONST 1 (<code object inner at 00C160A0, file "autosuper.py", line 219>) 25 MAKE_CLOSURE 0 28 STORE_FAST 2 (inner) 223 31 LOAD_FAST 1 (super) 34 STORE_DEREF 0 (super) 224 37 LOAD_FAST 2 (inner) 40 CALL_FUNCTION 0 43 RETURN_VALUE Note that in the final implementation, the preamble would not be part of the bytecode of the method, but would occur immediately following unpacking of parameters. Alternative Proposals ===================== No Changes ---------- Although its always attractive to just keep things how they are, people have sought a change in the usage of super calling for some time, and for good reason, all mentioned previously. - Decoupling from the class name (which might not even be bound to the right class anymore!) - Simpler looking, cleaner super calls would be better Dynamic attribute on super type ------------------------------- The proposal adds a dynamic attribute lookup to the super type, which will automatically determine the proper class and instance parameters. Each super attribute lookup identifies these parameters and performs the super lookup on the instance, as the current super implementation does with the explicit invokation of a super instance upon a class and instance. This proposal relies on sys._getframe(), which is not appropriate for anything except a prototype implementation. super(__this_class__, self) --------------------------- This is nearly an anti-proposal, as it basically relies on the acceptance of the __this_class__ PEP, which proposes a special name that would always be bound to the class within which it is used. If that is accepted, __this_class__ could simply be used instead of the class' name explicitly, solving the name binding issues [2]_. self.__super__.foo(\*args) -------------------------- The __super__ attribute is mentioned in this PEP in several places, and could be a candidate for the complete solution, actually using it explicitly instead of any super usage directly. However, double-underscore names are usually an internal detail, and attempted to be kept out of everyday code. super(self, \*args) or __super__(self, \*args) ---------------------------------------------- This solution only solves the problem of the type indication, does not handle differently named super methods, and is explicit about the name of the instance. It is less flexable without being able to enacted on other method names, in cases where that is needed. One use case this fails is where a base- class has a factory classmethod and a subclass has two factory classmethods, both of which needing to properly make super calls to the one in the base- class. super.foo(self, \*args) ----------------------- This variation actually eliminates the problems with locating the proper instance, and if any of the alternatives were pushed into the spotlight, I would want it to be this one. super or super() ---------------- This proposal leaves no room for different names, signatures, or application to other classes, or instances. A way to allow some similar use alongside the normal proposal would be favorable, encouraging good design of multiple inheritence trees and compatible methods. super(\*p, \*\*kw) ------------------ There has been the proposal that directly calling ``super(*p, **kw)`` would be equivalent to calling the method on the ``super`` object with the same name as the method currently being executed i.e. the following two methods would be equivalent: :: def f(self, *p, **kw): super.f(*p, **kw) :: def f(self, *p, **kw): super(*p, **kw) There is strong sentiment for and against this, but implementation and style concerns are obvious. Guido has suggested that this should be excluded from this PEP on the principle of KISS (Keep It Simple Stupid). History ======= 29-Apr-2007 - Changed title from "Super As A Keyword" to "New Super" - Updated much of the language and added a terminology section for clarification in confusing places. - Added reference implementation and history sections. 06-May-2007 - Updated by Tim Delaney to reflect discussions on the python-3000 and python-dev mailing lists. References ========== .. [1] Fixing super anyone? (http://mail.python.org/pipermail/python-3000/2007-April/006667.html) .. [2] PEP 3130: Access to Module/Class/Function Currently Being Defined (this) (http://mail.python.org/pipermail/python-ideas/2007-April/000542.html) Copyright ========= This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End:

2 3

Summary of Tracker Issues
by Tracker May 20, 2007

May 20, 2007

ACTIVITY SUMMARY (05/06/07 - 05/13/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1650 open ( +0) / 8584 closed ( +0) / 10234 total ( +0) Average duration of open issues: 791 days. Median duration of open issues: 743 days. Open Issues Breakdown open 1650 ( +0) pending 0 ( +0)

23 57

Py2.6 buildouts to the set API
by Raymond Hettinger May 20, 2007

May 20, 2007

Here some ideas that have been proposed for sets: * New method (proposed by Shane Holloway): s1.isdisjoint(s2). Logically equivalent to "not s1.intersection(s2)" but has an early-out if a common member is found. The speed-up is potentially large given two big sets that may largely overlap or may not intersect at all. There is also a memory savings since a new set does not have to be formed and then thrown away. * Additional optional arguments for basic set operations to allow chained operations. For example, s=s1.union(s2, s3, s4) would be logically equivalent to s=s1.union(s2).union(s3).union(s4) but would run faster because no intermediate sets are created, copied, and discarded. It would run as if written: s=s1.copy(); s.update(s2); s.update(s3); s.update(s4). * Make sets listenable for changes (proposed by Jason Wells): s = set(mydata) def callback(s): print 'Set %d now has %d items' % (id(s), len(s)) s.listeners.append(callback) s.add(existing_element) # no callback s.add(new_element) # callback Raymond

7 8

Summary of Tracker Issues
by Tracker May 20, 2007

May 20, 2007

ACTIVITY SUMMARY (05/13/07 - 05/20/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1649 open ( +0) / 8584 closed ( +0) / 10233 total ( +0) Average duration of open issues: 799 days. Median duration of open issues: 750 days. Open Issues Breakdown open 1649 ( +0) pending 0 ( +0)

1 0

accepted peps that should be final?
by Neal Norwitz May 18, 2007

May 18, 2007

Are the following accepted PEPs implemented and should be marked final: SA 358 The "bytes" Object Schemenauer, GvR SA 3106 Revamping dict.keys(), .values() & .items() GvR SA 3109 Raising Exceptions in Python 3000 Winter SA 3110 Catching Exceptions in Python 3000 Winter SA 3111 Simple input built-in in Python 3000 Roberge SA 3112 Bytes literals in Python 3000 Orendorff n

3 5