date:20110629

[issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer

2011-06-29 Thread Nick Coghlan


Nick Coghlan ncogh...@gmail.com added the comment:

Marking the PEP 380 implementation as a dependency, as I expect it to be easier 
to update this patch to cope with those changes than it would be the other way 
around.

--
dependencies: +PEP 380 reference implementation for 3.3

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

[issue12417] Inappropriate copyright on profile files

2011-06-29 Thread Barry A. Warsaw


Barry A. Warsaw ba...@python.org added the comment:

Thanks Benjamin!

--

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

[issue12352] multiprocessing.Value() hangs

2011-06-29 Thread Charles-François Natali


Charles-François Natali neolo...@free.fr added the comment:

 Nice work! I also think heap_gc_deadlock_lockless.diff is good, except for 
 Victor's reservation: is it deliberate that you reversed the following two 
 statements in _free_pending_blocks(), compared to the code in free()?

 +            self._free(block)
 +            self._allocated_blocks.remove(block)


No, it's not deliberate (it shouldn't have any impact since they're
protected by the mutex though).
As for calling _free_pending_blocks() a second time, I'm not sure
that's necessary, I find the code simpler and cleaner that way.
I'll provide a new patch in a couple days (no access to my development
box right now).

--

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

[issue12303] expose sigwaitinfo() and sigtimedwait() in the signal module

2011-06-29 Thread Charles-François Natali


Charles-François Natali neolo...@free.fr added the comment:

 Oh, the problem is that sigwait() behaviour changes after a fork: it is 
 interrupted if an unexpected signal is received, but the signal handler is 
 not called. It behaves correctly (the signal handler is called) without the 
 fork.


Reminds me of http://bugs.python.org/issue8407#msg138066

But I think we could just remove this test: honestly, I'm not sure
that checking the behavior in case of delivery of an unblocked signal
is really useful, especially since the behavior is not clearly
defined, see POSIX man page:

The sigwaitinfo() and sigtimedwait() functions may fail if:

[EINTR]
The wait was interrupted by an unblocked, caught signal. It will be
documented in system documentation whether this error will cause these
functions to fail.


may fail [...] It will be documented in system documentation

--

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

[issue12303] expose sigwaitinfo() and sigtimedwait() in the signal module

2011-06-29 Thread Roundup Robot


Roundup Robot devnull@devnull added the comment:

New changeset 00ca0c2c7bc0 by Victor Stinner in branch 'default':
Issue #12303: run sig*wait*() tests in a subprocesss
http://hg.python.org/cpython/rev/00ca0c2c7bc0

--

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

[issue12303] expose sigwaitinfo() and sigtimedwait() in the signal module

2011-06-29 Thread STINNER Victor


STINNER Victor victor.stin...@haypocalc.com added the comment:

 But I think we could just remove this test

The test pass on Linux and FreeBSD 6 using a subprocess. I commited my patch to 
replace fork() by subprocess, let's see how it works on buildbots.

--

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

[issue12439] BaseHTTPServer's send_reponse adds extra \r\n when using HTTPMessage in input

2011-06-29 Thread Yoav Weiss


New submission from Yoav Weiss yoav.weiss...@gmail.com:

I'm using BaseHTTPServer's send_response (from within a class that inherits 
BaseHTTPRequestHandler) with the following:

self.send_response(response.code, response.headers)
self.end_headers()
self.wfile.write(content)
self.wfile.flush()
When response is a httplib's HTTPResponse object, and its headers inherits from 
rfc822.Message.

What I see is that message is printed as is, including all the headers trailing 
\r\n, after which the send_response method (BaseHTTPServer.py:381) adds 
another \r\n.
Then send_response adds the Server and Date headers.
Since the headers before Server  Date include \r\n\r\n, Date  server are 
considered by the browser as the content.

Am I misusing BaseHTTPServer? If not, this is a bug and \r\n should be 
removed from line 381, or added only after a check that shows they are not 
already there at the headers end, or in case there are no input headers.

--
components: Library (Lib)
messages: 139401
nosy: Yoav.Weiss
priority: normal
severity: normal
status: open
title: BaseHTTPServer's send_reponse adds extra \r\n when using HTTPMessage 
in input
type: behavior
versions: Python 2.6

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

[issue7117] Backport py3k float repr to trunk

2011-06-29 Thread Michael Foord

Michael Foord mich...@voidspace.org.uk added the comment:

Wondered if you guys had heard of some recent advances in the state of the art
in this field. I'm sure you have, but thought I'd link it here anywhere.

Quote taken from this article (which links to relevant papers):

http://www.serpentine.com/blog/2011/06/29/here-be-dragons-advances-in-problems-you-didnt-even-know-you-had/

In 2010, Florian Loitsch published a wonderful paper in PLDI, Printing
floating-point numbers quickly and accurately with integers, which represents
the biggest step in this field in 20 years: he mostly figured out how to use
machine integers to perform accurate rendering! Why do I say mostly? Because
although Loitsch's Grisu3 algorithm is very fast, it gives up on about 0.5%
of numbers, in which case you have to fall back to Dragon4 or a derivative.

If you're a language runtime author, the Grisu algorithms are a big deal:
Grisu3 is about 5 times faster than the algorithm used by printf in GNU libc,
for instance. A few language implementors have already taken note: Google hired
Loitsch, and the Grisu family acts as the default rendering algorithms in both
the V8 and Mozilla Javascript engines (replacing David Gay's 17-year-old dtoa
code). Loitsch has kindly released implementations of his Grisu algorithms as a
library named double-conversion.

--
nosy: +michael.foord

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

78 matches

Mail list logo