Antoine Pitrou added the comment:
Should be fixed.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> pending
___
Python tracker
<http://bugs.python.or
Changes by Antoine Pitrou :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
There's a failure on certain locales that Victor, I believe, is currently
investigating.
--
status: pending -> open
___
Python tracker
<http://bugs.python.org
Antoine Pitrou added the comment:
> I think that if we were to call PyThread_set_key_value twice on the
> same key it's either an error, or we want the last version to be
> stored, not the old one.
Not necessarily. You can have several interpreters (and therefore several
threa
Antoine Pitrou added the comment:
> Is anyone working on this?
I don't think so, you could try if you are interested.
--
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
Can you check CFLAGS and friends? Also, attach of output of "configure"?
--
nosy: +dmalcolm, pitrou
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
> CFAGS and friends are not set.
How about LDFLAGS?
By the way, the build should have succeeded anyway: the "python" executable
should be at the root of your build directory.
--
___
Python t
Antoine Pitrou added the comment:
> Well, after fork, all threads have exited, so you'll be running on the
> behalf of the child process' main - and only - thread, so by
> definition you can't access other threads' thread-specific data, no?
A rather good point :)
H
Antoine Pitrou added the comment:
> > How about deleting the mapping (pthread_key_delete) and recreating it
> > from scratch, then?
>
> Sounds good.
> So the idea would be to retrieve the current thread's tstate, destroy
> the current autoTLSkey, re-create it,
New submission from Antoine Pitrou :
The SMTP_SSL doc says “If port is omitted, the standard SMTP-over-SSL port
(465) is used”, but actually port 25 is used by default. The fix is trivial:
make "default_port" a class attribute (in both SMTP and SMTP_SSL) instead of
setting it
Antoine Pitrou added the comment:
For the record, issue11927 reminds me that test_smtpnet actually has a trivial
test for SMTP-over-SSL.
--
___
Python tracker
<http://bugs.python.org/issue8
Antoine Pitrou added the comment:
So, thanks for the new patch. I tested it with my ISP's server and it works
fine!
Two remaining issues though:
- in the SMTP_SSL constructor, you must add the "context" argument at the end
of the argument list (after "timeout"),
Antoine Pitrou added the comment:
Le mardi 26 avril 2011 à 01:34 +, STINNER Victor a écrit :
> STINNER Victor added the comment:
>
> > > - Rename _PyThread_Info() to PyThread_GetInfo() (consistent name with
> > > PyFloat_GetInfo() and PyLong_GetInfo())
> >
Antoine Pitrou added the comment:
> So how about a --with-dlmalloc=path/to/dlmalloc.c?
Can't you just add dlmalloc to LDFLAGS or something? Or would the
default malloc still be selected?
> This is
> similar in how python uses e.g. openssl to provide optional extra
> function
Changes by Antoine Pitrou :
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue11935>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> Antoine, I wonder if we can restore PyThread_set_key_value to behave
> like a canonical TLS api function (always setting) but fix the cases
> that want to "set if it has not already been set" like the cases you
> mention.
> It is ver
Antoine Pitrou added the comment:
> > You could add a new _PyGILState_ReInit() function and call it from
> > PyOS_AfterFork() or PyEval_ReInitThreads().
>
> See attached tls_reinit.diff patch.
Thank you. I like this patch, except that _PyGILState_ReInit() should be
declared
Antoine Pitrou added the comment:
> > Thank you. I like this patch, except that _PyGILState_ReInit() should be
> > declared in the appropriate .h file, not in signalmodule.c.
>
> I asked myself this question when writing the patch: what's the
> convention regardi
Changes by Antoine Pitrou :
--
dependencies: -multiprocessing generates a fatal error
stage: -> commit review
superseder: -> multiprocessing generates a fatal error
versions: +Python 2.7, Python 3.1, Python 3.3
___
Python tracker
Changes by Antoine Pitrou :
--
superseder: -> multiprocessing generates a fatal error
___
Python tracker
<http://bugs.python.org/issue10632>
___
___
Python-
Changes by Antoine Pitrou :
--
superseder: multiprocessing generates a fatal error ->
___
Python tracker
<http://bugs.python.org/issue10517>
___
___
Python-
Changes by Antoine Pitrou :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue11937>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
It should be fixed now! Thank you.
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions: -Python 3.1
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
Victor, the fix needs to go into 3.2 as well.
--
assignee: -> haypo
status: closed -> open
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
Hello,
> This patch (is_ipv6_enabled.diff) must be applied before
> ssl_ipv6.diff.
is_ipv6_enabled.diff is fine.
As for ssl_ipv6.diff, it fails on certificate verification:
==
Changes by Antoine Pitrou :
--
nosy: +debatem1, pitrou
stage: -> patch review
type: -> feature request
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
Committed, thank you!
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Antoine Pitrou :
Apparently not all Windows socket error codes (see
http://msdn.microsoft.com/en-us/library/ms740668%28v=vs.85%29.aspx) are mapped
in the errno module.
For example, a buildbot recently got a 11004 error (see
http://www.python.org/dev/buildbot/all/builders
Changes by Antoine Pitrou :
--
nosy: +brian.curtin, tim.golden
___
Python tracker
<http://bugs.python.org/issue11953>
___
___
Python-bugs-list mailing list
Unsub
Antoine Pitrou added the comment:
Actually, it was raised by getaddrinfo(), so should perhaps belong in the
socket module instead.
--
___
Python tracker
<http://bugs.python.org/issue11
Antoine Pitrou added the comment:
> Since I want PyMem_MALLOC to call dlmalloc, I would need to export the
> "malloc" symbol from libpython so that Python extensions could use it
> when calling PyMem_MALLOC, but that would impact all malloc calls in
> applications which em
Antoine Pitrou added the comment:
> Yes, I was probably not clear:
> When --with-dlmalloc is activated, PyMem_MALLOC/PyMem_Malloc will call
> dlmalloc, PyMem_REALLOC/PyMem_Realloc will call dlrealloc and
> PyMem_FREE/PyMem_Free will call dlfree.
>
> While calls to malloc/fre
Antoine Pitrou added the comment:
Senthil, Windows buildbots on 3.1, 3.2 and 3.x show test failures.
See e.g.
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.1/builds/1780/steps/test/logs/stdio
--
assignee: lars.gustaebel -> orsenthil
nosy: +pitrou
status: clo
Antoine Pitrou added the comment:
> For the same reason that extension modules can choose between
> PyMem_Malloc and plain malloc (or whatever else). Python has never
> forced it's malloc on extension modules why should it now?
We're talking about a platform-specific fea
Antoine Pitrou added the comment:
As noted by Martin above (he quoted the Subversion revision numbers), this was
actually fixed.
--
resolution: accepted -> fixed
stage: patch review -> committed/rejected
___
Python tracker
<http://bugs.p
Changes by Antoine Pitrou :
--
nosy: +ned.deily, ronaldoussoren
stage: -> patch review
versions: -Python 2.5, Python 2.6, Python 3.4
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
Thanks for the patch. Some preliminary comments:
- the OpenSSL functions you are using (SSL_get_srp_username etc.) don't seem
documented on openssl.org; this makes it harder to do a proper review
- no need to fill Misc/ACKS and Misc/NEWS by yourself, w
Antoine Pitrou added the comment:
Have you seen the comment on top of it? It says "Helper for popen() -- a proxy
for a file whose close waits for the process".
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
> Should we add a unit test for this as well?
True, a simple test could be added to test_smtpnet.
--
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
Thanks for the patch. Comments:
- the keyfile / certfile pair and the context parameter should be mutually
exclusive (see e.g. the POP3_SSL constructor in Lib/poplib.py)
- I don't think the remote test server used in test_imaplib supports client
certifi
Antoine Pitrou added the comment:
> Update signalfd patch.
>
> --
> Added file: http://bugs.python.org/file21856/signalfd-2.patch
- In the tests, you don't need sys.exc_info(), just
"except XXXError as e".
- In the doc, you wrote "file description&qu
Antoine Pitrou added the comment:
This is a very interesting patch, thank you.
I've tested it on Mandriva 64-bit and it indeed fixes the free() issue on the
XML workload. I see no regression on pybench, stringbench or json/pickle
benchmarks.
I guess the final patch will have to guar
Changes by Antoine Pitrou :
--
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue9971>
___
___
Python-bugs-list mailing list
Unsub
Changes by Antoine Pitrou :
--
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue10044>
___
___
Python-bugs-list mailing list
Unsub
Antoine Pitrou added the comment:
Do you want to provide a patch?
--
components: +Library (Lib) -Extension Modules
nosy: +pitrou
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3 -Python 2.6
___
Python tracker
<http://bugs.python.
Antoine Pitrou added the comment:
Your patch uses tabs for indentation. Otherwise, looks good on the principle.
--
nosy: +pitrou
stage: -> patch review
type: behavior -> feature request
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
With Python 3.3, thread_exit.py still crashes more or less randomly:
$ ./python thread_exit.py
[49205 refs]
python: Python/_warnings.c:501: setup_context: Assertion
`((PyObject*)(*filename))->ob_type))->tp_flags & ((1L<<28))) != 0)&
Antoine Pitrou added the comment:
A patch that seems to work under Linux and Windows (for 3.2/3.3).
--
nosy: +haypo
stage: -> patch review
Added file: http://bugs.python.org/file21862/finalizing.patch
___
Python tracker
<http://bugs.pyth
Antoine Pitrou added the comment:
I encountered this issue while debugging some multiprocessing code; fork()
would be called from one thread while sys.stdout was in use in another thread
(simply because of a couple of debugging statements). As a result the IO lock
would be already "take
Antoine Pitrou added the comment:
Here is a proof-of-concept patch that makes concurrent.futures able to detect
killed processes. Works only under POSIX, and needs issue11743.
I'm not sure it's a good idea to change the multiprocessing public API
(SimpleQueue.get()
Antoine Pitrou added the comment:
Actually, it came to me that if a child process exists, the queues are not
guaranteed to be a consistent state anymore (the child could have terminated in
the middle of a partial read or write). So it may be better to simply declare
the ProcessPoolExecutor
Antoine Pitrou added the comment:
Patch looks fine to me, thank you.
--
stage: -> patch review
versions: -Python 2.7, Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
> Under what circumstances do we expect a ProcessPoolExecutor child
> process to be killed outside of the control of the
> ProcessPoolExecutor?
Killed by the user, or by an automatic device (such as the Linux OOM
killer), or crashed.
> If the
Antoine Pitrou added the comment:
> > Killed by the user, or by an automatic device (such as the Linux OOM
> > killer), or crashed.
>
> Crashed would be bad - it would indicate a bug in the
> ProcessPoolExecutor code.
I meant a crash in Python itself, or any third-p
Changes by Antoine Pitrou :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
Victor pointed out that Py_Finalize() is not necessarily called in the main
Python thread. This new patch records the thread state of the finalizing
thread, and also includes a test case.
--
Added file: http://bugs.python.org/file21872/finalizing2
Antoine Pitrou added the comment:
Not specific to NaNs:
>>> min({1}, {2})
{1}
>>> min({2}, {1})
{2}
--
nosy: +pitrou
___
Python tracker
<http://bugs.
Antoine Pitrou added the comment:
Here is a patch with tests for the issue (some of which fail of course).
Do we agree that these tests are right?
--
keywords: +patch
Added file: http://bugs.python.org/file21874/forklocktests.patch
___
Python
Antoine Pitrou added the comment:
> Also, this would imply keeping track of the thread currently owning
> the lock,
Yes, we would need to keep track of the thread id and process id inside
the lock. We also need a global variable of the main thread id after
fork, and a per-lock "
Antoine Pitrou added the comment:
> - what's current_thread_id ? If it's thread_get_ident (pthread_self),
> since TID is not guaranteed to be inherited across fork, this won't
> work
Ouch, then the approach I'm proposing is probably doomed.
> And it's tru
Antoine Pitrou added the comment:
Should be fixed in 3.2 and 3.3 now. I don't really want to bother with 2.7 and
3.1 (the GIL implementation is different), but someone can backport the patch
if they want to :)
--
resolution: -> fixed
stage: patch review -> committed/reje
Antoine Pitrou added the comment:
Are you sure about "if not san and not dnsnames"? It is even more restrictive
than the currently condition. "if not dnsnames" looks like it would fit the
bill better.
Also, better if you can provide a complete patch, including additional
Antoine Pitrou added the comment:
> Making a copy of f_locals values to return a dictionary that doesn't
> hold references to the locals of the frame is not that simple
I think you misunderstood the bug report. The issue here is not that locals are
referenced from the dict, it
Antoine Pitrou added the comment:
Quick review at http://bugs.python.org/review/8407/show
--
___
Python tracker
<http://bugs.python.org/issue8407>
___
___
Pytho
Antoine Pitrou added the comment:
> As I think about this more... I'm not sure how much performance there
> is to gain here in practice. It seems like any time I'd want to use
> readinto(), it's because I want to do my own buffering, in which case
> why would I
Antoine Pitrou added the comment:
Well, ctypes is kindof unmaintained right now, and the private libffi copy
belongs to that module.
(the reason we have a libffi copy is that, IIUC, it's patched)
--
nosy: +pitrou
___
Python tracker
Changes by Antoine Pitrou :
--
nosy: +doko
___
Python tracker
<http://bugs.python.org/issue11729>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Antoine Pitrou :
Treating RuntimeError as if it could take an errno is no good:
>>> try: signal.siginterrupt(32, 12345)
... except RuntimeError as e: print(e.errno)
...
Traceback (most recent call last):
File "", line 1, in
RuntimeError: (22, 'In
Antoine Pitrou added the comment:
Do you want to propose a patch? I'm not sure any of us can test on an Android
setup.
--
nosy: +pitrou
stage: -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3
___
Python tracke
Antoine Pitrou added the comment:
Thank you for the patch. A couple of comments:
- the whole slow path (which loops calling _bufferedreader_raw_read()) should
be surrounded by calls to ENTER_BUFFERED() and LEAVE_BUFFERED()
- other things:
+if (!PyArg_ParseTuple(args, "O:rea
Antoine Pitrou added the comment:
Does this happen with a released build of OpenSSL? The Debian bug talks about
experimental.
+try:
+from _ssl import PROTOCOL_SSLv2
+OPENSSL_NO_SSL2 = False
+except ImportError:
+OPENSSL_NO_SSL2 = True
Please avoid "negative" constants.
Changes by Antoine Pitrou :
--
stage: -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issu
Changes by Antoine Pitrou :
--
nosy: +barry
priority: normal -> high
stage: test needed -> needs patch
versions: +Python 2.6
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
Patch committed in 3.2 and 3.x, thank you!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
+if (n <= 0) {
+if (written > 0 || n == 0)
+break;
+if (n == -2) {
+Py_INCREF(Py_None);
+res = Py_None;
+}
+goto end;
+}
I think the logic is
Antoine Pitrou added the comment:
I'm not sure there's any sense in trying to bend the json module into producing
other formats.
--
nosy: +pitrou, rhettinger
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
Thank you! I've tweaked the patch slightly (mostly cosmetics (*)) and committed
it to 3.3. I've left out the poplib doc changes, they could be committed
separately.
(*) 80-line character limit, calling logout() on the test server
--
Antoine Pitrou added the comment:
Le jeudi 05 mai 2011 à 18:45 +, Facundo Batista a écrit :
>
> Antoine, to see if I understood correctly... if we build the dict, and
> just return it but don't save it in the frame, this leak would be
> solved? (yes, it'd be slower
Antoine Pitrou added the comment:
> Possibly of more interest for Python is that it's no longer buildable
> without wchar_t support. While unicodeobject is pretty good at
> checking HAVE_WCHAR_H, a number of modules and even pythonrun.c
> directly use wchar_t
Antoine Pitrou added the comment:
Sounds like a reasonable request, although I don't think it's a bug fix in
itself (there are probably other places where mmap breaks the file-like
expectation).
--
nosy: +pitrou
stage: -> needs patch
type: behavior -> feature
Antoine Pitrou added the comment:
This doesn't seem to be so easy. WFMO (or WFSO) often seems to return
successfully while there's no message to read on the pipe end. Here is a sample
session (disturbing results):
>>> a, b = connection.Pipe(True)
>>> win32.WaitF
Antoine Pitrou added the comment:
Oops... It hadn't jumped at me earlier, but the patch is actually problematic
performance-wise. The reason is that it doesn't buffer data at all, so small
readintos become slower (they have to go through raw I/O every time):
$ ./python -m timeit
Antoine Pitrou added the comment:
A solution could be to use overlapped I/O on the named pipe handles.
The first poll() would call ReadFile() with a tiny value (1?) and store an
object wrapping the OVERLAPPED structure. Subsequent poll() or recv() would
re-use that structure until the
Antoine Pitrou added the comment:
Barry, 2.6?
--
nosy: +barry, benjamin.peterson
priority: normal -> release blocker
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
A solution could be to use overlapped I/O on the named pipe handles.
The first poll() would call ReadFile() with a tiny value (1?) and store an
object wrapping the OVERLAPPED structure. Subsequent poll() or recv() would
re-use that structure until the
Antoine Pitrou added the comment:
Uh, sorry for the last message (about overlapped I/O), wrong issue.
--
___
Python tracker
<http://bugs.python.org/issue9
Changes by Antoine Pitrou :
--
Removed message: http://bugs.python.org/msg135425
___
Python tracker
<http://bugs.python.org/issue9971>
___
___
Python-bugs-list m
Changes by Antoine Pitrou :
--
Removed message: http://bugs.python.org/msg135435
___
Python tracker
<http://bugs.python.org/issue9971>
___
___
Python-bugs-list m
Antoine Pitrou added the comment:
Here is an updated patch. Much of it consists of changes in the Windows
Connection implementation, where I had to use overlapped I/O in order to use
WaitForMultipleObjects on named pipes.
test_concurrent_futures sometimes blocks (under Windows), I'll t
Antoine Pitrou added the comment:
Updated patch, fixing a sporadic failure in test_spawn_close.
--
Added file: http://bugs.python.org/file21926/mpconn2.patch
___
Python tracker
<http://bugs.python.org/issue11
Antoine Pitrou added the comment:
Ok, this patch seems fully debugged (under Windows and Linux). A couple of
things come in addition, such as removing repeated polling in
PipeConnection.poll() and _Popen.wait().
--
Added file: http://bugs.python.org/file21928/sentinels3.patch
Antoine Pitrou added the comment:
I have a full patch using overlapped I/O in issue9205 (sentinels3.patch).
--
___
Python tracker
<http://bugs.python.org/issue11
Antoine Pitrou added the comment:
The patch was committed in dev and maintenance branches. Thank you!
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
> pending_signals-3.patch:
> - don't check for pending signals in sigwait()
> - pthread_kill() doc: it is not a good idea to say that pthread_kill() with
> signum=0 can be used to check if a thread identifier is valid => such test
>
Antoine Pitrou added the comment:
Hum, I get a strange skip on a XP buildbot:
[224/354] test_multiprocessing
test_multiprocessing skipped -- DLL load failed: The specified procedure could
not be found.
Yet _multiprocessing was compiled fine... Does anyone know what it means?
http
Antoine Pitrou added the comment:
> Hum, I get a strange skip on a XP buildbot:
>
> [224/354] test_multiprocessing
> test_multiprocessing skipped -- DLL load failed: The specified
> procedure could not be found.
>
> Yet _multiprocessing was compiled fine... Does anyone
Antoine Pitrou added the comment:
Looks like a bug in the third-party "socks" module rather than in urllib. You
should report it there.
--
nosy: +pitrou
resolution: -> invalid
status: open -> pending
___
Python tracker
<htt
Antoine Pitrou added the comment:
> The trade-off of accommodating a small buffer size (by buffering
> behind the scenes anyways) would likely slow the more common cases
> which use a decent buffer size. I am wondering if an effort to
> accommodate both uses would be appropriate.
Antoine Pitrou added the comment:
Thank you, the patch looks good. A simple test could probably be added to
test_smtpnet, along the lines of the existing tests, do you want to tackle that?
--
stage: needs patch -> patch review
___
Python trac
New submission from Antoine Pitrou :
The code for check_GetFinalPathNameByHandle() goes like this:
static int has_GetFinalPathNameByHandle = 0;
[...]
static int
check_GetFinalPathNameByHandle()
{
HINSTANCE hKernel32;
/* only recheck */
if (!has_GetFinalPathNameByHandle
2801 - 2900 of 16792 matches
Mail list logo
