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

2013-07-30 Thread Charles-François Natali 
>> 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-CLOEXEC before
> calling the underlying C library function. Things are more annoying for
> os.system(), though.
>
>> 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...
>
> 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 honestly, when I think about it, I think that this whole mess is a
solution looking for a problem.
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).
If a user wants to use the execve() syscall directly, then he should
be aware of the implications. I don't think that patching half the
stdlib and complicating the API of many functions is the right way to
do this.

The stdlib should be updated to replace the handful of places where
exec() is called explicitly by subprocess (the only one I can think on
top of my head is http.server.CGIHTTPRequestHandler (issue #16945)),
otherwise that's about it.

cf



>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/cf.natali%40gmail.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-07-30 Thread Victor Stinner 
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 handles) is discussed
since january 2013. Thanks to all exchanges on python-dev, we now know well
the perimeter of such changes. Each option has been discussed, and
advantages and drawbacks of each option were listed.

Going against the POSIX standard (clear inheritable flag when creating a
fd) is a drawback, but it's less important than issues fixed by such change
(don't "leak" fd or handle to child processes which fixes many other
issues).

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-07-30 Thread Antoine Pitrou 
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 honestly, when I think about it, I think that this whole mess is a
> solution looking for a problem.
> 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).

This is a good point. Are there any reasons (other than fd inheritance)
not to use subprocess? If there are, perhaps we should try to eliminate
them by improving subprocess.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-07-30 Thread Victor Stinner 
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 modifiable default, for the reasons Charles
Francois gave some months ago.

I did have time yet to rewrite the PEP 446, I'm writing first its
implementation. Basically, the new PEP 446 is:

- functions creating file descriptors and Windows handle now clear the
inheritable flag (disable inheritance by default)
- add new functions os.get/set_inheritable()
- subprocess makes fds of pass_fds inheritable
- (maybe) os.dup2(fd, fd2) makes fd2 inheritable for fd 0, 1, 2

That's all! No more new cloexec parameter to +15 functions and classes, no
more global variable (default inheritavle values).

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-07-30 Thread Richard Oudkerk 

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 redirect the standard streams then you are forced to inherit 
all inheritable handles.


--
Richard

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-07-30 Thread Victor Stinner 
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:

startupinfo.dwFlags |= _winapi.STARTF_USESTDHANDLES
startupinfo.hStdInput = p2cread
startupinfo.hStdOutput = c2pwrite
startupinfo.hStdError = errwrite

But I don't know how to add another streams (ex: pipe). I would be
nice to have a "pass_handles" on Windows.

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-07-30 Thread Richard Oudkerk 

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 = errwrite

The documentation for STARTUPINFO says this about STARTF_USESTDHANDLES:

  If this flag is specified when calling one of the process creation
  functions, the handles must be inheritable and the function's
  bInheritHandles parameter must be set to TRUE.

So, as I said, if you redirect the streams then you inherit all 
inheritable handles.


--
Richard

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-07-30 Thread Martin v. Löwis 
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-separated.

To find all myopenid users, do

select id,_username,_address,_openids from _user where _openids like
'%myopenid.com/%';

You could filter out those with multiple openids (and not _openids
like '% %').

I'd appreciate if you could contact them; if anybody loses access and
registered a working email address, the password reset procedure
should still work for them.

FWIW, 204 out of 13581 users only have a myopenid registered;
how many of these also have a working password, I cannot tell.
49 more have a second OpenID registered (which atleast must
have worked when they registered it - but it could be an alias
for the myopenid one).

Regards,
Martin

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-07-30 Thread Martin v. Löwis 
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 of confusion/complaints.
> 
> 
> 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

1. create a new "feature" in the feature tree. Your patch currently
   uses the "Extensions" feature (child of the default feature);
   you could make your feature a subfeature of Extensions.
2. create a new "component". This should work similar to REGISTRY.path.
3. Add a "FeatureComponents" entry saying that the "REGISTRY.pathext"
   component (say) belongs to the "PathExt" feature (say).

Instead of hooking the environment variable to the REGISTRY.def
component, it should then go to the REGISTRY.pathext component.

The nice thing about this feature tree is that it allows convenient
user configuration yet powerful scripted installation, see

http://msdn.microsoft.com/en-us/library/windows/desktop/aa368585(v=vs.85).aspx

For example, you could set the msidbFeatureAttributesFollowParent
flag, which would make it be selected/unselected if the parent
feature is, yet still allow it to be independent of the parent
for people who really want to.

Regards,
Martin

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-07-30 Thread R. David Murray 
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: 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 another issue.)
> 
> files:
>   Lib/idlelib/idle_test/test_text.py |   5 +---
>   Lib/test/test_idle.py  |  20 ++---
>   2 files changed, 17 insertions(+), 8 deletions(-)
> 
> 
> diff --git a/Lib/idlelib/idle_test/test_text.py 
> b/Lib/idlelib/idle_test/test_text.py
> --- a/Lib/idlelib/idle_test/test_text.py
> +++ b/Lib/idlelib/idle_test/test_text.py
> @@ -216,10 +216,7 @@
>  requires('gui')
>  from Tkinter import Tk, Text
>  cls.Text = Text
> -try:
> -cls.root = Tk()
> -except TclError as msg:
> -raise unittest.SkipTest('TclError: %s' % msg)
> +cls.root = Tk()
>  
>  @classmethod
>  def tearDownClass(cls):
> diff --git a/Lib/test/test_idle.py b/Lib/test/test_idle.py
> --- a/Lib/test/test_idle.py
> +++ b/Lib/test/test_idle.py
> @@ -1,9 +1,21 @@
> -# Skip test if _tkinter or _thread wasn't built or idlelib was deleted.
> -from test.test_support import import_module
> -import_module('Tkinter')
> -import_module('threading')  # imported by PyShell, imports _thread
> +# Skip test if _thread or _tkinter wasn't built or idlelib was deleted.
> +from test.test_support import import_module, use_resources
> +import_module('threading')  # imported by idlelib.PyShell, imports _thread
> +tk = import_module('Tkinter')
>  idletest = import_module('idlelib.idle_test')
>  
> +# If buildbot improperly sets gui resource (#18365, #18441), remove it
> +# so requires('gui') tests are skipped while non-gui tests still run.
> +if use_resources and 'gui' in use_resources:
> +try:
> +root = tk.Tk()
> +root.destroy()
> +except TclError:
> +while True:
> +use_resources.delete('gui')
> +if 'gui' not in use_resources:
> +break

I believe that this logic is incorrect.  If regrtest is run with "-u
gui", given this code the skip message will be "requires gui
resource"...but the caller specified the gui resource, which will make
the skip message completely confusing.

Instead, if it is true that 'gui' always means 'tk must work', then the
_is_gui_available function should do the Tk() check.  Currently as far
as I can see it is indeed the case that requires('gui') always means tk
must work.  So, I believe that the correct fix is to move
check_tk_availability to test.support, and call it from
_is_gui_available.  If we ever add another gui toolkit, we can deal with
moving the tk check out into a separate 'tk' resource at that time.

> +
>  # Without test_main present, regrtest.runtest_inner (line1219) calls
>  # unittest.TestLoader().loadTestsFromModule(this_module) which calls
>  # load_tests() if it finds it. (Unittest.main does the same.)
> 
> -- 
> Repository URL: http://hg.python.org/cpython
> ___
> Python-checkins mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-checkins
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-07-30 Thread Antoine Pitrou 

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 globals to None before trying to reclaim modules.
(and then, we don't need to cache global functions for use in
finalizers, either)

I have a patch to suppress the hack in
http://bugs.python.org/issue18214
Once I get to add some tests, I would like to commit it soon too!

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-07-30 Thread Paul Moore 
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 mystery to me, so this is very useful. Saved for
future reference.

Paul
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-07-30 Thread Guido van Rossum 
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 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 globals to None before trying to reclaim modules.
> (and then, we don't need to cache global functions for use in
> finalizers, either)
>
> I have a patch to suppress the hack in
> http://bugs.python.org/issue18214
> Once I get to add some tests, I would like to commit it soon too!
>
> Regards
>
> Antoine.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PyPy3 2.1 beta 1 released

2013-07-30 Thread Philip Jenvey 

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 supporting the work that went into this and future releases.

You can download the PyPy3 2.1 beta 1 release here:

http://pypy.org/download.html#pypy3-2-1-beta-1

Highlights
==

* The first release of PyPy3: support for Python 3, targetting CPython 3.2.3!

  - There are some `known issues`_ including performance regressions (issues
`#1540`_ & `#1541`_) slated to be resolved before the final release.

What is PyPy?
==

PyPy is a very compliant Python interpreter, almost a drop-in replacement for
CPython 2.7.3 or 3.2.3. It's fast due to its integrated tracing JIT compiler.

This release supports x86 machines running Linux 32/64, Mac OS X 64 or Windows
32. Also this release supports ARM machines running Linux 32bit - anything with
``ARMv6`` (like the Raspberry Pi) or ``ARMv7`` (like Beagleboard,
Chromebook, Cubieboard, etc.) that supports ``VFPv3`` should work.


Cheers,
the PyPy team
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-07-30 Thread Tres Seaver 
-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) compatibility.
> 
> We would like to thank all of the people who donated_ to the `py3k
> proposal`_ for supporting the work that went into this and future
> releases.
> 
> You can download the PyPy3 2.1 beta 1 release here:
> 
> http://pypy.org/download.html#pypy3-2-1-beta-1
> 
> Highlights ==
> 
> * The first release of PyPy3: support for Python 3, targetting CPython
> 3.2.3!
> 
> - There are some `known issues`_ including performance regressions
> (issues `#1540`_ & `#1541`_) slated to be resolved before the final
> release.
> 
> What is PyPy? ==
> 
> PyPy is a very compliant Python interpreter, almost a drop-in
> replacement for CPython 2.7.3 or 3.2.3. It's fast due to its
> integrated tracing JIT compiler.
> 
> This release supports x86 machines running Linux 32/64, Mac OS X 64 or
> Windows 32. Also this release supports ARM machines running Linux
> 32bit - anything with ``ARMv6`` (like the Raspberry Pi) or ``ARMv7``
> (like Beagleboard, Chromebook, Cubieboard, etc.) that supports
> ``VFPv3`` should work.

Wow -- congratulations!


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  [email protected]
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlH4LbQACgkQ+gerLs4ltQ655ACfXIlTNAldCJdCSjY0Os8xIhLu
vl4AoIi8eXqB6Ef/RO2W46iIbQvlX41j
=R2vL
-END PGP SIGNATURE-

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-07-30 Thread Antoine Pitrou 
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 even after being removed from
sys.modules:

- it is held alive by a C extension: the main example is the locale
  module, which is held alive by _io and in turn keeps alive other
  Python modules (such as collections or re). But there is also the
  readline module, whose completer can keep alive other stuff (this
  is aggravated by the fact the readline module currently doesn't
  have a proper dealloc routine).

- it is held alive through builtins: the site module patches builtins
  with additional objects, which themselves keep references to the site
  module's globals, and with it other modules

Regards

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 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 globals to None before trying to reclaim modules.
> > (and then, we don't need to cache global functions for use in
> > finalizers, either)
> >
> > I have a patch to suppress the hack in
> > http://bugs.python.org/issue18214
> > Once I get to add some tests, I would like to commit it soon too!
> >
> > Regards
> >
> > Antoine.
> 

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-07-30 Thread Christian Heimes 
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 all steps in one
> simple make tag. http://bugs.python.org/issue18481

Have fun with

   make coverage-report

as documented in the devguide


http://docs.python.org/devguide/coverage.html#measuring-coverage-of-c-code-with-gcov-and-lcov

Christian


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-07-30 Thread Christian Heimes 
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 extension -- so much for Windows. I also don't know if gcov
supports cross-profiling on varying platforms and operating systems.

By the way gcov understands preprocessor output. It doesn't report lines
as uncovered when the lines or functions are #ifdef-ed out.

Christian

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-07-30 Thread Terry Reedy 

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 another issue.)



+# Skip test if _thread or _tkinter wasn't built or idlelib was deleted.
+from test.test_support import import_module, use_resources
+import_module('threading')  # imported by idlelib.PyShell, imports _thread
+tk = import_module('Tkinter')
  idletest = import_module('idlelib.idle_test')

+# If buildbot improperly sets gui resource (#18365, #18441), remove it
+# so requires('gui') tests are skipped while non-gui tests still run.
+if use_resources and 'gui' in use_resources:
+try:
+root = tk.Tk()
+root.destroy()
+except TclError:
+while True:
+use_resources.delete('gui')
+if 'gui' not in use_resources:
+break


I believe that this logic is incorrect.


It works for the intended purpose.


If regrtest is run with "-u gui", given this code the skip message will

> be "requires gui resource" but the caller specified the gui resource,
> which will make the skip message completely confusing.

The message is accurate; string 'gui' does not create or enable the 
required physical graphics subsystem. Anyway, the message is not in any 
of the current buildbot reports I looked at. This patch has no effect on 
normal machines with graphics and nor on most of the buildbots (at least 
the stable one). On the 3 stable buildbots it is written for, the 
message will only appear if test_idle fails (in one of the text tests 
that do run) and is rerun or displayed in verbose mode. I doubt that 
such a rare occurrence will seriously confuse any of the few developers 
who will read the verbose idle_test output.



Instead, if it is true that 'gui' always means 'tk must work', then the
_is_gui_available function should do the Tk() check.  Currently as far
as I can see it is indeed the case that requires('gui') always means tk
must work.  So, I believe that the correct fix is to move
check_tk_availability to test.support, and call it from
_is_gui_available.


Ned and I agreed in the issue discussion that gui checks (also in 
tkinter files) should be consolidated into test.support. See

http://bugs.python.org/issue18604
The check in this patch will be modified or simply removed once that is 
done. But I need it here now to continue pushing new idle tests.


A consolidated gui check could report to the user something like "'gui' 
is being ignored because graphics are not usable".


> If we ever add another gui toolkit, we can deal with

moving the tk check out into a separate 'tk' resource at that time.


The above check is intended mostly as a gui check, not a tk check, 
because it is only performed after successfully importing tkinter, which 
imports _tkinter, which initializes tcl/tk.


--
Terry Jan Reedy
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-07-30 Thread Greg Ewing 

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.

--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-07-30 Thread R. David Murray 
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 this code the skip message will
>  > be "requires gui resource" but the caller specified the gui resource,
>  > which will make the skip message completely confusing.
> 
> The message is accurate; string 'gui' does not create or enable the 
> required physical graphics subsystem. Anyway, the message is not in any 
> of the current buildbot reports I looked at. This patch has no effect on 
> normal machines with graphics and nor on most of the buildbots (at least 
> the stable one). On the 3 stable buildbots it is written for, the 
> message will only appear if test_idle fails (in one of the text tests 
> that do run) and is rerun or displayed in verbose mode. I doubt that 
> such a rare occurrence will seriously confuse any of the few developers 
> who will read the verbose idle_test output.

OK, I see what you are saying, but I really do think the skip message
should differentiate between the flag not being specified and the
physical resource not existing.

> > Instead, if it is true that 'gui' always means 'tk must work', then the
> > _is_gui_available function should do the Tk() check.  Currently as far
> > as I can see it is indeed the case that requires('gui') always means tk
> > must work.  So, I believe that the correct fix is to move
> > check_tk_availability to test.support, and call it from
> > _is_gui_available.
> 
> Ned and I agreed in the issue discussion that gui checks (also in 
> tkinter files) should be consolidated into test.support. See
> http://bugs.python.org/issue18604
> The check in this patch will be modified or simply removed once that is 
> done. But I need it here now to continue pushing new idle tests.
> 
> A consolidated gui check could report to the user something like "'gui' 
> is being ignored because graphics are not usable".

As long as this is the end result, I'm fine with it.

--David
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-07-30 Thread Ronald Oussoren 
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 "readPlist" and 
"writePlist" instead of "load" and "dump".

While working on the issue I noticed something uglier than that: plistlib in 
py3k inherits a design decision that was necessary in py2 and feels decidedly 
odd in py3k. It represents binary data objects of type plistlib.Data instead of 
bytes. Those objects have an attribute with the actual data. The distinction 
was necessary in Python 2 to make it possible to keep binary data and strings 
apart, but is no longer necessary in Python 3.

Because of this I'd like to introduce a new API in plistlib that fixes both 
problems. In particular:

* Add 'load', 'loads', 'dump' and 'dumps', those use "bytes" for binary data by 
default

* Keep and deprecate "readPlist", "writePlist" and the their string 
equivalents, those still use Data objects (and call the new API to do the 
actual work).

I'd like some feedback on this change. On the one hand the new APIs make it 
possible to clean up the API of plistlib, on the other hand this is a big API 
change.

Ronald

P.S. The issue itself is about adding support for binary plist files, I got a 
bit carried away while testing and refactoring the original patch :-(
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-07-30 Thread Ronald Oussoren 

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 previous version:
> 
> * Better explanation of why this is a useful addition
> 
> * type.__locallookup__ is no longer optional.
> 
> * I've added benchmarking results using pybench.
>  (using the patch attached to issue 18181)
> 
> Ronald

And something I forgot to ask: is anyone willing to be the BDFL-Delegate for
PEP 447?

Ronald
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-07-30 Thread Antoine Pitrou 
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 that case, since
> it's still accessible via those patched builtins.

Of course. I'm not gonna kill reachable modules like a cowboy on the
loose :-)
The problem is that its global objects will get finalized very late.

Anyway, the solution is to unpatch builtins through an atexit handler
in the site module.

(my patch still has a last step where surviving modules get their
globals wiped, though)

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com