[issue11723] No proper support for mingw64 - patch to add

[Jason Morgan]

Jason Morgan  added the comment:

Ok, I know there is a typo, (mings64 should read mingw64) I realised after 
posting but can't edit it. I don't need any more emails telling me I can't 
spell (or type) - I knew that already!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11722] mingw64 does not link when building extensions

[Jason Morgan]

Jason Morgan  added the comment:

OK,  I've understood this a bit more.

The compiler does not cause pyconfig.h to define SIZEOF_SIZE_T and SIZEOF_INT, 
rather it is the definition of MS_WIN64 at compile time (which was not being 
defined)

Defining MS_WIN64 fixes the problem, and causes another unrelated one

I would guess that I would have to change the patch in Issue11723 to define 
MS_WIN64, how do I then use the same compiler for 32BIT?  What is the correct 
way to pass such flags to the compiler class?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11393] Integrate faulthandler module into Python 3.3

[Roundup Robot]

Roundup Robot  added the comment:

New changeset a6d2c703586a by Victor Stinner in branch 'default':
Issue #11393: Fix the documentation (cancel_dump_traceback_later)
http://hg.python.org/cpython/rev/a6d2c703586a

New changeset e289b64f355d by Victor Stinner in branch 'default':
Issue #11393: limit stack overflow test to 100 MB
http://hg.python.org/cpython/rev/e289b64f355d

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11726] linecache becomes specific to Python scripts in Python 3

[STINNER Victor]

New submission from STINNER Victor :

linecache document doesn't tell that the module reads the #coding:xxx cookie to 
get the encoding of the Python file. linecache reads this cookie since 41665 
(May 09 2007).

"The linecache module allows one to get any line from any file, ..."

=> "any file"!

And the example uses /etc/passwd which is not a Python file.

Not only it reads the #coding:xxx cookie, but updatecache() tries also a PEP 
302 loader to read the file.

linecache should be marked as very specific to Python scripts, or it should be 
patched to become more generic (don't read the cookie / use loader by default).

Note: the locale encoding may change between to calls to the linecache module.

--
assignee: docs@python
components: Documentation, Library (Lib)
messages: 132641
nosy: docs@python, haypo
priority: normal
severity: normal
status: open
title: linecache becomes specific to Python scripts in Python 3
versions: Python 3.1, Python 3.2, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11393] Integrate faulthandler module into Python 3.3

[STINNER Victor]

STINNER Victor  added the comment:

test_faulthandler blocked AMD64 Gentoo Wide 3.x and AMD64 OpenIndiana 3.x 
buildbots because of the stack overflow test.

> New changeset e289b64f355d by Victor Stinner in branch 'default':
> Issue #11393: limit stack overflow test to 100 MB
> http://hg.python.org/cpython/rev/e289b64f355d

Ok, it fixed test_faulthandler on AMD64 OpenIndiana 3.x and AMD64 Gentoo Wide 
3.x.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11727] Add a --timeout option to regrtest.py using the faulthandler module

[STINNER Victor]

New submission from STINNER Victor :

I would be nice to add a timeout option to regrtest.py to be able to dump the 
traceback after TIMEOUT seconds and also exit the process. It would help 
debugging timeout issues (e.g. test_multiprocessing ), but also protect 
buildbots against evil (long) tests.

Attached patch implements this feature.

--
components: Tests
files: regrtest_timeout.patch
keywords: buildbot, patch
messages: 132643
nosy: haypo
priority: normal
severity: normal
status: open
title: Add a --timeout option to regrtest.py using the faulthandler module
versions: Python 3.3
Added file: http://bugs.python.org/file21488/regrtest_timeout.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11393] Integrate faulthandler module into Python 3.3

[STINNER Victor]

STINNER Victor  added the comment:

I opened #11727 for the patch on regrtest.py. All buildbots look happy (no more 
failure on test_faulthandler), so let's close this issue.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11663] multiprocessing (and concurrent.futures) doesn't detect killed processes

[STINNER Victor]

STINNER Victor  added the comment:

This issue is a duplicate of #9205.

--
resolution:  -> duplicate
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

[STINNER Victor]

STINNER Victor  added the comment:

Issue #11663 has been marked as a duplicate.

--
nosy: +bquinlan, haypo, pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11727] Add a --timeout option to regrtest.py using the faulthandler module

[STINNER Victor]

STINNER Victor  added the comment:

I created a new Mercurial repository to test this issue: 
features/regrtest_timeout.

Let's try it with a timeout of 5 minutes on:
 - "x86 Tiger custom" to learn more about test_threadsignals timeout (1 hour) 
=> issue #11223
 - "x86 FreeBSD 7.2 3.x" to learn more about test_multiprocessing failures 
(timeout of 1 hour sometimes) => issue #8428

http://www.python.org/dev/buildbot/all/builders/x86%20Tiger%20custom/builds/2
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%207.2%20custom/builds/3

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6087] distutils.sysconfig.get_python_lib gives surprising result when used with a Python build

[Vinay Sajip]

Vinay Sajip  added the comment:

Actually, the makefile location *is* wrong - ignore my last comment 
contradicting that.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10656] "Out of tree" build fails on AIX 5.3

[Tristan Carel]

Tristan Carel  added the comment:

I have experienced the same problem under ppc64 aix 6.1.2.0 while compiling 
Python 2.7.1

$ cd Python-2.7.1
$ mkdir __build
$ cd __build
$ ../configure --with-gcc=xlc_r --with-cxx-main=xlC_r --with-threads 
--disable-ipv6
$ /usr/linux/bin/make
[...]
../Modules/ld_so_aix xlc_r -bI:Modules/python.exp -L.. -L/opt/freeware/lib 
-L/opt/freeware/lib 
build/temp.aix-6.1-2.7/data/tcarel/ngbuilder/python/2.7.1/Python-2.7.1/Modules/_struct.o
 -L/opt/freeware/lib -L/usr/local/lib -o build/lib.aix-6.1-2.7/_struct.so
unable to execute ../Modules/ld_so_aix: No such file or directory

There are references to $(srcdir)/Modules/ld_so_aix in both configure.in and 
Makefile.pre.in whereas ld_so_aix is created in build tree.

==
diff -r f4e6e18cae4b Makefile.pre.in
--- a/Makefile.pre.in   Tue Mar 29 17:28:25 2011 -0700
+++ b/Makefile.pre.in   Thu Mar 31 13:05:45 2011 +0200
@@ -1028,7 +1028,7 @@
$(INSTALL_SCRIPT) $(srcdir)/Modules/makexp_aix  \
$(DESTDIR)$(LIBPL)/makexp_aix;  \
echo "$(LIBPL)/makexp_aix"; \
-   $(INSTALL_SCRIPT) $(srcdir)/Modules/ld_so_aix   \
+   $(INSTALL_SCRIPT) Modules/ld_so_aix \
$(DESTDIR)$(LIBPL)/ld_so_aix;   \
echo "$(LIBPL)/ld_so_aix";  \
echo; echo "See Misc/AIX-NOTES for details.";   \
diff -r f4e6e18cae4b configure.in
--- a/configure.in  Tue Mar 29 17:28:25 2011 -0700
+++ b/configure.in  Thu Mar 31 13:05:45 2011 +0200
@@ -1778,7 +1778,7 @@
 then
case $ac_sys_system/$ac_sys_release in
AIX*)
-   BLDSHARED="\$(srcdir)/Modules/ld_so_aix \$(CC) 
-bI:\$(srcdir)/Modules/python.exp"
+   BLDSHARED="Modules/ld_so_aix \$(CC) -bI:Modules/python.exp 
-L\$(srcdir)"
LDSHARED="\$(BINLIBDEST)/config/ld_so_aix \$(CC) 
-bI:\$(BINLIBDEST)/config/python.exp"
;;
BeOS*)
==

After fixing these 2 files, Modules/ld_so_aix is found and properly executed by 
compilation process, but then there is a new issue:

Modules/ld_so_aix xlc_r -bI:Modules/python.exp -L.. -L/opt/freeware/lib 
-L/opt/freeware/lib 
build/temp.aix-6.1-2.7/data/tcarel/Python-2.7.1/Modules/_struct.o 
-L/opt/freeware/lib -L/usr/local/lib -o build/lib.aix-6.1-2.7/_struct.so
Modules/ld_so_aix[183]: Modules/makexp_aix:  not found.

This time, makexp_aix is expected to be is the same directory than ld_so_aix 
whereas makeexp_aix remains in the source tree.

Here is a fix:

==
diff -r f4e6e18cae4b Modules/ld_so_aix.in
--- a/Modules/ld_so_aix.in  Tue Mar 29 17:28:25 2011 -0700
+++ b/Modules/ld_so_aix.in  Thu Mar 31 13:01:57 2011 +0200
@@ -69,7 +69,10 @@
   echo $usage; exit 2
 fi
 
-makexp=`dirname $0`/makexp_aix
+makexp=`dirname $0`/@srcdir@/makexp_aix
+if test ! -e "$makexp" ; then
+  makeexp=makexp_aix
+fi
 
 # Check for existence of compiler.
 CC=$1; shift
==

The first value fix the issue while building Python. The second will use PATH 
to find makeexp_aix as explained in section `SHARED LIBRARY SUPPORT' in 
AIX-NOTES (for building shared extension modules).

You can find a patch for 2.7 branch in attachment.

Regards
-- 
Tristan Carel
Exalead

--
keywords: +patch
nosy: +Tristan.Carel
Added file: http://bugs.python.org/file21489/aix-fix-out-of-source.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

I can't see how that patch has anything to do with it.  The problem has been 
present since at least 2.5.  Your patch fixed it for timeout>0.0 but left the 
0.0 case still broken.

It comes from these lines in init_sockobject:
{
 s->sock_timeout = defaulttimeout;
 if (defaulttimeout >= 0.0)
 internal_setblocking(s, 0);
}
This code assumes that the socket's internal state is always blocking, and so 
only switches it into the non-blocking state if required.

Now, you fixed the 'accept' case with your socket.py patch, but you left out 
the case where accept_socket.gettimeout() == 0.0.  In other words, you fixed 
only accept_socket.gettimeout() > 0.0

We can fix it to be as advertized, except that the second part is not possible: 
"if the listening socket is in non-blocking mode, whether the socket 
returned by accept() is in blocking or non-blocking mode is operating 
system-dependent. If you want to ensure cross-platform behaviour, it is 
recommended you manually override this setting."
The reason is that it is impossible to _ask_ the socket whether it is blocking 
or non-blocking and therefore, accepted_socket.gettimeout() will not be 
truthful.

imho, we should just simplify this rule and have the accepted socket inherit 
the accept socket's properties if defaulttimeout() == None, and not make this 
special case.  I'll prepare a demonstration patch.

I've added a suggested patch.
p.s. My comments about fixing things in socketmodule.c were only half correct.  
I didn't realize that accept had been broken into _accept and socket() in py3k.

--
hgrepos: +14
Added file: http://bugs.python.org/file21490/defined.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11727] Add a --timeout option to regrtest.py using the faulthandler module

[STINNER Victor]

STINNER Victor  added the comment:

Try the branch on "PPC Leopard 3.x" (test_subprocess timeout):

http://www.python.org/dev/buildbot/all/builders/PPC%20Leopard%20custom/builds/6

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1635741] Interpreter seems to leak references after finalization

[Tim Lesher]

Changes by Tim Lesher :


--
nosy: +tlesher

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11393] Integrate faulthandler module into Python 3.3

[Antoine Pitrou]

Antoine Pitrou  added the comment:

There is a failure on FreeBSD:

==
FAIL: test_dump_tracebacks_later_repeat 
(test.test_faulthandler.FaultHandlerTests)
--
Traceback (most recent call last):
  File 
"/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_faulthandler.py",
 line 406, in test_dump_tracebacks_later_repeat
self.check_dump_tracebacks_later(repeat=True)
  File 
"/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_faulthandler.py",
 line 400, in check_dump_tracebacks_later
self._check_dump_tracebacks_later(repeat, cancel, None)
  File 
"/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_faulthandler.py",
 line 381, in _check_dump_tracebacks_later
trace = self.get_output(code, True, filename)
  File 
"/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_faulthandler.py",
 line 57, in get_output
self.assertEqual(exitcode, 0)
AssertionError: -11 != 0

http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%203.x/builds/1333/steps/test/logs/stdio

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11393] Integrate faulthandler module into Python 3.3

[Roundup Robot]

Roundup Robot  added the comment:

New changeset aa2ac1581d23 by Victor Stinner in branch 'default':
Issue #11393: test_faulthandler checks the exitcode after the output
http://hg.python.org/cpython/rev/aa2ac1581d23

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11727] Add a --timeout option to regrtest.py using the faulthandler module

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Just a nit but:
"if timeout and 0 < timeout"

Could you use the usual coding style? ("if timeout and timeout > 0")

Putting constants on the left-side of comparisons is pointless in Python, and 
even in C it's quite ugly and surprising.

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11727] Add a --timeout option to regrtest.py using the faulthandler module

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> "x86 Tiger custom" to learn more about test_threadsignals timeout 
> (1 hour)

Please read the comments. There is no timeout anymore.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11727] Add a --timeout option to regrtest.py using the faulthandler module

[STINNER Victor]

STINNER Victor  added the comment:

>> "x86 Tiger custom" to learn more about test_threadsignals timeout 
>> (1 hour)
>
> Please read the comments. There is no timeout anymore.

The last build failed with:
---
...
[213/354] test_plistlib
[214/354] test_minidom
[215/354] test_threadsignals

command timed out: 3600 seconds without output, killing pid 24165
process killed by signal 9
---
http://www.python.org/dev/buildbot/all/builders/x86%20Tiger%203.x/builds/2262/steps/test/logs/stdio

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11728] mbox parser incorrect behaviour

[valera]

New submission from valera :

mailbox.mbox  parser is splitting mbox files by "^From " pattern, which is 
wrong , in fairy it should split mbox by "\nFrom ".
Illustration:
--
>From bla-blah@localhost
Header1
Header2
body1
body2

>From blah-blah2@localhost
Header1
body1
>From your dear friend
body3

--
This mbox would be splitted in 3 messages instead of 2

--
components: Library (Lib)
messages: 132657
nosy: wally1980
priority: normal
severity: normal
status: open
title: mbox parser incorrect behaviour
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 
3.3, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11724] concurrent.futures: executor.submit() runs until completion even when future times out or is canceled

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Agreed with Brian. There is generally no reliable way to terminate another 
thread or process without cooperation from said thread or process. Especially 
in the case of threads, terminating a thread while leaving the process alive 
may leave some resources (including Python interpreter resources) in a 
consistent state. Admittedly, terminating a process could be implemented using 
kill().

The solution is to write your long-running task so that it can be cancelled 
using a synchronization object (such as an Event).

--
nosy: +pitrou
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11727] Add a --timeout option to regrtest.py using the faulthandler module

[STINNER Victor]

STINNER Victor  added the comment:

I ran the full test suite on "x86 Tiger custom" on my features/regrtest_timeout 
repository: no failure (test_threadsignals failure was not reproduced).

On "PPC Leopard custom", the test suite was interrupted (timeout) on 
test_io.test_basic_io:

...
[ 53/354] test_xdrlib
[ 54/354] test_descr
[ 55/354] test_io
Current thread 0xa09e1820:
  File "/Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/codecs.py", 
line 302 in decode
  File "/Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/_pyio.py", 
line 1378 in decode
  File "/Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/_pyio.py", 
line 1682 in _read_chunk
  File "/Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/_pyio.py", 
line 2002 in readline
  File 
"/Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/test/test_io.py", 
line 1964 in multi_line_test
  File 
"/Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/test/test_io.py", 
line 1945 in test_basic_io
  File 
"/Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/unittest/case.py", 
line 387 in _executeTestPart
  File 
"/Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/unittest/case.py", 
line 442 in run
  File 
"/Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/unittest/case.py", 
line 494 in __call__
  File 
"/Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/unittest/suite.py", 
line 105 in run
  File 
"/Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/unittest/suite.py", 
line 67 in __call__
  File 
"/Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/unittest/suite.py", 
line 105 in run
  File 
"/Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/unittest/suite.py", 
line 67 in __call__
  File 
"/Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/test/support.py", 
line 1078 in run
  File 
"/Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/test/support.py", 
line 1166 in _run_suite
  File 
"/Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/test/support.py", 
line 1192 in run_unittest
  File 
"/Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/test/test_io.py", 
line 2845 in test_main
  File "./Lib/test/regrtest.py", line 1029 in runtest_inner
  File "./Lib/test/regrtest.py", line 823 in runtest
  File "./Lib/test/regrtest.py", line 649 in main
  File "./Lib/test/regrtest.py", line 1604 in 
make: *** [buildbottest] Error 1
program finished with exit code 2
---
http://www.python.org/dev/buildbot/all/builders/PPC%20Leopard%20custom/builds/6

Cool! The traceback was printed correctly, the process exited correctly , and 
the build stopped also correctly. The full (interrupted) build took 27 min 41 
sec, it takes usually 56 min 44 sec.

So a timeout of 5 minutes on each test (each function of each test file) is not 
enough on PPC Leopard buildslave. Anyway, I plan to use something closer to the 
actual buildbot timeout (1200 or 3600 seconds). And it would be better if the 
buildbot can choose its own regrtest.py timeout.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The problem with this approach is that it won't help concurrent.futures.
Detection of killed endpoints should ideally happen at a lower level, e.g. in 
Process or Queue or Connection objects.

Speaking of which, I wonder why we have both multiprocessing.Pool and 
concurrent.futures.ProcessPoolExecutor. They seem to fill the exact same needs, 
with different APIs...

--
keywords: +easy -patch
versions: +Python 3.2, Python 3.3 -Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

[Jesse Noller]

Jesse Noller  added the comment:

On Thu, Mar 31, 2011 at 8:25 AM, Antoine Pitrou  wrote:
>
> Antoine Pitrou  added the comment:
>
> Speaking of which, I wonder why we have both multiprocessing.Pool and 
> concurrent.futures.ProcessPoolExecutor. They seem to fill the exact same 
> needs, with different APIs...
>

Brian and I need to work on the consolidation we intend(ed) to occur
as people got comfortable with the APIs. My eventual goal is to remove
anything but the basic multiprocessing.Process/Queue stuff out of MP
and into concurrent.* and support threading backends for it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10963] "subprocess" can raise OSError (EPIPE) when communicating with short-lived processes

[Ross Lagerwall]

Ross Lagerwall  added the comment:

I'd argue that this is not a feature request but a bug.

I did some testing of this issue and the problem is that EPIPE is only 
generated sometimes depending on the time the process takes to finish, the size 
of the data sent, the underlying mechanism used (select vs poll) and the 
whether anything happens between the starting of the process and the 
communicate() call.

Here are some results (on my PC, I think some of these will vary on others):
With poll:
 [sys.executable, 'c', 'pass']- no error
 ['dd', 'option=bad'] - varies between EPIPE and no error
 ['dd', 'option=bad'], sleep(1) - EPIPE

With select:
 [sys.executable, 'c', 'pass']- EPIPE
 ['dd', 'option=bad'] - EPIPE
 ['dd', 'option=bad'], sleep(1) - EPIPE

Only stdin (neither select or poll):
 [sys.executable, 'c', 'pass']- no error (error in 2.7)
 ['dd', 'option=bad'] - no error (error in 2.7)
 ['dd', 'option=bad'], sleep(1) - EPIPE

(all of my tests appear to fail on Windows, they also generate EINVAL sometimes)

I think it's best to remove all this inconsistency and fix it so that EPIPE is 
never generated and then backport it to 2.7, 3.1, 3.2.

Attached is a patch which fixes it for poll, select, windows and adds two tests.

--
nosy: +rosslagerwall
Added file: http://bugs.python.org/file21491/10963.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11729] libffi assembler relocation check is not robust, fails with clang

[Ismail Donmez]

New submission from Ismail Donmez :

The check under Modules/_ctypes/libffi/configure.ac does;

echo '.text; foo: nop; .data; .long foo-.; .text' > conftest.s
if $CC $CFLAGS -c conftest.s 2>&1 | grep -i warning > /dev/null; then
libffi_cv_as_x86_pcrel=no
fi  

With clang; we get:

clang: warning: argument unused during compilation: '-g'

So it fails to detect pc relocation support due to an unrelated warning.

--
components: Build
messages: 132663
nosy: cartman
priority: normal
severity: normal
status: open
title: libffi assembler relocation check is not robust, fails with clang
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Possible plan for POSIX, where a connection uses a pipe() or socketpair(): 
exploit the fact that an endpoint becomes ready for reading (indicating EOF) 
when the other endpoint is closed:

>>> r, w = os.pipe()
>>> select.select([r], [], [r], 0)
([], [], [])
>>> os.close(w)
>>> select.select([r], [], [r], 0)
([4], [], [])

>>> a, b = socket.socketpair()
>>> select.select([b], [], [b], 0)
([], [], [])
>>> a.close()
>>> select.select([b], [], [b], 0)
([], [], [])

So, each Process could have a sentinel fd in the parent process, which becomes 
ready when the process exits. These sentinel fds can be used in the various 
select() calls underlying Queue.get().

(I don't understand why _multiprocessing/socket_connection.c in written in C. 
Rewriting it in Python would make improvements much easier)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

[Antoine Pitrou]

Antoine Pitrou  added the comment:

(certainly not easy, sorry)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

[Jesse Noller]

Jesse Noller  added the comment:

On Thu, Mar 31, 2011 at 9:05 AM, Antoine Pitrou  wrote:
>
> Antoine Pitrou  added the comment:
>
> Possible plan for POSIX, where a connection uses a pipe() or socketpair(): 
> exploit the fact that an endpoint becomes ready for reading (indicating EOF) 
> when the other endpoint is closed:
>
 r, w = os.pipe()
 select.select([r], [], [r], 0)
> ([], [], [])
 os.close(w)
 select.select([r], [], [r], 0)
> ([4], [], [])
>
 a, b = socket.socketpair()
 select.select([b], [], [b], 0)
> ([], [], [])
 a.close()
 select.select([b], [], [b], 0)
> ([], [], [])
>
> So, each Process could have a sentinel fd in the parent process, which 
> becomes ready when the process exits. These sentinel fds can be used in the 
> various select() calls underlying Queue.get().
>
> (I don't understand why _multiprocessing/socket_connection.c in written in C. 
> Rewriting it in Python would make improvements much easier)

I concur with you. The only reason it is in C is legacy; I don't see
an immediate reason why it should continue to be that way

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11727] Add a --timeout option to regrtest.py using the faulthandler module

[STINNER Victor]

STINNER Victor  added the comment:

Result on "x86 FreeBSD 7.2 custom":

...
[148/354] test_fileinput
[149/354] test_subprocess
[36645 refs]
[36645 refs]
...
[36647 refs]
[44034 refs]
Current thread 0x28401040:
  File 
"/usr/home/db3l/buildarea/custom.bolen-freebsd7/build/Lib/subprocess.py", line 
1282 in _execute_child
  File 
"/usr/home/db3l/buildarea/custom.bolen-freebsd7/build/Lib/subprocess.py", line 
766 in __init__
  File 
"/usr/home/db3l/buildarea/custom.bolen-freebsd7/build/Lib/test/test_subprocess.py",
 line 687 in test_leaking_fds_on_error
  File 
"/usr/home/db3l/buildarea/custom.bolen-freebsd7/build/Lib/unittest/case.py", 
line 387 in _executeTestPart
  File 
"/usr/home/db3l/buildarea/custom.bolen-freebsd7/build/Lib/unittest/case.py", 
line 442 in run
  File 
"/usr/home/db3l/buildarea/custom.bolen-freebsd7/build/Lib/unittest/case.py", 
line 494 in __call__
  File 
"/usr/home/db3l/buildarea/custom.bolen-freebsd7/build/Lib/unittest/suite.py", 
line 105 in run
  File 
"/usr/home/db3l/buildarea/custom.bolen-freebsd7/build/Lib/unittest/suite.py", 
line 67 in __call__
  File 
"/usr/home/db3l/buildarea/custom.bolen-freebsd7/build/Lib/unittest/suite.py", 
line 105 in run
  File 
"/usr/home/db3l/buildarea/custom.bolen-freebsd7/build/Lib/unittest/suite.py", 
line 67 in __call__
  File 
"/usr/home/db3l/buildarea/custom.bolen-freebsd7/build/Lib/test/support.py", 
line 1078 in run
  File 
"/usr/home/db3l/buildarea/custom.bolen-freebsd7/build/Lib/test/support.py", 
line 1166 in _run_suite
  File 
"/usr/home/db3l/buildarea/custom.bolen-freebsd7/build/Lib/test/support.py", 
line 1192 in run_unittest
  File 
"/usr/home/db3l/buildarea/custom.bolen-freebsd7/build/Lib/test/test_subprocess.py",
 line 1607 in test_main
  File "./Lib/test/regrtest.py", line 1029 in runtest_inner
  File "./Lib/test/regrtest.py", line 823 in runtest
  File "./Lib/test/regrtest.py", line 649 in main
  File "./Lib/test/regrtest.py", line 1604 in 
program finished with exit code 1
elapsedTime=2100.157408

http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%207.2%20custom/builds/3

So test_subprocess does timeout (5 min) because of test_leaking_fds_on_error, 
it may be related to #8052. subprocess.MAXFD=655000 on FreeBSD: create a 
subprocess requires to call close() system calls 655,000 times and 
test_leaking_fds_on_error() creates 1024 subprocesses.

There is something interesting in this output: the test uses a subprocess and 
we only have the traceback of the parent. It may be nice to have the trace of 
the child process. It might be possible by sending a signal to the child 
process (but how can we get the list of the child processes in a C signal 
handler?).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11284] slow close file descriptors in subprocess, popen2, os.popen*

[STINNER Victor]

STINNER Victor  added the comment:

test_subprocess.test_leaking_fds_on_error takes more than 5 minutes on x86 
FreeBSD 7.2 build slave! This tests creates 1,024 subprocesses, and subprocess 
has to close 655,000 file descriptors just to create on child process (whereas 
there are only something like 10 open files...).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8052] subprocess close_fds behavior should only close open fds

[STINNER Victor]

STINNER Victor  added the comment:

test_subprocess.test_leaking_fds_on_error takes more than 5 minutes on x86 
FreeBSD 7.2 build slave! This tests creates 1,024 subprocesses, and subprocess 
has to close 655,000 file descriptors just to create on child process (whereas 
there are only something like 10 open files...).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

[R. David Murray]

Changes by R. David Murray :


--
keywords:  -easy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11727] Add a --timeout option to regrtest.py using the faulthandler module

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11678] Add support for Arch Linux to platform.linux_distributions()

[Westley Martínez]

Westley Martínez  added the comment:

Perhaps I wasn't clear. That release version isn't for the system. It's for the 
installation disc. There's no way to get that info and it means nothing to 
anyone anyways. All users of Arch are expected to have their system fully up to 
date. There are no releases; Just do "pacman -Syu" and the system is made up to 
date.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11728] mbox parser incorrect behaviour

[R. David Murray]

R. David Murray  added the comment:

All the references I could find talk about triggering the match without the 
proceeding newline.  That is, it is not certain that a blank line will precede 
the 'From ' header, and the typical quoting rules for mbox format call for any 
'From ' at the start of a line (whether preceded by a blank line or not) to be 
quoted.  This might have something to do with the fact that otherwise you have 
to special case the first line of the mbox, but I don't really know.

What tool are you using that is producing the unquoted 'From ' lines in your 
mbox?  I know there are variants on the mbox format, so if one of them has the 
format you propose, this would become a feature request to support that variant 
mbox format.

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11727] Add a --timeout option to regrtest.py using the faulthandler module

[Charles-Francois Natali]

Charles-Francois Natali  added the comment:

> There is something interesting in this output: the test uses a subprocess and 
> we only have the traceback of the parent. It may be nice to have the trace of 
> the child process. It might be possible by sending a signal to the child 
> process (but how can we get the list of the child processes in a C signal 
> handler?).

I don't think you can find that, but you could send a signal to the whole 
process group:
if (getpgrp() == getpid()) {
kill(-getpgrp(), );
}

The getpgrp() == getpid() makes sure that you'll only do that if the current 
process is the group leader (and it's async-safe). You'll probably want to 
block  in the parent's handler first.
Note that it won't work if your child process calls setsid(), of course 
(start_new_session argument to Popen).

--
nosy: +neologix

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10645] Remove egg-info files in stdlib

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11393] Integrate faulthandler module into Python 3.3

[STINNER Victor]

STINNER Victor  added the comment:

Same issue on PPC Leopard custom:

[224/354] test_faulthandler
test test_faulthandler failed -- Traceback (most recent call last):
  File 
"/Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/test/test_faulthandler.py",
 line 412, in test_dump_tracebacks_later_file
self.check_dump_tracebacks_later(file=True)
  File 
"/Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/test/test_faulthandler.py",
 line 398, in check_dump_tracebacks_later
self._check_dump_tracebacks_later(repeat, cancel, filename)
  File 
"/Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/test/test_faulthandler.py",
 line 381, in _check_dump_tracebacks_later
trace = self.get_output(code, True, filename)
  File 
"/Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/test/test_faulthandler.py",
 line 57, in get_output
self.assertEqual(exitcode, 0)
AssertionError: 1 != 0

Reopen the issue until this test is fixed.

--
resolution: fixed -> 
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10645] Remove egg-info files in stdlib

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I agree that the egg-info file should be removed in 3.3, especially because 
distutils2 has a better way of specifying python version dependencies.

The OSX installers for 2.7, 3.1 and 3.2 should remove the egg-info file for 
older releases, that way we at least don't lie about the version.

IMO we cannot remove the egg-info for current releases, someone might depend on 
their existence and this is a minor enough nit to not risk breaking code.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11729] libffi assembler relocation check is not robust, fails with clang

[Benjamin Peterson]

Benjamin Peterson  added the comment:

I suggest you complain to the libffi maintainers.

--
nosy: +benjamin.peterson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11729] libffi assembler relocation check is not robust, fails with clang

[Ismail Donmez]

Ismail Donmez  added the comment:

This is already fixed in upstream, check has been changed into:

libffi_cv_as_x86_pcrel=no
echo '.text; foo: nop; .data; .long foo-.; .text' > conftest.s
if $CC $CFLAGS -c conftest.s > /dev/null; then
libffi_cv_as_x86_pcrel=yes
fi
])

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11729] libffi assembler relocation check is not robust, fails with clang

[Arfrever Frehtes Taifersar Arahesis]

Arfrever Frehtes Taifersar Arahesis  added the comment:

You can install the newest libffi and pass --with-system-ffi option to main 
`configure` of Python.

--
nosy: +Arfrever

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11730] Setting sys.stdin to an invalid input stream causes interpreter run loop forever.

[ysj.ray]

New submission from ysj.ray :

Setting sys.stdin to an invalid input stream under interactive mode causes 
interpreter run loop forever:

Python 3.3a0 (default:22ae2b002865+, Mar 30 2011, 21:17:03) 
[GCC 4.4.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
[57804 refs]
>>> sys.stdin = None
[57809 refs]
[57809 refs]
[57809 refs]
[57809 refs]
[57809 refs]
..


Not only setting to None but also to any other invalid input stream could cause 
this. It's because in the beginning of PyRun_InteractiveOneFlags(), in order to 
get stdin encoding, the code tries to get sys.stdin and check if it's valid(not 
NULL, not None, has "encoding" attribute), if not, return -1 directly, then the 
loop in PyRun_InteractLoopFlags() continues and does the same thing. I think 
this should be fixed by using the Py_FileSystemDefaultEncoding instead when 
sys.stdin is invalid.

--
components: Interpreter Core
messages: 132678
nosy: ysj.ray
priority: normal
severity: normal
status: open
title: Setting sys.stdin to an invalid input stream causes interpreter run loop 
forever.
type: crash
versions: Python 3.1, Python 3.2, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11729] libffi assembler relocation check is not robust, fails with clang

[Ismail Donmez]

Ismail Donmez  added the comment:

Yes I can workaround it but I'd like to get it fixed inside Python too ;)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11729] libffi assembler relocation check is not robust, fails with clang

[Arfrever Frehtes Taifersar Arahesis]

Arfrever Frehtes Taifersar Arahesis  added the comment:

Internal copies of third-party libraries are rather always outdated, so it's 
better to always use system libraries. IMHO Python shouldn't bundle any 
third-party libraries and should force users to use system libraries. At least, 
system libraries could be used by default and main `configure` could accept 
--with-internal-expat and --with-internal-libffi options.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10632] multiprocessing generates a fatal error

[Dave Malcolm]

Dave Malcolm  added the comment:

This is indeed looking like it's RHEL-specific.

I was about to close it out as a duplicate of issue 10517, but I'm wondering 
why Brian chose to open it as a separate bug.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11726] linecache becomes specific to Python scripts in Python 3

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
priority: normal -> high

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11727] Add a --timeout option to regrtest.py using the faulthandler module

[Roundup Robot]

Roundup Robot  added the comment:

New changeset bdc946dc512a by Victor Stinner in branch 'default':
Issue #11727: add --timeout option to regrtest (disabled by default).
http://hg.python.org/cpython/rev/bdc946dc512a

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11393] Integrate faulthandler module into Python 3.3

[Roundup Robot]

Roundup Robot  added the comment:

New changeset e91de993964c by Victor Stinner in branch 'default':
Issue #11393: check that stdout is empty if we use a file
http://hg.python.org/cpython/rev/e91de993964c

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11727] Add a --timeout option to regrtest.py using the faulthandler module

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 0f3dbf93ac06 by Victor Stinner in branch 'default':
Issue #11727: Antoine and Arfrever don't like "0 < timeout" style (regrtest.py)
http://hg.python.org/cpython/rev/0f3dbf93ac06

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11727] Add a --timeout option to regrtest.py using the faulthandler module

[STINNER Victor]

STINNER Victor  added the comment:

Patch commited into 3.3 (bdc946dc512a, 0f3dbf93ac06). I opened a thread on 
python-dev to decide if we turn this on by default on buildbots.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11725] httplib and urllib2 failed ssl connection httplib.BadStatusLine

[Isaac Salsberg]

Isaac Salsberg  added the comment:

Yep, I am sure Ronald, the RH server has no special configuration. 

The RH box actually immediately connects to the server, an because it requires 
a certificate returns a 403 forbidden code:


[opentrails@redhat5 ~]$ uname -a
Linux redhat5.ultralat.com 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:14 EST 2007 
x86_64 x86_64 x86_64 GNU/Linux
[opentrails@redhat5 ~]$ python
Python 2.6.5 (r265:79063, Dec  1 2010, 19:40:01) 
[GCC 4.1.1 20070105 (Red Hat 4.1.1-52)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib2
>>> response = urllib2.urlopen('https://www.finratrace.org/')
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python2.6/urllib2.py", line 126, in urlopen
return _opener.open(url, data, timeout)
  File "/usr/local/lib/python2.6/urllib2.py", line 397, in open
response = meth(req, response)
  File "/usr/local/lib/python2.6/urllib2.py", line 510, in http_response
'http', request, response, code, msg, hdrs)
  File "/usr/local/lib/python2.6/urllib2.py", line 435, in error
return self._call_chain(*args)
  File "/usr/local/lib/python2.6/urllib2.py", line 369, in _call_chain
result = func(*args)
  File "/usr/local/lib/python2.6/urllib2.py", line 518, in http_error_default
raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 403: Forbidden

--

And "HTTP Error 403: Forbidden: is what MAC OS X should return as well when the 
certificate was not sent.

==

Furthermore, MAC OS X hangs even with the second sample code, which provides 
the certificate and the authentication, failing as well.

See the section ">Same thing happens Using python 2.7.1" on my original 
post. That example sends the certificate and the authentication but it simply 
hangs, getting the "httplib.BadStatusLine: ''" error at the end.

--
Now, if I send the authentication and certificate under the linux box, it works 
fine:



[opentrails@redhat5 ~]$ uname -a
Linux redhat5.ultralat.com 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:14 EST 2007 
x86_64 x86_64 x86_64 GNU/Linux
[opentrails@redhat5 ~]$ python
Python 2.6.5 (r265:79063, Dec  1 2010, 19:40:01) 
[GCC 4.1.1 20070105 (Red Hat 4.1.1-52)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import httplib,base64
>>> 
>>> key,cert=('/tmp/cert_nopwd.pem',)*2
>>> HOSTNAME = 'www.finratrace.org'
>>> 
>>> username,password='mysuer','mypass'
>>> 
>>> base64string = base64.encodestring('%s:%s' % (username, password))[:-1]
>>> 
>>> 
>>> conn = httplib.HTTPSConnection(HOSTNAME,key_file = key,cert_file = cert)
>>> conn.putrequest('GET', '/')
>>> conn.putheader("Authorization", "Basic %s" % base64string)
>>> 
>>> conn.endheaders()
>>> response = conn.getresponse()
>>> print response.status,response.reason
200 OK
>>> html= response.read()
>>> open("/tmp/kk.html",'w').write(html)
>>> 

I attached the response file from the web site.

-
By the way, I am using openssl 0.9.8 in both machines:

imac:bin isaac$ uname -a 
Darwin imac.localdomain 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 
15:16:10 PST 2011; root:xnu-1504.9.37~1/RELEASE_X86_64 x86_64
imac:bin isaac$ openssl version
OpenSSL 0.9.8l 5 Nov 2009


- - - - - - - - - - - - - -

Redhat has two  openssl flavors:

[opentrails@redhat5 ~]$ openssl version
OpenSSL 0.9.8b 04 May 2006
[opentrails@redhat5 ~]$ /usr/local/ssl/bin/openssl version
OpenSSL 0.9.8p 16 Nov 2010

-

In case it might help, this was working with MAC OS X 10.4 with PPC. It started 
to fail when I upgraded to an intel iMac with OSX 10.6. I do not know if it has 
something to do with the 64 bits kernel.

--
Added file: http://bugs.python.org/file21492/kk.html

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11728] mbox parser incorrect behaviour

[valera]

valera  added the comment:

On Thu, 31 Mar 2011 14:13:50 +
"R. David Murray"  wrote:

> 
> R. David Murray  added the comment:
> 
> All the references I could find talk about triggering the match
> without the proceeding newline.  That is, it is not certain that a
> blank line will precede the 'From ' header, and the typical quoting
> rules for mbox format call for any 'From ' at the start of a line
> (whether preceded by a blank line or not) to be quoted.  This might
> have something to do with the fact that otherwise you have to special
> case the first line of the mbox, but I don't really know.
> 
> What tool are you using that is producing the unquoted 'From ' lines
> in your mbox?  I know there are variants on the mbox format, so if
> one of them has the format you propose, this would become a feature
> request to support that variant mbox format.
> 
> --
> nosy: +r.david.murray
> 

Hello, David !

This is  an email from netcraft mailing list - the host which accepted
it is running sendmail  with some antivirus software  on top -
mimedefang + spamassassin from what I know.
Could be tat something is broken in that chain, I've spotted the error
when I was writing the script for mailbox --> maildir conversion,
while migrating this server.
So I had to inherit mailbox.mbox  and  fix as I need, I'll investigate
further what lead to such behaviour. 
Nevertheless, here is snippet from rfc4155 -
In order to improve interoperability among messaging systems, this
 memo defines a "default" mbox database format, which MUST be
 supported by all implementations that claim to be compliant with this
 specification.

 The "default" mbox database format uses a linear sequence of Internet
 messages, with each message being immediately prefaced by a separator
 line, and being terminated by an empty line.

---
So I think  assuming that there should be  an empty line before
"From " separator line is fine  (for the second email and further) and
would help to deal with all kinds of mbox  mailboxes, fix is rather
trivial.

Best regards,
Valery Masiutsin

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11393] Integrate faulthandler module into Python 3.3

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 61626c3f3a54 by Victor Stinner in branch 'default':
Issue #11393: get more information on assertion error (test_faulthandler)
http://hg.python.org/cpython/rev/61626c3f3a54

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11393] Integrate faulthandler module into Python 3.3

[STINNER Victor]

STINNER Victor  added the comment:

Other failures on "x86 XP-4 3.x":
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4308

==
FAIL: test_dump_tracebacks_later (test.test_faulthandler.FaultHandlerTests)
--
Traceback (most recent call last):
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py",
 line 404, in test_dump_tracebacks_later
self.check_dump_tracebacks_later()
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py",
 line 401, in check_dump_tracebacks_later
self._check_dump_tracebacks_later(repeat, cancel, None)
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py",
 line 390, in _check_dump_tracebacks_later
self.assertRegex(trace, '^%s$' % regex)
AssertionError: Regex didn't match: '^^Thread 0x[0-9a-f]+:\n  File 
"\\", line 7 in func\\n  File "\\", line 30 in 
\\$$' not found in 'Thread 0x07cc:\n  File "", line 7 in 
func\n  File "", line 30 in \nTraceback (most recent call 
last):\n  File "", line 30, in \n  File "", line 11, in 
func\nAssertionError'

==
FAIL: test_dump_tracebacks_later_file (test.test_faulthandler.FaultHandlerTests)
--
Traceback (most recent call last):
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py",
 line 413, in test_dump_tracebacks_later_file
self.check_dump_tracebacks_later(file=True)
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py",
 line 399, in check_dump_tracebacks_later
self._check_dump_tracebacks_later(repeat, cancel, filename)
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py",
 line 391, in _check_dump_tracebacks_later
self.assertEqual(exitcode, 0)
AssertionError: 1 != 0

==
FAIL: test_dump_tracebacks_later_repeat 
(test.test_faulthandler.FaultHandlerTests)
--
Traceback (most recent call last):
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py",
 line 407, in test_dump_tracebacks_later_repeat
self.check_dump_tracebacks_later(repeat=True)
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py",
 line 401, in check_dump_tracebacks_later
self._check_dump_tracebacks_later(repeat, cancel, None)
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py",
 line 390, in _check_dump_tracebacks_later
self.assertRegex(trace, '^%s$' % regex)
AssertionError: Regex didn't match: '^^Thread 0x[0-9a-f]+:\n  File 
"\\", line 7 in func\\n  File "\\", line 30 in 
\\\nThread 0x[0-9a-f]+:\n  File "\\", line 7 in func\\n  
File "\\", line 30 in \\$$' not found in 'Thread 
0x0fd8:\n  File "", line 7 in func\n  File "", line 30 in 
\nThread 0x0fd8:\n  File "", line 7 in func\n  File 
"", line 30 in \nTraceback (most recent call last):\n  File 
"", line 30, in \n  File "", line 11, in 
func\nAssertionError'

==
FAIL: test_dump_tracebacks_later_repeat_cancel 
(test.test_faulthandler.FaultHandlerTests)
--
Traceback (most recent call last):
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py",
 line 410, in test_dump_tracebacks_later_repeat_cancel
self.check_dump_tracebacks_later(repeat=True, cancel=True)
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py",
 line 401, in check_dump_tracebacks_later
self._check_dump_tracebacks_later(repeat, cancel, None)
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py",
 line 390, in _check_dump_tracebacks_later
self.assertRegex(trace, '^%s$' % regex)
AssertionError: Regex didn't match: '^^Thread 0x[0-9a-f]+:\n  File 
"\\", line 7 in func\\n  File "\\", line 30 in 
\\\nThread 0x[0-9a-f]+:\n  File "\\", line 7 in func\\n  
File "\\", line 30 in \\$$' not found in 'Thread 
0x082c:\n  File "", line 7 in func\n  File "", line 30 in 
\nThread 0x082c:\n  File "", line 7 in func\n  File 
"", line 30 in \nTraceback (most recent call last):\n  File 
"", line 30, in \n  File "", line 11, in 
func\nAssertionError'


The 3 assertion errors mean that time.sleep(pause) takes less than pause 
seconds. 61626c3f3a54 adds more information about these failure.

test_dump_tracebacks_later_file() failure is the same than the PPC Leopard 
failure.

--

__

[issue6498] Py_Main() does not return on SystemExit

[Éric Araujo]

Changes by Éric Araujo :


--
versions: +Python 2.7 -Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11729] libffi assembler relocation check is not robust, fails with clang

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
nosy: +brett.cannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10050] urllib.request still has old 2.x urllib primitives

[Éric Araujo]

Éric Araujo  added the comment:

Feel free to create them and set orsenthil as assignee.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6087] distutils.sysconfig.get_python_lib gives surprising result when used with a Python build

[Éric Araujo]

Éric Araujo  added the comment:

I’m not sure yet whether this is a bug or a new feature, but when python runs 
from an uninstalled build, I would like paths to refer to the source directory, 
not the default configure prefix.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10645] Remove egg-info files in stdlib

[Éric Araujo]

Éric Araujo  added the comment:

Yes, I only target 3.3.

--
assignee: tarek -> eric.araujo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11725] httplib and urllib2 failed ssl connection httplib.BadStatusLine

[Ned Deily]

Ned Deily  added the comment:

This appears to be a bug in the versions of the Apple-supplied openssl libs 
supplied in OS X 10.5 (0.9.7l) and 10.6 (0.9.8l).  You can see the same results 
using the openssl test client:

   $ openssl s_client -connect www.finratrace.org:443

With the Apple-supplied versions in 10.5 and 10.6, it hangs. With a newer 
MacPorts-installed openssl (I have a 1.0.0d), the openssl s_client exits after 
the error. I verified that the urllib.request in the MacPorts python3.2 which 
is linked with the newer openssl also correctly does not hang.

--
nosy: +ned.deily
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: resource usage -> behavior
versions: +Python 3.1, Python 3.2 -Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11731] Simplify email API via 'policy' objects

[R. David Murray]

New submission from R. David Murray :

As part of the email6 design, the email-sig came up with the idea of 
simplifying the current email API by introducing the concept of "policy 
objects".  A policy object is an object that hold various parameters and 
methods that can be used to control the behavior of the email package.  Thus, 
instead of having 'maxheaderlen', '_mangle_from', 'unixfrom', linesep, etc, etc 
options, you have a policy object that holds settings for these options that 
are applicable to a particular domain.  Thus an 'SMTP' policy would have a 
maxheaderlen of 76, a linesep of \r\n, and _mangle_from and unixfrom false, 
while mbox would have linesep \n and _mangle_from and unixfrom True.  HTTP 
would be like SMTP, but with maxheaderlen 0 (unlimited).

The policy is passed to the parser and/or the generator construtor to control 
how input is interpreted and how output is generated.  By encapsulating the 
details into objects related to clearly defined problem domains, we make it 
much simpler to use the email package both within a domain and for translating 
messages between domains.

Originally we saw the policy object as fundamental to the whole email6 design, 
but it has become clear that it is actually a relatively independent piece, and 
by itself much smaller than the parser and generator changes required for the 
full email6 implementation.

Therefore I'm starting the email6 development with the policy object piece as a 
standalone proposal.  I'd like to see this piece get reviewed and committed 
early in the process so I can use it as an underpinning for the further work.

I've set up a feature repo for email6 at features/email6.  I've pushed the 
framework (the policy object and its docs, with a selection of the options I 
intend to implement documented) and several integration updates 
(raise_on_defect, linesep, must_be_7bit).  I thought I'd post this issue now, 
with the link to the repo, so people can give me early feedback if they wish.

Ultimately I would like to deprecate the constructor arguments that are 
subsumed by the policy object settings.

--
assignee: r.david.murray
hgrepos: 15
messages: 132694
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Simplify email API via 'policy' objects
type: feature request
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2736] datetime needs an "epoch" method

[Ka-Ping Yee]

Ka-Ping Yee  added the comment:

I am extremely disappointed by what has happened here.

We are talking about a very simple method that everybody needs, and that has 
been reimplemented over and over again.  I have been frustrated countless times 
by the lack of a utctotimestamp() method.  I have watched beginners and 
experienced programmers alike suffer over and over again for the lack of this 
method, and spend hours trying to figure out why Python doesn't have it and how 
it should be spelled in Python.

The discussion here has been stuck on assumptions that the method must meet all 
of the following ideals:

  1. It must produce a value that is easy to compute with
  2. It must have perfect precision in representing microseconds, forever
  3. It must make an exact round-trip for any possible input
  4. It must let users use whatever epoch they want

These ideals cannot all be met simultaneously and perfectly.  The correct thing 
to do as an engineer is to choose a practical compromise and document the 
decision.

The compromise that almost everyone chooses (because it is useful, convenient, 
has microsecond precision at least until the year 2100, and millisecond 
precision is frequently sufficient) is to use a floating-point number with an 
epoch of 1970-01-01.  Floating-point seconds can be easily subtracted, added, 
serialized, and deserialized, and are a primitive data type in nearly every 
language and database.  They are unmatched in ease of use.  So everyone wastes 
time searching for the answer and figuring out how to write:

import calendar
calendar.timegm(dt.utctimetuple()) + dt.microsecond * 1e-6

We should use this as the definition of datetime.utctotimestamp(), document its 
limitations, and be done with it.

Instead, this essential and useful method has now been held up for almost three 
YEARS by an inability to accept a simple engineering decision.  Unbelievable.

--
nosy: +ping

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10632] multiprocessing generates a fatal error

[Brian Quinlan]

Brian Quinlan  added the comment:

Filing a new bug might have been a mistake. Once the investigation in issue 
10517 isolated the failure as being in a different module, I thought it best to 
file a new bug with a minimal repro case.

Fill free to cleanup.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2736] datetime needs an "epoch" method

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Thu, Mar 31, 2011 at 2:52 PM, Ka-Ping Yee  wrote:
..
> I am extremely disappointed by what has happened here.
>

What exactly are you disappointed about?  As far as I can tell, the
feature request has not been rejected, just no one has come up with a
satisfactory solution.   The issue is open and patches are welcome.

> We are talking about a very simple method that everybody needs, and that has 
> been
> reimplemented over and over again.  I have been frustrated countless times by 
> the lack of
> a utctotimestamp() method.

This is not what this issue has been about so far.  It was about local
time to timestamp.  In py3k,  utctotimestamp() is easy:

EPOCH = datetime(1970, 1, 1)
def utctotimestamp(dt) :
  return (dt - EPOCH).total_seconds()

>  I have watched beginners and experienced programmers alike suffer over and 
> over
> again for the lack of this method, and spend hours trying to figure out why 
> Python
> doesn't have it and how it should be spelled in Python.
>

These "beginners and experienced programmers" may want to reconsider
using floating point numbers to store high precision timestamps.  I
know that some OSes made the same unfortunate choice in system APIs,
but it does not make this choice any better.   I can make a long list
of why this is a bad choice, but I'll just mention that the precision
of your timestamp varies from year to year and the program that works
fine today may mysteriously fail in 5 years when nobody is around who
can fix it anymore.

> The discussion here has been stuck on assumptions that the method must meet
> all of the following ideals:
>
>  1. It must produce a value that is easy to compute with
>  2. It must have perfect precision in representing microseconds, forever
>  3. It must make an exact round-trip for any possible input
>  4. It must let users use whatever epoch they want
>

No it was actually stuck because of the inability to reliably obtain
the system UTC offset for historical times.  This is a solvable
problem, but the patches proposed so far did not solve it correctly.
On top of this,  there is an issue of datetime.fromtimestamp() not
being invertible in the presence of DST shifts, so
datetime.totimestamp() is ambiguous for some datetime values.

> These ideals cannot all be met simultaneously and perfectly.  The correct 
> thing to
> do as an engineer is to choose a practical compromise and document the 
> decision.
>
> The compromise that almost everyone chooses (because it is useful, 
> convenient, has
> microsecond precision at least until the year 2100, and millisecond precision 
> is frequently
> sufficient) is to use a floating-point number with an epoch of 1970-01-01.  
> Floating-point
> seconds can be easily subtracted, added, serialized, and deserialized, and 
> are a primitive
> data type in nearly every language and database.

Those who need to do arithmetics on time values more often deal with
durations rather than points in time.   An arbitrary epoch around
current time is often more appropriate for timeseries analytics than
Unix epoch.

>  They are unmatched in ease of use.

Compared to what?  I find integers much more suitable for representing
points in time than floats.  Yes, in some languages you have to deal
with 32-bit int overflow issues if you want to be able to deal with
durations of over 100 years expressed in microseconds, but these days
64-bit integers are almost universally available.

>  So everyone wastes time searching for the answer and figuring out how to 
> write:
>
>    import calendar
>    calendar.timegm(dt.utctimetuple()) + dt.microsecond * 1e-6
>

And this is the wrong answer.  Someone else using (dt -
EPOCH).total_seconds() may get a slightly different result.  Some may
argue that given that it is not obvious what expression to use, we
need to provide a function.  However, we already provided
timedelta.total_seconds() that hides the floating point details.  In
my opinion, even adding total_seconds() was a mistake and x /
timedelta(seconds=1) is just as short and more explicit than
x.total_seconds().

I think the best we can do is to expand datetime.utcfromtimestamp()
documentation to explain that it is equivalent to

def utcfromtimestamp(s):
 return EPOCH + timedelta(seconds=s)

and either leave it as an exercise to the reader to solve
utcfromtimestamp(s) = dt for s or spell out

def utctotimestamp(dt) :
  return (dt - EPOCH) / timedelta(seconds=1)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11393] Integrate faulthandler module into Python 3.3

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 69f58be4688a by Victor Stinner in branch 'default':
Issue #11393: test_faulthandler is more tolerant on inaccurate time
http://hg.python.org/cpython/rev/69f58be4688a

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11732] Skip decorator for tests requiring manual intervention on Windows

[Brian Curtin]

New submission from Brian Curtin :

Attached is a patch which adds skip_unless_unattended, which ideally would be 
used with at least test_faulthandler when running on Windows.

Running the tests on a Windows desktop results in the user having to click 
through Windows Error Reporting dialogs in order to continue. Build slaves 
disable or handle WER dialogs in order to continue running without manual 
intervention. The patch looks in the common registry keys [0,1] to see the 
status of WER and skips tests when it finds that WER is enabled and would 
require user intervention.

We may want to additionally hook this up to a regrtest command line parameter 
to override the registry setting.

Maybe there's a better name for the decorator - I'm not stuck with what I 
suggested. I consider build slaves as running in "unattended" mode as opposed 
to a human kicking off the tests.


[0] http://www.spyany.com/program/registry-disable-error-reporting.htm
[1] http://msdn.microsoft.com/en-us/library/bb513638(v=vs.85).aspx

--
assignee: brian.curtin
components: Tests, Windows
files: unattended_decorator.diff
keywords: patch
messages: 132699
nosy: brian.curtin
priority: normal
severity: normal
stage: patch review
status: open
title: Skip decorator for tests requiring manual intervention on Windows
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file21493/unattended_decorator.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11732] Skip decorator for tests requiring manual intervention on Windows

[Brian Curtin]

Brian Curtin  added the comment:

Attached is an example of how this might be used with 
Lib/test/test_faulthandler.py

--
nosy: +haypo, loewis
Added file: http://bugs.python.org/file21494/faulthandler_example.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11714] threading.Semaphore does not use try...finally

[Thomas Rachel]

Thomas Rachel  added the comment:

Oops, sorry. I have re-made it; it is to be applied to 69f58be4688a.

The original one was made against the respective file of my distribution which 
contains Python 2.6. It can be applied to (at least) 787b969d37f0, a fact which 
might help backporting it to 2.x, if wanted.

--
Added file: http://bugs.python.org/file21495/threading.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11393] Integrate faulthandler module into Python 3.3

[STINNER Victor]

STINNER Victor  added the comment:

Cool, 69f58be4688a fixed all failures (all related to dump_backtraces_later()) 
on "x86 XP-4 3.x". So "PPC Leopard" should also be fixed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11714] threading.Semaphore does not use try...finally

[Thomas Rachel]

Thomas Rachel  added the comment:

Here is another patch which fits to 2.7, if desired.

--
Added file: http://bugs.python.org/file21496/threading.b36cb4602e21.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11732] Skip decorator for tests requiring manual intervention on Windows

[STINNER Victor]

STINNER Victor  added the comment:

Ah yes, I have also issues with the Windows fault handler (the popup). I 
disabled this popup manually in my Windows XP box.

Instead of skipping the test, I prefer to disable temporary the popup by 
setting the right registry key (and then restore the previous value or delete 
the key).

faulthandler causes fatal errors, but test_capi does also test a crash (I don't 
know which test exactly). I always have to click on the popup to continue to 
execute the test suite :-(

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4657] Doctest gets line numbers wrongs with <> in name

[Nick Coghlan]

Nick Coghlan  added the comment:

Note that this appears to have been fixed already in the 3.x series (I haven't 
investigated the differences to see what makes this a 2.x only problem)

--
versions: +Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11732] Skip decorator for tests requiring manual intervention on Windows

[STINNER Victor]

STINNER Victor  added the comment:

Ubuntu has also a fault handler: Apport.
https://wiki.ubuntu.com/Apport

Fedora has abrt.
https://fedorahosted.org/abrt/wiki
http://fedoraproject.org/wiki/Features/ABRT

If we should to disable the Windows fault handler, we may also disable these 
tools.

test_faulthandler already disable another fault handler: it disables the 
creation of core files. prepare_subprocess() calls setrlimit(RLIMIT_CORE, (0, 
0)).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11723] No proper support for mingw64 - patch to add

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Sorry, I honestly wasn't sure whether this is a typo, or whether mings64 is 
something I hadn't heard of (for the record, I'm not sure what mingw64 really 
is, either).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11733] Implement a `Counter.elements_count` method

[Ram Rachum]

New submission from Ram Rachum :

I suggest a `Counter.elements_count()` method should be added, that would give 
the same answer as `sum(counter.itervalues())`.

--
components: Library (Lib)
messages: 132708
nosy: cool-RR, rhettinger
priority: normal
severity: normal
status: open
type: feature request
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8668] add a 'develop' command

[Éric Araujo]

Éric Araujo  added the comment:

See also 
http://groups.google.com/group/the-fellowship-of-the-packaging/browse_thread/thread/10506b8326a7b047

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11733] Implement a `Counter.elements_count` method

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Thanks for the feature request.  Py3.3 is a long ways away, so I'll leave this 
open for a while.

Comments in favor:
* Precedent with Smalltalk bags that know their total length

Comments against:
* sum(c.values()) is trivial to write
* fattening the API makes it harder to learn and remember

--
priority: normal -> low

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11733] Implement a `Counter.elements_count` method

[STINNER Victor]

STINNER Victor  added the comment:

It would be interesting to have Counter.elements_count() if it has a complexity 
of O(1): if the collections maintains a total (in a private attribute).

Otherwise, I think that sum(c.values()) is enough and can be documented as an 
example in the Counter doc.

--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11733] Implement a `Counter.elements_count` method

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> It would be interesting to have Counter.elements_count() 
> if it has a complexity of O(1): if the collections 
> maintains a total (in a private attribute).

I agree that it would be interesting; however, it would be an implementation 
disaster.  We would have to override (and slow-down) every mutating method in 
order to maintain the invariant.  And as a dict subclass, any C module using 
PyDict_Setitem() would bypass those methods and still break the invariant no 
matter what we do.

The Counter tool was designed in an open fashion (a simple, fully exposed 
dictionary with a few handy methods for counting).  In that regard, it is much 
different and more flexible than a traditional Bag class that maintains its 
data privately.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7796] No way to find out if an object is an instance of a namedtuple

[Jan Kaliszewski]

Jan Kaliszewski  added the comment:

PS. For the record: the final recipe is here: 
http://code.activestate.com/recipes/577629-namedtupleabc-abstract-base-class-mix-in-for-named/

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11715] Building Python on multiarch Debian and Ubuntu

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Python 2.5 is not open for bug fixes anymore, so this can't be applied to this 
branch. I suggest that Python 2.6 is closed for bug fixes as well.

--
nosy: +loewis

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11722] mingw64 does not link when building extensions

[Ralf Schmitt]

Ralf Schmitt  added the comment:

pyconfig.h defines SIZEOF_SIZE_T depending on the preprocessor symbol MS_WIN64. 
The patch in #4709 would fix that.

--
nosy: +schmir

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7796] No way to find out if an object is an instance of a namedtuple

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 7aa3f1f7ac94 by Raymond Hettinger in branch '3.2':
Issue #7796: Add link to Jan Kaliszewski's alternate constructor and ABC for 
named tuples.
http://hg.python.org/cpython/rev/7aa3f1f7ac94

New changeset 330d3482cad8 by Raymond Hettinger in branch 'default':
Issue #7796: Add link to Jan Kaliszewski's alternate constructor and ABC for 
named tuples.
http://hg.python.org/cpython/rev/330d3482cad8

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11715] Building Python on multiarch Debian and Ubuntu

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

On Mar 31, 2011, at 10:08 PM, Martin v. Löwis wrote:

>Martin v. Löwis  added the comment:
>
>Python 2.5 is not open for bug fixes anymore, so this can't be applied to
>this branch. I suggest that Python 2.6 is closed for bug fixes as well.

Although I'd still like to apply it to 2.5, I defer to you as RM.  However,
if/when I ever need to do a 2.6 release I'll need to build and test it and I
don't want to have to keep an old version of Ubuntu around to do that.

So how about if I apply it to 2.6, 2.7, 3.1 - 3.3?

(I've also addressed the comment you made in the review.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11715] Building Python on multiarch Debian and Ubuntu

[Martin v . Löwis]

Martin v. Löwis  added the comment:

If Ubuntu stops supporting to build old Python releases, I rather consider this 
a serious bug in Debian, not one in Python.

If the issue is merely that certain extension modules fail to build, I see no 
real reason to do anything about it. Users affected by this issue can still 
edit Modules/Setup.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11733] Implement a `Counter.elements_count` method

[Matthew Barnett]

Matthew Barnett  added the comment:

The name isn't meaningful to me. My preference would be for something like 
"total_count".

--
nosy: +mrabarnett

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11393] Integrate faulthandler module into Python 3.3

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 8b1341d51fe6 by Victor Stinner in branch 'default':
Issue #11393: Fix faulthandler_thread(): release cancel lock before join lock
http://hg.python.org/cpython/rev/8b1341d51fe6

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11393] Integrate faulthandler module into Python 3.3

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> New changeset 8b1341d51fe6 by Victor Stinner in branch 'default':
> Issue #11393: Fix faulthandler_thread(): release cancel lock before join lock
> http://hg.python.org/cpython/rev/8b1341d51fe6

This is wrong, it should always be released, not only when explicitly
cancelled.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11734] Add half-float (16-bit) support to struct module

[Eli Stevens]

New submission from Eli Stevens :

Numpy 1.6.0 adds support for a half-float (16-bit) data type, but
cannot currently export a buffer interface to the data since neither PEP 3118 
nor the struct module (referenced by PEP 3118) support the data type.

I am proposing that the struct module be extended to support half floats, and 
will be providing a patch that implements that behavior.

The current numpy implementation (1.6.0b1) uses the 'e' character to indicate 
half floats; I don't have a vested interest in what character is used.  If 
consensus between CPython and numpy is reached for using a different character, 
I will update my patches (but I don't plan on participating in the bike 
shedding prior to that point).

For reference:

python-ideas thread:
http://mail.python.org/pipermail/python-ideas/2011-March/009650.html

numpy-discussion thread:
http://mail.scipy.org/pipermail/numpy-discussion/2011-March/055667.html

cython-user thread (less relevant to this issue specifically):
http://groups.google.com/group/cython-users/browse_thread/thread/6bf811409cdab89e

--
components: Library (Lib)
messages: 132722
nosy: Eli.Stevens
priority: normal
severity: normal
status: open
title: Add half-float (16-bit) support to struct module
type: feature request
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11393] Integrate faulthandler module into Python 3.3

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 0fb0fbd442b4 by Victor Stinner in branch 'default':
Issue #11393: New try to fix faulthandler_thread()
http://hg.python.org/cpython/rev/0fb0fbd442b4

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11393] Integrate faulthandler module into Python 3.3

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 3558eecd84f0 by Victor Stinner in branch 'default':
Issue #11393: fix usage of locks in faulthandler
http://hg.python.org/cpython/rev/3558eecd84f0

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4657] Doctest gets line numbers wrongs with <> in name

[R. David Murray]

R. David Murray  added the comment:

I have a vague memory of changing some code, in linecache I think, that 
involved anonymous names.  I might have fixed it by accident.

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11734] Add half-float (16-bit) support to struct module

[Eli Stevens]

Eli Stevens  added the comment:

Initial patch; tests pass.  A couple notes:

- I manually excised some commented changes to structmodule.{h,c} from the 
.patch; once I get a determination on if those files need to be updated or not 
I will discard the changes or implement what needs to be done there.  Hopefully 
I didn't damage the patch while editing.

- The code in _PyFloat_Pack2 and _PyFloat_Unpack2 is adapted from the numpy 
code in 
https://github.com/numpy/numpy/blob/master/numpy/core/src/npymath/halffloat.c . 
 This means that it is BSD licensed; I'm presuming that is acceptable for 
inclusion in CPython.  If not, I'll try a clean-room implementation.

--
keywords: +patch
Added file: http://bugs.python.org/file21497/cpython-struct-float16-v1.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11735] Python Crash on strftime with %f

[mangeletti]

New submission from mangeletti :

Win XP 32 bit 2.7.4

>>> import time
>>> time.strftime('%m/%d/%Y %H:%M:%S')
'03/31/2011 20:04:52'
>>> # ^^^ works fine
>>> time.strftime('%m/%d/%Y %H:%M:%S:%f')  # Oops, forgot `time.strftime` 
>>> doesn't provide microseconds

Python crashes

Error Signature (sorry, didn't get full log):

AppName: python.exe  AppVer: 0.0.0.0 ModName: msvcr90.dll
ModVer: 9.0.30729.4148   Offset: 0005bbac


I've never patched Python, but I might try to give it a whirl.

--
components: Library (Lib)
messages: 132727
nosy: mangeletti
priority: normal
severity: normal
status: open
title: Python Crash on strftime with %f
type: crash
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11735] Python Crash on strftime with %f

[Santoso Wijaya]

Santoso Wijaya  added the comment:

Hm, I can't reproduce this on darwin:

Python 2.7.1 (r271:86832, Jan 26 2011, 19:17:30) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.strftime('%m/%d/%Y %H:%M:%S:%f')
'03/31/2011 23:11:59:f'

--
nosy: +santa4nt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6457] subprocess.Popen.communicate can lose data from output/error streams when broken input pipe occures

[Ross Lagerwall]

Ross Lagerwall  added the comment:

Closing as duplicate of #10963. See #10963 for more discussion.

--
nosy: +rosslagerwall
resolution:  -> duplicate
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10963] "subprocess" can raise OSError (EPIPE) when communicating with short-lived processes

[Ross Lagerwall]

Ross Lagerwall  added the comment:

Marked #6457 as a duplicate. See #6457 for more discussion.

--
nosy: +Yaniv.Aknin, amaury.forgeotdarc, dwalczak, mcrute

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com