Mailman 3 May 2012 - Python-Dev

docs.python.org pointing to Python 3 by default?
by Barry Warsaw May 22, 2012

May 22, 2012

At what point should we cut over docs.python.org to point to the Python 3 documentation by default? Wouldn't this be an easy bit to flip in order to promote Python 3 more better? Cheers, -Barry

22 42

Re: [Python-Dev] cpython (3.2): Issue12541 - Add UserWarning for unquoted realms
by Georg Brandl May 22, 2012

May 22, 2012

Am 15.05.2012 18:08, schrieb senthil.kumaran: > diff --git a/Lib/urllib/request.py b/Lib/urllib/request.py > --- a/Lib/urllib/request.py > +++ b/Lib/urllib/request.py > @@ -95,6 +95,7 @@ > import sys > import time > import collections > +import warnings > > from urllib.error import URLError, HTTPError, ContentTooShortError > from urllib.parse import ( > @@ -827,6 +828,9 @@ > mo = AbstractBasicAuthHandler.rx.search(authreq) > if mo: > scheme, quote, realm = mo.groups() > + if quote not in ["'", '"']: > + warnings.warn("Basic Auth Realm was unquoted", > + UserWarning, 2) > if scheme.lower() == 'basic': > response = self.retry_http_basic_auth(host, req, realm) > if response and response.code != 401: This looks suspect. Do we issue UserWarnings/any warnings anywhere else in the network-related libs when servers don't implement protocols correctly? I'm afraid of spurious warnings generated that will bug users unnecessarily. If the warning is left in, the message should probably include the offending realm string. Georg

1 0

Re: [Python-Dev] cpython: Close #14588: added a PEP 3115 compliant dynamic type creation mechanism
by Georg Brandl May 22, 2012

May 22, 2012

Am 19.05.2012 18:34, schrieb nick.coghlan: > diff --git a/Doc/library/types.rst b/Doc/library/types.rst > --- a/Doc/library/types.rst > +++ b/Doc/library/types.rst > @@ -1,5 +1,5 @@ > -:mod:`types` --- Names for built-in types > -========================================= > +:mod:`types` --- Dynamic type creation and names for built-in types > +=================================================================== > > .. module:: types > :synopsis: Names for built-in types. > @@ -8,20 +8,69 @@ > > -------------- > > -This module defines names for some object types that are used by the standard > +This module defines utility function to assist in dynamic creation of > +new types. > + > +It also defines names for some object types that are used by the standard > Python interpreter, but not exposed as builtins like :class:`int` or > -:class:`str` are. Also, it does not include some of the types that arise > -transparently during processing such as the ``listiterator`` type. > +:class:`str` are. > > -Typical use is for :func:`isinstance` or :func:`issubclass` checks. > > -The module defines the following names: > +Dynamic Type Creation > +--------------------- > + > +.. function:: new_class(name, bases=(), kwds=None, exec_body=None) > + > + Creates a class object dynamically using the appropriate metaclass. > + > + The arguments are the components that make up a class definition: the > + class name, the base classes (in order), the keyword arguments (such as > + ``metaclass``) and the callback function to populate the class namespace. > + > + The *exec_body* callback should accept the class namespace as its sole > + argument and update the namespace directly with the class contents. > + > +.. function:: prepare_class(name, bases=(), kwds=None) > + > + Calculates the appropriate metaclass and creates the class namespace. > + > + The arguments are the components that make up a class definition: the > + class name, the base classes (in order) and the keyword arguments (such as > + ``metaclass``). > + > + The return value is a 3-tuple: ``metaclass, namespace, kwds`` > + > + *metaclass* is the appropriate metaclass > + *namespace* is the prepared class namespace > + *kwds* is an updated copy of the passed in *kwds* argument with any > + ``'metaclass'`` entry removed. If no *kwds* argument is passed in, this > + will be an empty dict. > + > + > +.. seealso:: > + > + :pep:`3115` - Metaclasses in Python 3000 > + Introduced the ``__prepare__`` namespace hook > + > + Should have versionadded. Georg

1 0

Re: [Python-Dev] cpython (3.2): #14766: Add correct algorithm for when a 'time' object is naive.
by Georg Brandl May 22, 2012

May 22, 2012

Am 15.05.2012 04:33, schrieb r.david.murray: > diff --git a/Doc/library/datetime.rst b/Doc/library/datetime.rst > --- a/Doc/library/datetime.rst > +++ b/Doc/library/datetime.rst > @@ -15,16 +15,23 @@ > formatting and manipulation. For related > functionality, see also the :mod:`time` and :mod:`calendar` modules. > > -There are two kinds of date and time objects: "naive" and "aware". This > -distinction refers to whether the object has any notion of time zone, daylight > -saving time, or other kind of algorithmic or political time adjustment. Whether > -a naive :class:`.datetime` object represents Coordinated Universal Time (UTC), > +There are two kinds of date and time objects: "naive" and "aware". > + > +An aware object has sufficient knowledge of applicable algorithmic and > +political time adjustments, such as time zone and daylight saving time > +information, to locate itself relative to other aware objects. An aware object > +is used to represent a specific moment in time that is not open to > +interpretation [#]_. > @@ -1806,3 +1816,7 @@ > When the ``%z`` directive is provided to the :meth:`strptime` method, an > aware :class:`.datetime` object will be produced. The ``tzinfo`` of the > result will be set to a :class:`timezone` instance. > + > +.. rubric:: Footnotes > + > +.. [#] If, that is, we ignore the effects of Relativity I like that :) Georg

1 0

Re: [Python-Dev] cpython: Close #13585: add contextlib.ExitStack to replace the ill-fated
by Georg Brandl May 22, 2012

May 22, 2012

Am 21.05.2012 14:54, schrieb nick.coghlan: > http://hg.python.org/cpython/rev/8ef66c73b1e1 > changeset: 77095:8ef66c73b1e1 > user: Nick Coghlan <ncoghlan(a)gmail.com> > date: Mon May 21 22:54:43 2012 +1000 > summary: > Close #13585: add contextlib.ExitStack to replace the ill-fated contextlib.nested API > > files: > Doc/library/contextlib.rst | 279 +++++++++++++++++++++++- > Doc/whatsnew/3.3.rst | 15 + > Lib/contextlib.py | 126 ++++++++++- > Lib/test/test_contextlib.py | 123 ++++++++++ > Misc/NEWS | 2 + > 5 files changed, 539 insertions(+), 6 deletions(-) > > > diff --git a/Doc/library/contextlib.rst b/Doc/library/contextlib.rst > --- a/Doc/library/contextlib.rst > +++ b/Doc/library/contextlib.rst > @@ -12,8 +12,11 @@ > statement. For more information see also :ref:`typecontextmanager` and > :ref:`context-managers`. > > -Functions provided: > > +Utilities > +--------- > + > +Functions and classes provided: > > .. decorator:: contextmanager > > @@ -168,6 +171,280 @@ > .. versionadded:: 3.2 > > > +.. class:: ExitStack() > + > + A context manager that is designed to make it easy to programmatically > + combine other context managers and cleanup functions, especially those > + that are optional or otherwise driven by input data. > + > + For example, a set of files may easily be handled in a single with > + statement as follows:: > + > + with ExitStack() as stack: > + files = [stack.enter_context(open(fname)) for fname in filenames] > + # All opened files will automatically be closed at the end of > + # the with statement, even if attempts to open files later > + # in the list throw an exception > + > + Each instance maintains a stack of registered callbacks that are called in > + reverse order when the instance is closed (either explicitly or implicitly > + at the end of a ``with`` statement). Note that callbacks are *not* invoked > + implicitly when the context stack instance is garbage collected. > + > + This stack model is used so that context managers that acquire their > + resources in their ``__init__`` method (such as file objects) can be > + handled correctly. > + > + Since registered callbacks are invoked in the reverse order of > + registration, this ends up behaving as if multiple nested ``with`` > + statements had been used with the registered set of callbacks. This even > + extends to exception handling - if an inner callback suppresses or replaces > + an exception, then outer callbacks will be passed arguments based on that > + updated state. > + > + This is a relatively low level API that takes care of the details of > + correctly unwinding the stack of exit callbacks. It provides a suitable > + foundation for higher level context managers that manipulate the exit > + stack in application specific ways. > + > + .. method:: enter_context(cm) > + > + Enters a new context manager and adds its :meth:`__exit__` method to > + the callback stack. The return value is the result of the context > + manager's own :meth:`__enter__` method. > + > + These context managers may suppress exceptions just as they normally > + would if used directly as part of a ``with`` statement. > + > + .. method:: push(exit) > + > + Adds a context manager's :meth:`__exit__` method to the callback stack. > + > + As ``__enter__`` is *not* invoked, this method can be used to cover > + part of an :meth:`__enter__` implementation with a context manager's own > + :meth:`__exit__` method. > + > + If passed an object that is not a context manager, this method assumes > + it is a callback with the same signature as a context manager's > + :meth:`__exit__` method and adds it directly to the callback stack. > + > + By returning true values, these callbacks can suppress exceptions the > + same way context manager :meth:`__exit__` methods can. > + > + The passed in object is returned from the function, allowing this > + method to be used is a function decorator. > + > + .. method:: callback(callback, *args, **kwds) > + > + Accepts an arbitrary callback function and arguments and adds it to > + the callback stack. > + > + Unlike the other methods, callbacks added this way cannot suppress > + exceptions (as they are never passed the exception details). > + > + The passed in callback is returned from the function, allowing this > + method to be used is a function decorator. > + > + .. method:: pop_all() > + > + Transfers the callback stack to a fresh :class:`ExitStack` instance > + and returns it. No callbacks are invoked by this operation - instead, > + they will now be invoked when the new stack is closed (either > + explicitly or implicitly). > + > + For example, a group of files can be opened as an "all or nothing" > + operation as follows:: > + > + with ExitStack() as stack: > + files = [stack.enter_context(open(fname)) for fname in filenames] > + close_files = stack.pop_all().close > + # If opening any file fails, all previously opened files will be > + # closed automatically. If all files are opened successfully, > + # they will remain open even after the with statement ends. > + # close_files() can then be invoked explicitly to close them all > + > + .. method:: close() > + > + Immediately unwinds the callback stack, invoking callbacks in the > + reverse order of registration. For any context managers and exit > + callbacks registered, the arguments passed in will indicate that no > + exception occurred. > + > + .. versionadded:: 3.3 I'd prefer this versionadded a little more towards the top of the class documentation, e.g. before the first method. Otherwise it might get overlooked, or taken as belonging to the close() method (the indentation suggests otherwise, but that might not be enough cue for a quick read). Georg

1 0

ossaudiodev and linuxaudiodev not built on SLES11SP2 due to change in sys.platform
by Wempa, Kristofer May 22, 2012

May 22, 2012

I am currently working on porting our Linux tool chains to SuSe Enterprise Linux 11 service pack 2 (SLES11SP2). During this process, we noticed an issue due to a change in the sys.platform string. Previously, the string was "linux2" and it has now changed to "linux3". This seems to be due to a change in the kernel version. This causes the ossaudiodev and linuxaudiodev modules to be omitted from the build. I found the relevant code in setup.py: if platform == 'linux2': # Linux-specific modules exts.append( Extension('linuxaudiodev', ['linuxaudiodev.c']) ) else: missing.append('linuxaudiodev') if platform in ('linux2', 'freebsd4', 'freebsd5', 'freebsd6', 'freebsd7', 'freebsd8'): exts.append( Extension('ossaudiodev', ['ossaudiodev.c']) ) else: missing.append('ossaudiodev') Since neither of these account for "linux3", they are both omitted from the build. I can simply modify the code to include "linux3" so that these modules are built on the new platform. However, I wanted to check and see whether they are specifically being omitted for a reason or if the setup file just wasn't ported and tested against the new platform. Any help would be appreciated. Thanks. Kris ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 2

dir() in inspect.py ?
by Christian Tismer May 21, 2012

May 21, 2012

Hi, by chance I looked into the impl of inspect.getmembers today and was slightly shocked: def getmembers(object, predicate=None): """Return all members of an object as (name, value) pairs sorted by name. Optionally, only return members that satisfy a given predicate.""" results = [] for key in dir(object): According to http://docs.python.org/library/functions.html """ Note Because dir() is supplied primarily as a convenience for use at an interactive prompt, it tries to supply an interesting set of names more than it tries to supply a rigorously or consistently defined set of names, and its detailed behavior may change across releases. For example, metaclass attributes are not in the result list when the argument is a class. """ This is a bit inconsistent, and I think the standard lib should be the best example for clean code that is consistent with the docs. Is the usage of dir() correct in this context or is the doc right? It would be nice to add a sentence of clarification if the use of dir() is in fact the correct way to implement inspect. cheers - chris -- Christian Tismer :^)<mailto:tismer@stackless.com> tismerysoft GmbH : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de work +49 173 24 18 776 mobile +49 173 24 18 776 fax n.a. PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

4 4

Re: [Python-Dev] [Python-checkins] cpython: Describe the default hash correctly, and mark a couple of CPython
by Terry Reedy May 21, 2012

May 21, 2012

On 5/20/2012 4:31 AM, nick.coghlan wrote: > + and ``x.__hash__()`` returns an appropriate value such that ``x == y`` > + implies both that ``x is y`` and ``hash(x) == hash(y)``. I don't understand what you were trying to say with x == y implies x is y but I know you know that that is not true ;=0.

2 1

Backward compatibility of shutil.rmtree
by Hynek Schlawack May 21, 2012

May 21, 2012

Hi, as our shutil.rmtree() is vulnerable to symlink attacks (see <http://bugs.python.org/issue4489>) I’ve implemented a safe version using os.fwalk() and os.unlinkat() for Python 3.3. Now we face a problem I’d like a broad opinion on: rmtree has a callback hook called `onerror` that that gets called with amongst others the function that caused the error (see <http://docs.python.org/dev/library/shutil.html#shutil.rmtree>). Two of them differ in the new version: os.fwalk() is used instead of os.listdir() and os.unlinkat() instead of os.remove(). The safe version is used transparently if available, so this could potentially break code. Also it would mean that rmtree would behave differently on Linux & OS X for example. I’ve been thinking to "fake" the function names, as they map pretty good anyway. I.e. call onerror with os.listdir if os.fwalk failed and with os.remove instead of os.unlinkat. That could also make sense if some kind soul writes a safe rmtree for Windows or OS X so the function works the same across all platforms. It's a bit ugly though, a cleaner way would be to start using well defined symbols, but that would break code for sure. Opinions? Cheers, Hynek

3 4

PEP 3135 (new super()) __class__ references broken in 3.3
by Nick Coghlan May 21, 2012

May 21, 2012

PEP 3135 defines the new zero-argument form of super() as implicitly equivalent to super(__class__, <first argument>), and up until 3.2 has behaved accordingly: if you accessed __class__ from inside a method, you would receive a reference to the lexically containing class. In 3.3, that currently doesn't work: you get NameError instead (http://bugs.python.org/issue14857) While the 3.2 behaviour wasn't documented in the language reference, it's *definitely* documented in PEP 3135 (and my recent updates to the 3.3 version of the metaclass docs were written accordingly - that's how I discovered the problem) The error in the alpha releases appears to be a consequence of the attempt to fix a problem where the special treatment of __class__ meant that you couldn't properly set the __class__ attribute of the class itself in the class body (see http://bugs.python.org/issue12370). The fact that patch went in without causing a test failure means that this aspect of PEP 3135 has no explicit tests - it was only tested indirectly through the zero-argument super() construct. What I plan to do: 1. Revert the previous fix for #12370 2. Add tests for direct access to __class__ from methods 3. Create a *new* fix for #12370 that only affects the class scope, not the method bodies (this will be harder than the previous fix which affected the resolution of __class__ *everywhere* in the class body). Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

4 6