Re: [Python-Dev] PEP 442 aftermath: module globals at shutdown

On Wed, 31 Jul 2013 13:30:58 +1200 Greg Ewing wrote: > Antoine Pitrou wrote: > > - it is held alive through builtins: the site module patches builtins > > with additional objects, which themselves keep references to the site > > module's globals, > > The module probably *should* stay alive in

Re: [Python-Dev] PEP 447: add type.__locallookup__

On 29 Jul, 2013, at 14:49, Ronald Oussoren wrote: > Hi, > > This PEP proposed to add a __locallookup__ slot to type objects, > which is used by _PyType_Lookup and super_getattro instead of peeking > in the tp_dict of classes. The PEP text explains why this is needed. > > Differences with the

[Python-Dev] to rename or not...

Hi, The relevant issue for this question is Plistlib contains object serialization logic that is in spirit simular to json and pickle, but has a different output format and different limitations. The functions in the module don't reflect that though, they are

Re: [Python-Dev] cpython (2.7): Issue #18441: Make test.support.requires('gui') skip when it should.

On Tue, 30 Jul 2013 20:52:27 -0400, Terry Reedy wrote: > On 7/30/2013 1:31 PM, R. David Murray wrote: > > On Sun, 28 Jul 2013 01:09:43 +0200, terry.reedy > > wrote: > > I believe that this logic is incorrect. > > It works for the intended purpose. > > > If regrtest is run with "-u gui", given

Re: [Python-Dev] PEP 442 aftermath: module globals at shutdown

Antoine Pitrou wrote: - it is held alive through builtins: the site module patches builtins with additional objects, which themselves keep references to the site module's globals, The module probably *should* stay alive in that case, since it's still accessible via those patched builtins.

Re: [Python-Dev] cpython (2.7): Issue #18441: Make test.support.requires('gui') skip when it should.

On 7/30/2013 1:31 PM, R. David Murray wrote: On Sun, 28 Jul 2013 01:09:43 +0200, terry.reedy wrote: Issue #18441: Make test.support.requires('gui') skip when it should. (Consolidating this check and various checks in tkinter files and moving them to test.support and test.regrtest will be a

Re: [Python-Dev] C code coverage report with lcov

Am 29.07.2013 21:48, schrieb Antoine Pitrou: > Ideally, we should run coverage runs on different systems (Unices, > Windows...) and merge the results together, so that we know which paths > are really uncovered. I don't that is easily possible. The coverage report depends on GCC and its gcov exten

Re: [Python-Dev] C code coverage report with lcov

Am 29.07.2013 19:15, schrieb Christian Heimes: > Hi, > > I have done some experiments with GCC's gcov and lcov to get the C code > coverage of our unit test suite. You may find today's report at > > http://tiran.bitbucket.org/python-lcov/ > > I'm working on a patch for our Makefile to include

Re: [Python-Dev] PEP 442 aftermath: module globals at shutdown

On Tue, 30 Jul 2013 12:58:58 -0700 Guido van Rossum wrote: > I'm very excited to see this happening! It's been a constant pain and > one of the things I've always regretted. Thanks Antoine! Note this is currently imperfect. I've identified two reasons why a pure Python module could stay alive eve

Re: [Python-Dev] PyPy3 2.1 beta 1 released

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/30/2013 04:39 PM, Philip Jenvey wrote: > PyPy3 2.1 beta 1 > > We're pleased to announce the first beta of the upcoming 2.1 release > of PyPy3. This is the first release of PyPy which targets Python 3 > (3.2.3) c

[Python-Dev] PyPy3 2.1 beta 1 released

PyPy3 2.1 beta 1 We're pleased to announce the first beta of the upcoming 2.1 release of PyPy3. This is the first release of PyPy which targets Python 3 (3.2.3) compatibility. We would like to thank all of the people who donated_ to the `py3k proposal`_ for suppo

Re: [Python-Dev] PEP 442 aftermath: module globals at shutdown

I'm very excited to see this happening! It's been a constant pain and one of the things I've always regretted. Thanks Antoine! --Guido On Tue, Jul 30, 2013 at 11:42 AM, Antoine Pitrou wrote: > > Hello, > > PEP 442 has now been committed in time for testing in Alpha 1. > > This paves the way for

Re: [Python-Dev] Adding Python scripts to PATHEXT on Windows

On 30 July 2013 18:24, "Martin v. Löwis" wrote: > > Personally, I don't know how to do this so someone else would have to - > > It seems that this was settled as fine as-is; if you ever wanted to > allow this to be specifically enabled, you'd have to do three things > Thanks, Martin - MSI is a m

[Python-Dev] PEP 442 aftermath: module globals at shutdown

Hello, PEP 442 has now been committed in time for testing in Alpha 1. This paves the way for the removal of another well-known annoyance: the behaviour of module globals at shutdown. Now that reference cycles aren't a barrier to object finalization anymore, we shouldn't need to set module global

Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #18441: Make test.support.requires('gui') skip when it should.

On Sun, 28 Jul 2013 01:09:43 +0200, terry.reedy wrote: > http://hg.python.org/cpython/rev/dd9941f5fcda > changeset: 84870:dd9941f5fcda > branch: 2.7 > parent: 84865:c0788ee86a65 > user:Terry Jan Reedy > date:Sun Jul 21 20:13:24 2013 -0400 > summary: > Issue #18441:

Re: [Python-Dev] Adding Python scripts to PATHEXT on Windows

Am 28.07.13 00:36, schrieb Paul Moore: > On 27 July 2013 21:14, Steve Dower > wrote: > > Any chance of this being made optional when installing? It provides > no benefit for people who prefer to associate scripts with an editor > and may be a source o

Re: [Python-Dev] MyOpenID.com no longer supported

Am 29.07.13 18:56, schrieb R. David Murray: > Either Martin needs to clue me in, or I'll have to find time to read > his openid code :) If you want to read the code, this issue can be discovered from schema.py. The openids are stored per user in a single field; multiple openids are simply space-se

Re: [Python-Dev] PEP 446: Open issues/questions

On 30/07/2013 11:52am, Victor Stinner wrote: > You can redirect standard streams (stdin, stdout, stderr) using the > startup info structure: > > startupinfo.dwFlags |= _winapi.STARTF_USESTDHANDLES > startupinfo.hStdInput = p2cread > startupinfo.hStdOutput = c2pwrite > startupinfo.hStdError = errwr

Re: [Python-Dev] PEP 446: Open issues/questions

2013/7/30 Richard Oudkerk : > Note that on Windows subprocess has no equivalent of a passfds argument, and > if you redirect the standard streams then you are forced to inherit all > inheritable handles. You can redirect standard streams (stdin, stdout, stderr) using the startup info structure: s

Re: [Python-Dev] PEP 446: Open issues/questions

On 30/07/2013 8:09am, Charles-François Natali wrote: If we don't want to inherit file descriptors in child processes, the answer is simple: the subprocess module (this fact is not even mentioned in the PEP). Note that on Windows subprocess has no equivalent of a passfds argument, and if you re

Re: [Python-Dev] PEP 446: Open issues/questions

Le 30 juil. 2013 09:11, "Charles-François Natali" a écrit : > > Perhaps this advocates for a global flag, e.g. > > sys.set_default_fd_inheritance(), with False (non-inheritable) being > > the default for sanity and security. > > This looks more and more like PEP 433 :-) I don't like the global mo

Re: [Python-Dev] PEP 446: Open issues/questions

Le Tue, 30 Jul 2013 09:09:38 +0200, Charles-François Natali a écrit : > > > > Perhaps this advocates for a global flag, e.g. > > sys.set_default_fd_inheritance(), with False (non-inheritable) being > > the default for sanity and security. > > This looks more and more like PEP 433 :-) > > And hon

Re: [Python-Dev] PEP 446: Open issues/questions

2013/7/28 Charles-François Natali : > Also, it'll be puzzling to have syscalls automatically set the cloexec > flag. I guess a lot of people doing system programming with Python > will get bitten, but that's a discussion we already had months ago... The inheritance of file descriptors (and Windows

Re: [Python-Dev] PEP 446: Open issues/questions

>> Having stdin/stdout/stderr cloexec (e.g. after a dup() to redirect to >> a log file, a socket...) will likely break a lot of code, e.g. code >> using os.system(), or code calling exec manually (and I'm sure there's >> a bunch of it). > > Hmm. os.exec*() could easily make standard streams non-CLO