Antoine Pitrou added the comment:
Patch now committed, thank you!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Antoine Pitrou :
--
nosy: +brian.curtin, orsenthil, tim.golden
stage: -> patch review
versions: +Python 3.1, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
> I suspect this may be an issue now because the old svn approach was a
> full checkout for each build, whereas the hg approach is to pull to
> the local clone, and then just update the build tree. So in the svn
> case all the files would have a
Antoine Pitrou added the comment:
(the change will probably make things worse actually; see
http://bugs.python.org/issue11419)
--
___
Python tracker
<http://bugs.python.org/issue11
Antoine Pitrou added the comment:
Well, all of the following systems/configurations should have their support
removed in 3.3:
Name: Systems using Mach C Threads
Name: SunOS lightweight processes (LWP)
Name: Systems using --with-pth (GNU pth
Antoine Pitrou added the comment:
> Would it be possible to add an open() function to the bz2 module?
> Currently gzip has such a function, but bz2 does not:
Well, it could be a topic for a separate issue.
--
___
Python tracker
Antoine Pitrou added the comment:
> Uhm... cleaning this code I have a lot of references in ctypes
> libraries, especifically in the FFI section.
>
> I have the feeling that we are importing this code from upstream, so I
> better don't touch this ctypes/FFI.
ctypes can be
Antoine Pitrou added the comment:
> Regarding the use of PY_SSIZE_T_CLEAN, I assume that Py_ssize_t is to be
> preferred over plain ssize_t. Is this correct?
Yes, ssize_t doesn't exist everywhere AFAIK.
(size_t does, or at least we assume it does)
> Also, I was wondering whether
Changes by Antoine Pitrou :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue7689>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
IMO, it would probably have been better if these APIs had been private from the
start. Is there any use case for calling them from 3rd-party code?
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.
Antoine Pitrou added the comment:
Since the patch makes BadGzipFile a subclass of IOError, it doesn't look
unreasonable.
Some nits:
- a gzipped file is not an "archive"
- the unit tests should use either the "with" statement, or try/finally blocks
to properly close th
New submission from Antoine Pitrou :
http://www.python.org/dev/buildbot/all/builders/x86%20debian%20parallel%203.x/builds/1678/steps/test/logs/stdio
==
FAIL: test_check_output_timeout (test.test_subprocess.ProcessTestCase
Antoine Pitrou added the comment:
> It seems reasonable to me that the interpreter should be able to
> initialize and write to stdout in less than half a second
Well, we have some very slow buildbots and others which seem quite loaded too.
(this one should be very fast but perhaps there&
Antoine Pitrou added the comment:
There seems to be another kind, sporadic, of failure on the same buildbot:
test test_subprocess failed -- Traceback (most recent call last):
File
"/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/test/test_subprocess.py",
line 626, in test_wa
Changes by Antoine Pitrou :
--
nosy: +benjamin.peterson
___
Python tracker
<http://bugs.python.org/issue11549>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue11459>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
How about turning these asserts into Py_FatalError()s and then enabling
Victor's faulthandler extension?
--
___
Python tracker
<http://bugs.python.org/i
Changes by Antoine Pitrou :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: +Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
Indeed:
>>> s = b'a' * (2**31)
>>> d = pickle.dumps(s)
Traceback (most recent call last):
File "", line 1, in
SystemError: error return without exception set
There are two aspects to this:
- (bugfix) raise a proper
Antoine Pitrou added the comment:
Eugene, according to Mark your patch is fine. It just needs someone to commit
it. I would personally prefer to let Mark handle it, since he's our specialist
in negative zeroes (and other numerical subtleties) ;)
--
stage: patch review ->
Antoine Pitrou added the comment:
> Because I don't know how to make them. Any pointers?
Martin is hacking on the tool these days... So it's no surprise it
doesn't work perfectly yet ;)
If you have a Google account you can upload these patches to
http://codereview.ap
Antoine Pitrou added the comment:
> Uhmm, the test seems to have vanished in 3.x. Uhmmm... Why?.
Which test are you talking about?
--
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
> gdb tests. The python gdb scripting ability.
?
$ ls Lib/test/test_gdb.py
Lib/test/test_gdb.py
--
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
Other failures on the Sparc debian buildbot (which is quite slow):
==
ERROR: test_wait_timeout (test.test_subprocess.ProcessTestCase
Antoine Pitrou added the comment:
These "verbose numbers" don't seem to serve a purpose, they should simply be
removed (or replaced by a static, non-moving number higher than the highest svn
rev).
The keyword extension is generally frown upon, because it introduces
complexi
Antoine Pitrou added the comment:
"version numbers", not "verbose numbers", sorry.
--
___
Python tracker
<http://bugs.python.org/issue11439>
___
__
Antoine Pitrou added the comment:
> Thanks for spotting these. Is there an easier way for me to be
> notified if these particular tests fail?
Not really. There is no infrastructure to notify test failures to
specific e-mails depending on which test failed.
> Some of these are n
Antoine Pitrou added the comment:
> On Tue, Mar 15, 2011 at 7:05 PM, Antoine Pitrou
> wrote:
> ..
> > - (bugfix) raise a proper exception when an object too large for handling
> > by pickle is given
>
> What would be the "proper exception" here?
Over
Antoine Pitrou added the comment:
> I've asked the website team to see if they can adjust the robots.txt
> file
Is there a problem with the robots.txt? It already disallows all robots.
If Google ignores the robots.txt, then someone should complain to Google.
--
nosy: +g
Antoine Pitrou added the comment:
> I don't think so. OverflowError is a subclass of ArithmeticError and
> is raised when result of an arithmetic operation cannot be represented
> by the python type. For example,
If you grep for OverflowError in the C code base, you'l
Changes by Antoine Pitrou :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue11582>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
assignee: -> haypo
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue11586>
___
___
Python-bugs-list mailing list
Un
New submission from Antoine Pitrou :
Under Linux:
./Modules/posixmodule.c: In function ‘posix_readv’:
./Modules/posixmodule.c:6239: attention : implicit declaration of function
‘readv’
./Modules/posixmodule.c: In function ‘posix_writev’:
./Modules/posixmodule.c:6583: attention : implicit
Antoine Pitrou added the comment:
Thank you for the patch! This is now fixed in 3.x.
--
nosy: +pitrou
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 3.2, Python 3.3
___
Python track
Antoine Pitrou added the comment:
Sridhar: I'm sorry, but at this point you should investigate a bit more into
the actual causes of the problem. I'm not going to dig in virtualenv myself.
Also, since there's already #10743 for the virtualenv issue, perhaps further
virtualenv-r
Antoine Pitrou added the comment:
Ok, Palm's example even segfaults here:
Program received signal SIGSEGV, Segmentation fault.
0x772452bc in free () from /lib64/libc.so.6
(gdb) bt
#0 0x772452bc in free () from /lib64/libc.so.6
#1 0x0042a591 in Py_SetPath (
Antoine Pitrou added the comment:
Ouch, sorry, I got my commit message wrong.
--
___
Python tracker
<http://bugs.python.org/issue10914>
___
___
Python-bugs-list m
Antoine Pitrou added the comment:
Crash fixed in a791dd7d51f3 (3.2) and b4104ffd5127 (3.3), but the original
problem remains, or a variant of it. I now get:
Init
Fatal Python error: Py_Initialize: Unable to get the locale encoding
LookupError: no codec search functions registered: can't
Changes by Antoine Pitrou :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue11320>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Ok, the issue here is that you can't call Py_SetPath() on the point returned by
Py_GetPath(), since the memory refered to that pointer is free()d at the
beginning of Py_SetPath(). The following works, though:
main(int argc, char **argv)
{
wchar_t
Changes by Antoine Pitrou :
--
priority: high -> normal
title: Usage of API method Py_SetPath causes errors in Py_Initialize() (Posix
ony)) -> Can't call Py_SetPath() on pointer returned by Py_GetPath()
type: crash -> behavior
___
Antoine Pitrou added the comment:
> distutils sure knows how to build .o or .so files, but I don’t know
> about standalone executables (because I don’t know how the .o end up
> making an executable). If you want to try to do it, I would advise
> you not to use the config command
Antoine Pitrou added the comment:
+1 for not having pragma statements in the stdlib, especially when they target
a third-party tool few of us know and use.
Beside, while coverage measurements are useful, trusting them that actual
coverage is complete is IMO a bit foolish. It's not just
Antoine Pitrou added the comment:
> As for this error:
> Fatal Python error: Py_Initialize: Unable to get the locale encoding
> LookupError: no codec search functions registered: can't find encoding
>
> It seems to me that this error appears if the path passed to
&
Antoine Pitrou added the comment:
The question is not "why", it is "how". This file is part of the scripts used
to migrate from svn to hg. These files themselves were maintained in an hg
repository (it could have been an svn repository), for obvious practical
reasons. And
New submission from Antoine Pitrou :
Really, can't distutils at least display the command-line that failed to
execute?
Traceback (most recent call last):
File "/home/antoine/cpython/default/Lib/distutils/unixccompiler.py", line
176, in _compile
extra_postargs)
File
New submission from Antoine Pitrou :
One contains the include dirs for Python, not the other:
>>> distutils.sysconfig.get_config_var('PY_CFLAGS')
'-g -O0 -Wall -Wstrict-prototypes'
>>> distutils.sysconfig.get_config_var('PY_CPPFLAGS')
&#
New submission from Antoine Pitrou :
UnixCCompiler always uses "compiler_so", not "compiler", even when creating a
.o file. It is misleading and begs the question why compiler even exists.
--
assignee: tarek
components: Distutils
messages: 131355
nosy: eric.a
New submission from Antoine Pitrou :
python-config has the following non-trivial code for discovery of
cflags/ldflags, which should be callable as a sysconfig API instead:
elif opt in ('--includes', '--cflags'):
flags = ['-I' + sysconfig.get_path(&#
Antoine Pitrou added the comment:
Ok, this is what I came up with to build an exe using distutils. At this point,
the complication is downright silly and it doesn't even work under Windows, so
we may prefer to go down the Makefile route instead.
--
Added file: http://bugs.pytho
Antoine Pitrou added the comment:
I don't think the tests should be moved from one file to the other. It's making
more difficult to tell whether you have changed them or not. I think moving the
tests (as well as changing the synopsis, hello Eric) are cosmetic changes that
are bett
Antoine Pitrou added the comment:
Here is the adapted patch for 3.1, with a test case.
--
nosy: +pitrou
Added file: http://bugs.python.org/file21291/11459_v3.patch
___
Python tracker
<http://bugs.python.org/issue11
Antoine Pitrou added the comment:
Fixed now, thank you!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.3
___
Python tracker
<http://bugs.python.or
New submission from Antoine Pitrou :
Many urllib-related buildbot failures recently, this seems to be cause by one
of the recent urllib commits. 3.2 and 3.3 are affected.
http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%203.x/builds/1255
--
assignee: orsenthil
Antoine Pitrou added the comment:
Ok, the repo is now private.
--
resolution: -> fixed
status: open -> pending
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
Given the absence of response on python-dev, I'd say simply remove the obsolete
copyright notice.
--
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
This looks like an ugly hack to solve a slightly exotic problem. You could
instead enumerate() all threads and set their daemon flag to False, before
shutting down the interpreter.
--
nosy: +pitrou
___
Python
New submission from Antoine Pitrou :
There seem to be some buglets in the timeout code:
http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/2783/steps/test/logs/stdio
==
ERROR: test_check_output_timeout
Antoine Pitrou added the comment:
> There is one comment which I forgot to mention earlier.
>
> The current urlretrieve function is internally calling the URLOpener's
> retrieve method.
>
> Those URLOpener class might need a DeprecationWarning while address
> thi
Antoine Pitrou added the comment:
> URLopener which is an old class from the merge of urllib and urllib2
> and it can be slowly and safely removed. If we go this line, then I
> assume it has to have a DeprecationWarning before we remove it. Should
> we or not?
Yes, we shoul
Antoine Pitrou added the comment:
Hmm, making PyList_* an abstract API doesn't make sense to me. These functions
do exactly what they say: they operate on concrete instances of list (they are
documented as part of the concrete API). With that reasoning, we should have
fallback paths in
New submission from Antoine Pitrou :
>From
>http://www.python.org/dev/buildbot/all/builders/PPC%20Ubuntu%203.x/builds/779/steps/test/logs/stdio
==
FAIL: test_fexecve (test.test_posix.Posix
New submission from Antoine Pitrou :
Using WNOHANG means that still-running children won't get collected. This seems
to defeat the point of reap_children(). This patch seems to work:
diff -r adbdb3e74461 Lib/test/support.py
--- a/Lib/test/support.py Sun Mar 20 17:36:26 2011 +0100
Antoine Pitrou added the comment:
> I'm not sure. Was reap_children() meant to just reap zombie processes
> or wait for all children to finish?
Apparently just to reap zombie processes. At least that was the initial
intent. And it's true that we don't really need to
New submission from Antoine Pitrou :
http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.2/builds/101/steps/test/logs/stdio
test test_httpservers failed -- Traceback (most recent call last):
File
"/export/home/buildbot/32bits/3.2.cea-indiana-x86/build/Lib
Changes by Antoine Pitrou :
--
nosy: +krisvale, pitrou
___
Python tracker
<http://bugs.python.org/issue11618>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> It appears that the thread_id field is never actually used
> -- is it there to help with debugging? Perhaps it should just be
> removed.
True, I think we can remove it.
> does this mean that in Python 3.2
> threads are only supported wi
Antoine Pitrou added the comment:
Well, Windows 2000 has semaphores, so why not use them? It makes the code much
simpler. Patch attached (including test).
--
nosy: +loewis
Added file: http://bugs.python.org/file21308/semlocknt.patch
___
Python
Changes by Antoine Pitrou :
--
nosy: +brian.curtin, tim.golden
___
Python tracker
<http://bugs.python.org/issue11618>
___
___
Python-bugs-list mailing list
Unsub
Antoine Pitrou added the comment:
> Have you tried benchmarking it?
>
> Interlocked functions are *much* faster than Win32 mutex/semaphores in
> the uncontended case.
Well, I'd rather have obviously correct code than
difficult-to-understand "speedy" code.
The p
Antoine Pitrou added the comment:
> Interestingly, it used to be a Semaphore up to [5e6e9e893acd]; in
> [cde4da18c4fa], Yakov Markovitch rewrote this to be the faster
> implementation we have today.
At that time, the Pythread_* functions were still in use by the GIL
implementation, an
Antoine Pitrou added the comment:
> > At that time, the Pythread_* functions were still in use by the GIL
> > implementation, and it made a difference judging by the commit message.
>
> Hmm. And if some application uses thread.lock heavily, won't it still
> make
Antoine Pitrou added the comment:
> The problem isn't a lack of available abstract
> functions.
Then what is it exactly?
You are arguing for PyList_SetItem() to have the same semantics as
PyObject_SetItem(), but what's the point of having two functions which
do exactly th
Antoine Pitrou added the comment:
It would be nice if it were enabled by default for fatal errors (and asserts
perhaps?).
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue11
Antoine Pitrou added the comment:
Probably a bad idea on my part :)
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
Committed the patch with the test, thank you!
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
> It appears a choice has been made to print only the first argument in
> the error messages; attached patch changes that, please test.
Well, I don't have the failing setup at hand anymore, but the patch
looks reasonable to me
Antoine Pitrou added the comment:
> Yes, the race condition with the timeout is a problem.
> Here is a patch that implements this lock using a condition variable.
> I agree that one must consider performance/simplicity when doing this.
I don't understand why you need something th
Antoine Pitrou added the comment:
> I'm just providing this as a fast alternative to the Semaphore, which
> as far as I know, will cause a kernel call every time.
A Semaphore might be "slow", but I'm not sure other primitives are
faster. For the record, I tried anot
New submission from Antoine Pitrou :
Looks like a bootstrap issue, could be related to the latest getopt changes:
Could not find platform dependent libraries
Consider setting $PYTHONHOME to [:]
Traceback (most recent call last):
File "/Users/db3l/buildarea.dmg/3.x.dmg/build/setup.py&q
Changes by Antoine Pitrou :
--
nosy: -pitrou
___
Python tracker
<http://bugs.python.org/issue11621>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Actually, it's not specific to the DMG build.
--
nosy: +pitrou, r.david.murray
priority: normal -> release blocker
title: DMG build error -> build error: bootstrap issue with gettext
___
Python tra
Antoine Pitrou added the comment:
Should be fixed.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11621>
___
__
Antoine Pitrou added the comment:
> >From the discussion on python-dev, it seems that I will need to submit a
> Contributor Agreement to the PSF. Can I ask that you not commit this
> patch until the CA has been submitted? I will need to clear it with my
> employer, and it m
Antoine Pitrou added the comment:
Just for the record, here is the critical section-based version.
I would still favour committing the semaphore-based version first (especially
in 3.2), and then discussing performance improvements if desired.
--
Added file: http://bugs.python.org
Antoine Pitrou added the comment:
> Antoine: I notice that even the fast path contains a ResetEvent()
> call. I think this is a kernel call and so just as expensive as
> directly using a semaphore :)
Yes, in my timings it doesn't show significant improvements compared to
Antoine Pitrou added the comment:
Have you tried 3.1?
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue11627>
___
___
Python-bugs-list mailin
Antoine Pitrou added the comment:
Le lundi 21 mars 2011 à 22:57 +, Andreas Stührk a écrit :
> Andreas Stührk added the comment:
>
> Attached is a patch. I'm not too happy about the error message though,
> I think it's more confusing than helpful.
You could try s
New submission from Antoine Pitrou :
Introduced by ef2b6305d395.
--
assignee: haypo
messages: 131727
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: refleak in test_import
type: resource usage
versions: Python 3.3
___
Python
Changes by Antoine Pitrou :
--
nosy: +amaury.forgeotdarc
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue10694>
___
___
Python-bugs-list m
New submission from Antoine Pitrou :
concurrent.futures uses polling in its worker threads and processes
(with a timeout of 0.1).
It means that:
1) this prevents CPUs to enter low power states durably
2) it incurs latency when calling shutdown() on an executor (this seems to be
the main source
Antoine Pitrou added the comment:
Ok, here is a patch. Summary:
- leave a minimal amount of polling (every 600 seconds) to avoid blocking
forever if there's a bug (shouldn't happen of course, but who knows? especially
with multiprocessing)
- when wanting to wakeup a worker, put N
Antoine Pitrou added the comment:
(patch is for 3.2, by the way. Perhaps this should only be fixed in default?)
--
___
Python tracker
<http://bugs.python.org/issue11
Antoine Pitrou added the comment:
Can you try to see if the refleak is still there? I can't reproduce on my
Windows 7 VM.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/is
New submission from Antoine Pitrou :
If you add the following test to text_contextlib:
diff --git a/Lib/test/test_contextlib.py b/Lib/test/test_contextlib.py
--- a/Lib/test/test_contextlib.py
+++ b/Lib/test/test_contextlib.py
@@ -363,6 +363,8 @@ class TestContextDecorator(unittest.Test
Antoine Pitrou added the comment:
Several people have spoken in favour of this document and you are the only one
who finds it useless, apparently (*). I think it should therefore be restored
in the repository.
(*) see http://mail.python.org/pipermail/python-dev/2011-March/109513.html
Antoine Pitrou added the comment:
> I would suggest that you base your patch on 3.3/default.
Well, since the module is new, I think it would be nice to fix such
quirks in the bugfix branch as well. So, following the recommended
workflow, I've started with a 3
Antoine Pitrou added the comment:
> Your approach seems workable but your patch allows the interpreter to
> exit while work items are still being processed. See the comment at
> the top of concurrent/futures/thread.py.
Why are you saying that? In my patch, _python_exit() still take
New submission from Antoine Pitrou :
Summary:
- remove "make quicktest" and "make memtest"
- when "-j0" is passed to regrtest, use the cpu count detected by
multiprocessing
- remove the duplicate test in "make test"
- add "-j0" to the test opti
Antoine Pitrou added the comment:
> I propose instead to change 'make quicktest' to use -j(N>1) and blacklist the
> following tests:
>
> test_mmap
> test_shelve
> test_posix
> test_largefile
> test_concurrent_futures
Why would you blacklist these tests?
2501 - 2600 of 16792 matches
Mail list logo
