On 08/28/2013 01:20 AM, victor.stinner wrote:
> changeset: 85420:ef889c3d5dc6
> user: Victor Stinner <victor.stinner(a)gmail.com>
> date: Wed Aug 28 00:53:59 2013 +0200
> Issue #18571: Implementation of the PEP 446: file descriptors and file handles
> are now created non-inheritable; add functions os.get/set_inheritable(),
> os.get/set_handle_inheritable() and socket.socket.get/set_inheritable().
> +.. _fd_inheritance:
> +Inheritance of File Descriptors
> +A file descriptor has a inheritable flag which indicates if the file descriptor
> +can be inherited or not in child processes. Since Python 3.4, file descriptors
> +created by Python are non-inheritable by default.
> +On UNIX, non-inheritable file descriptors are closed in child processes at the
> +execution of a new program, other file descriptors are inherited.
> +On Windows, non-inheritable handles and file descriptors are closed in child
> +processes, except standard streams (file descriptors 0, 1 and 2: stdin, stdout
> +and stderr) which are always inherited. Using :func:`os.spawn*` functions,
> +all inheritable handles and all inheritable file descriptors are inherited.
> +Using the :mod:`subprocess` module, all file descriptors except standard
> +streams are closed, inheritable handles are only inherited if the *close_fds*
> +parameter is ``False``.
> +.. versionadded:: 3.4
> +.. function:: get_inheritable(fd)
> + Get the `inheritable flag <fd_inheritance>`_ of the specified file
> + descriptor. Return a :class:`bool`.
> +.. function:: set_inheritable(fd, inheritable)
> + Set the `inheritable flag <fd_inheritance>`_ of the specified file descriptor.
> +.. function:: get_handle_inheritable(handle)
> + Get the `inheritable flag <fd_inheritance>`_ of the specified handle. Return a :class:`bool`.
> + Availability: Windows.
> +.. function:: set_handle_inheritable(handle, inheritable)
> + Set the `inheritable flag <fd_inheritance>`_ of the specified handle.
> + Availability: Windows.
"Handle" is used nowhere else in the os module documentation. Do you think it
would make sense to have a brief paragraph on what are possible handles under
Windows (and that file descriptors aren't handles)?
On 9/14/2013 1:45 PM, antoine.pitrou wrote:
> changeset: 85701:4f5815747f58
> user: Antoine Pitrou <solipsis(a)pitrou.net>
> date: Sat Sep 14 19:45:47 2013 +0200
> Issue #18937: Add an assertLogs() context manager to unittest.TestCase to ensure that a block of code emits a message using the logging module.
> Doc/library/unittest.rst | 41 +++++++
> Lib/unittest/case.py | 109 +++++++++++++++++++-
> Lib/unittest/test/test_case.py | 96 ++++++++++++++++++
> Misc/NEWS | 2 +
> 4 files changed, 242 insertions(+), 6 deletions(-)
> diff --git a/Doc/library/unittest.rst b/Doc/library/unittest.rst
> --- a/Doc/library/unittest.rst
> +++ b/Doc/library/unittest.rst
> @@ -1031,6 +1031,47 @@
> .. versionchanged:: 3.3
> Added the *msg* keyword argument when used as a context manager.
> + .. method:: assertLogs(logger=None, level=None)
> + A context manager to test that at least one message is logged on
> + the *logger* or one of its children, with at least the given
> + *level*.
> + If given, *logger* should be a :class:`logging.Logger` object or a
> + :class:`str` giving the name of a logger. The default is the root
> + logger, which will catch all messages.
> + If given, *level* should be either a numeric logging level or
> + its string equivalent (for example either ``"ERROR"`` or
> + :attr:`logging.ERROR`). The default is :attr:`logging.INFO`.
> + The test passes if at least one message emitted inside the ``with``
> + block matches the *logger* and *level* conditions, otherwise it fails.
> + The object returned by the context manager is a recording helper
> + which keeps tracks of the matching log messages. It has two
> + attributes:
> + .. attribute:: records
> + A list of :class:`logging.LogRecord` objects of the matching
> + log messages.
> + .. attribute:: output
> + A list of :class:`str` objects with the formatted output of
> + matching messages.
> + Example::
> + with self.assertLogs('foo', level='INFO') as cm:
> + logging.getLogger('foo').info('first message')
> + logging.getLogger('foo.bar').error('second message')
> + self.assertEqual(cm.output, ['INFO:foo:first message',
> + 'ERROR:foo.bar:second message'])
> + .. versionadded:: 3.4
> There are also other methods used to perform more specific checks, such as:
The new method should be added to the table of raises/warns methods that
starts this group. The table intro sentence
"It is also possible to check that exceptions and warnings are raised
using the following methods:"
should be modified to something like
"It is also possible to check the production of exception, warning, and
log messages using the following methods:"
In http://bugs.python.org/issue18986 I proposed adding a new mapping
type to the collections module.
The original use case is quite common in network programming and
elsewhere (Eric Snow on the tracker mentioned an application with stock
symbols). You want to have an associative container which matches keys
case-insensitively but also preserves the original casing (e.g. for
presentation). It is a commonly reimplemented container.
It is also an instance of a more general pattern: match keys after
applying a derivation (or coercion) function, but at the same time keep
track of the original key. Note that the derivation function needn't be
(and generally won't be) bijective, otherwise it's too simple.
Therefore I propose adding the general pattern. Simple example:
>>> d = transformdict(str.lower)
>>> d['Foo'] = 5
(case-insensitive but case-preserving, as the best filesystems are ;-))
On the tracker issue, it seems everyone agreed on the principle. There
is some bikeshedding left to do, though. So here are the reasonable
naming proposals so far:
I have a sweet spot for "transformdict" myself.
In issues 7238 , 16482 , 17697  and 17277 , the line
number may be incorrect when the global trace function has been
removed but not the frame f_trace function.
A simple test (see below) in issue 17288  crashes the interpreter
when setting f_lineno in a generator from a return trace function.
All those issues are few months old. There is a patch at issue 17277
 that fixes the first 4 issues. There is also a patch for issue
###### Setting f_lineno in a generator ######
$ cat jump.py
for i in range(1):
lineno = 4
for i in gen():
$ python -m pdb jump.py
-> def gen():
(Pdb) import sys; print(sys.version)
3.4.0a1+ (default:975d1e180689, Sep 6 2013, 09:26:12)
(Pdb) break 3
Breakpoint 1 at /tmp/jump.py:3
-> yield i
-> yield i
(Pdb) jump 2
-> for i in range(1):
I work on enhancement of audio modules testing , and I need free (in
both senses) small sample audio files in different formats. We already
have audiotest.au (mono, and sunau has a bug in processing multichannel
files ) and Sine-1000Hz-300ms.aif, but this is not enough. I have
generated a pack of files like Sine-1000Hz-300ms.aif by Python, it is
enough for regression testing but only if current implementation is correct.
I found some collections of sample files at , but I'm not sure about
copyright, and perhaps they are a little too big.
In ideal it should be one high-quality (float64?) multichannel (5+1?)
but short master file and it's lower-quality copies made by third-party
tools. In ideal the content should be related to Python.
> Note: Because dir() is supplied primarily as a convenience for
> use at an interactive prompt [...]
I suspect this comment is out of date, as there are two functions in the inspect module that rely on dir(), which also
means that help indirectly relies on dir(). And we also now have the __dir__ method that we can use to customize what
> [...] more than it tries to supply a rigorously or consistently
> defined set of names, [...]
If this is still true, should inspect be relying on dir()?
I wondering why there is no standard IOCP module in Python ?
As I know: Python3 have support epoll in linux and kqueue in freebsd.
Is there a plan to add IOCP module for Windows ?
-----BEGIN PGP SIGNED MESSAGE-----
I just received an email from my OpenID provider, "myOpenID", saying
that they drop OpenID service next February. I wonder what other
OpenID providers are used by other python-dev fellows.
What are you using?. bugs.python.org admins could share some data?
I agree than OpenID is (quite) dead, but I rather prefer OpenID to use
user/pass. I have big hopes for Mozilla Persona, looking forward
Python infrastructure support :).
PS: I use "http://www.jcea.es/" as my OpenID identity, and I delegate
the actual service to "myOpenID". I can switch delegation trivially.
Jesús Cea Avión _/_/ _/_/_/ _/_/_/
jcea(a)jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/
Twitter: @jcea _/_/ _/_/ _/_/_/_/_/
jabber / xmpp:firstname.lastname@example.org _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
On behalf of the Python development team, I'm chuffed to announce the
second alpha release of Python 3.4.
This is a preview release, and its use is not recommended for
Python 3.4 includes a range of improvements of the 3.x series, including
hundreds of small improvements and bug fixes. Major new features and
changes in the 3.4 release series so far include:
* PEP 435, a standardized "enum" module
* PEP 442, improved semantics for object finalization
* PEP 443, adding single-dispatch generic functions to the standard library
* PEP 445, a new C API for implementing custom memory allocators
* PEP 446, changing file descriptors to not be inherited by default
* PEP 447, a new magic method for metaclasses (``__typelookup__``)
* PEP 448, making automatic sequence unpacking more general
To download Python 3.4.0a2 visit:
Please consider trying Python 3.4.0a2 with your code and reporting any
issues you notice to:
Larry Hastings, Release Manager
larry at hastings.org
(on behalf of the entire python-dev team and 3.4's contributors)