Antoine Pitrou added the comment:
Here is a patch adding ResourceWarning, adding new tests, and fixing failures
in existing tests.
Feedback welcome.
--
Added file: http://bugs.python.org/file19236/deallocwarn3.patch
___
Python tracker
<h
Changes by Antoine Pitrou :
Removed file: http://bugs.python.org/file19236/deallocwarn3.patch
___
Python tracker
<http://bugs.python.org/issue10093>
___
___
Python-bug
Antoine Pitrou added the comment:
I committed the test fixes to py3k, so here is an updated patch.
--
Added file: http://bugs.python.org/file19238/deallocwarn3.patch
___
Python tracker
<http://bugs.python.org/issue10
Antoine Pitrou added the comment:
> Seems like a good idea to me. Would other VMs have to implement sys.xoptions
> too?
I don't think we should mandate that, no.
--
___
Python tracker
<http://bugs.python.
Changes by Antoine Pitrou :
--
nosy: +kbk
___
Python tracker
<http://bugs.python.org/issue10079>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> (It also makes it clear that other implementations aren't obliged to
> implement *any* particular interface to the -X options. Requiring that
> would go against the whole spirit of -X)
Agreed. I'll update the patch t
Antoine Pitrou added the comment:
> Please add a similar warning in PC/_subprocess.c::sp_handle_dealloc()
> I just got caught by this in PyPy because some pipe handle relies on
> reference counting to be closed.
Do you want to provid
Antoine Pitrou added the comment:
Probably, yes.
--
___
Python tracker
<http://bugs.python.org/issue8293>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Antoine Pitrou :
When a machine has a newer glibc and an old kernel, accept4 can fail and then
Python accept() is unusable. For example:
Traceback (most recent call last):
File
"/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/threading.py", lin
Antoine Pitrou added the comment:
Or perhaps we should back out the accept4 change and live with the fact that
SOCK_CLOEXEC and SOCK_NONBLOCK can't be inherited by calling accept().
--
___
Python tracker
<http://bugs.python.org/is
Antoine Pitrou added the comment:
> Falling back on result 90 is not that difficult, I think I can submit
> a patch today. What should be checked ENOSYS or 90?
That's a rather good question. I will enable some debug printout on t
Changes by Antoine Pitrou :
--
nosy: +benjamin.peterson
___
Python tracker
<http://bugs.python.org/issue10114>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Rather than the hand-made _open_with_retry, I think it would be better to use
support.transient_internet() (it's already used in other tests). Retrying is
not very helpful if the other end is down.
Also, EBADF (bad file descriptor) looks like a bug. ht
Antoine Pitrou added the comment:
Ok, 90 is ENOSYS on that buildbot :)
--
___
Python tracker
<http://bugs.python.org/issue10115>
___
___
Python-bugs-list mailin
Antoine Pitrou added the comment:
> What about exposing accept4() to python level?
That's another possibility, in which case we would first remove the current
accept4-calling code in order to fix the buildbot failure.
--
nosy: +loewis
__
Changes by Antoine Pitrou :
--
nosy: +exarkun
___
Python tracker
<http://bugs.python.org/issue10115>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> Given the range of people advocating for this change, this looks to me
> like it should be a release blocker for 3.2. Raymond's comment about
> performance seems especially important, and since the world seems to
> be moving toward 64-bit
Antoine Pitrou added the comment:
Le vendredi 15 octobre 2010 à 22:51 +, Mads Kiilerich a écrit :
> Mads Kiilerich added the comment:
>
> Can you confirm that the exception raised both on "too early" and "too
> late" is something like "...SSL3_GET_SE
Antoine Pitrou added the comment:
Here is a new patch renaming the attribute to sys._xoptions, and adding some
docs.
--
Added file: http://bugs.python.org/file19252/xopts2.patch
___
Python tracker
<http://bugs.python.org/issue10
Antoine Pitrou added the comment:
> Weekend is coming, so I can lend a hand in implementing whatever you
> choose.
I don't have any strong opinion about it, so it's whichever you prefer really :)
--
___
Python tracker
<htt
Antoine Pitrou added the comment:
(barry)
> I wonder if we should try to get a buildbot up that uses --enable-
> shared?
(éric)
> If the option has significant use, why not.
Well, it's all the more significant that most Linux distros use shared
libraries, so they will use tha
Antoine Pitrou added the comment:
I've done so on one of the stable buildbots. Let's see how it behaves:
http://www.python.org/dev/buildbot/builders/x86%20Ubuntu%20Shared%203.x/
--
___
Python tracker
<http://bugs.python.
Changes by Antoine Pitrou :
--
assignee: bob.ippolito ->
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue5729>
___
___
Python-bugs-list mai
New submission from Antoine Pitrou :
This happens on Python 3.1:
/usr/bin/ld: cannot find -lpython3.1
collect2: ld returned 1 exit status
test test_distutils failed -- Traceback (most recent call last):
File
"/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/distutils/unixccompil
Antoine Pitrou added the comment:
Similar failure on 2.7:
/usr/bin/ld: cannot find -lpython2.7
collect2: ld returned 1 exit status
test test_distutils failed -- Traceback (most recent call last):
File
"/srv/buildbot/buildarea/2.7.bolen-ubuntu/build/Lib/distutils/tests/test_build_e
Antoine Pitrou added the comment:
Le samedi 16 octobre 2010 à 20:43 +, Barry A. Warsaw a écrit :
> Barry A. Warsaw added the comment:
>
> I fixed this in py3k branch, so you just need to backport that. I can
> do if you can't get to it in the next day or so.
I don'
Antoine Pitrou added the comment:
I cannot reproduce with 2.7, 3.1 or 3.2. It seems the issue is obsolete, many
changes having been made to the ssl module since 2.6.
--
resolution: -> out of date
status: open -> pending
___
Python tracker
Antoine Pitrou added the comment:
There would need to be some tests.
Also, this last part of the patch looks strange:
@@ -3001,6 +3072,10 @@
PyErr_SetString(PyExc_ValueError,
"can't use invalid socket value");
ret
Antoine Pitrou added the comment:
Le dimanche 17 octobre 2010 à 17:40 +, Martin v. Löwis a écrit :
> Martin v. Löwis added the comment:
>
> > The issue Raymond raised is the potential impossibility of making the
> > change /after/ we settle on a stable ABI. The quest
Changes by Antoine Pitrou :
___
Python tracker
<http://bugs.python.org/issue9778>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/o
Changes by Antoine Pitrou :
--
nosy: +eric.smith, rhettinger
___
Python tracker
<http://bugs.python.org/issue10135>
___
___
Python-bugs-list mailing list
Unsub
Changes by Antoine Pitrou :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue10127>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Antoine Pitrou :
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue5736>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Le lundi 18 octobre 2010 à 13:56 +, Alexander Belopolsky a écrit :
> Alexander Belopolsky added the comment:
>
> On Mon, Oct 18, 2010 at 8:45 AM, Benjamin Peterson
> wrote:
> ..
> > No, negative values have to be allowed.
> >
Antoine Pitrou added the comment:
> AFAICT, a change from (Py_ssize_t)-1 to (size_t)-1 is less likely to
> break code than a change from -1L to (Py_ssize_t)-1. (Assuming a
> sizeof(long) != sizeof(void*) platform.)
That's true.
> The benefit, though is that
> hash
Changes by Antoine Pitrou :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue9437>
___
___
Python-bugs-list mailing list
Unsubscri
Antoine Pitrou added the comment:
If it's just additional constants then I don't see the problem. We already have
a lot of platform-specific constants.
However, it would be a lot better if the io module were made to work properly
with these constants, too. There are a lot of place
Antoine Pitrou added the comment:
> I don't think that a command line option and an environment variable
> is pratical for an OS distributor.
Environment variables are probably the most practical for OS vendors,
since they can simply set them in /etc/profile.d (Mandriva doe
Antoine Pitrou added the comment:
Here is a simpler version without comma-separated pairs.
--
Added file: http://bugs.python.org/file19302/xopts3.patch
___
Python tracker
<http://bugs.python.org/issue10
Antoine Pitrou added the comment:
Your traceback suggests it's a string allocated when reading a module file...
--
___
Python tracker
<http://bugs.python.org/is
Antoine Pitrou added the comment:
> I've the same question as Jesús Cea Avión: what is needed to get this
> in 3.2?
Same as usual: someone to review, apply, commit. Why do you ask?
--
nosy: +pitrou
___
Python tracker
<http://b
Antoine Pitrou added the comment:
Committed in r85772.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Antoine Pitrou :
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue3356>
___
___
Python-bugs-
Changes by Antoine Pitrou :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue10153>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Here is a patch for py3k, including http.client and urllib support.
--
Added file: http://bugs.python.org/file19327/sni.patch
___
Python tracker
<http://bugs.python.org/issue5
Antoine Pitrou added the comment:
You broke many 2.7, 3.1 and 3.x buildbots.
--
priority: high -> critical
resolution: fixed ->
status: closed -> open
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
Committed with docs in r85793.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
I've removed the accept4() call in the meantime (in r85796), so that this issue
can be re-classified as a feature request.
--
priority: critical -> normal
title: accept4 can fail with errno 90 -> Support accept4() for atomic setting
Antoine Pitrou added the comment:
Committed in r85797.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
> After thinking about what warning to go with, I take back my python-dev
> suggestion of ResourceWarning and switch to DebugWarning.
So what is your advice now?
I've thought about the DebugWarning name myself and I think it's a rather bad
na
Antoine Pitrou added the comment:
The commit broke the Windows buildbots because (un)pickling a TextIOWrapper now
raises an exception:
>>> f = open("LICENSE")
>>> pickle.dumps(f)
b'\x80\x03c_io\nTextIOWrapper\nq\x00)\x81q\x01}q\x02X\x04\x00\x00\x00modeq\x03
Antoine Pitrou added the comment:
The difference has to do with the result of __reduce__:
With the patch:
>>> open("LICENSE").__reduce_ex__(3)
(, (,),
{'mode': 'r'}, None, None)
Without:
>>> open("
New submission from Antoine Pitrou :
unittest.TestCase instances aren't supposed to be picklable, but
test_multiprocessing does it anyway (under Windows). Here is a patch.
--
components: Tests
files: tmp.patch
keywords: patch
messages: 119407
nosy: asksol, jnoller, pitrou
pri
Changes by Antoine Pitrou :
--
nosy: +michael.foord
___
Python tracker
<http://bugs.python.org/issue10173>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
assignee: -> jcea
___
Python tracker
<http://bugs.python.org/issue10143>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Antoine Pitrou :
--
components: +Library (Lib) -None
nosy: +asksol, jnoller
versions: +Python 3.1, Python 3.2 -Python 2.6
___
Python tracker
<http://bugs.python.org/issue10
New submission from Antoine Pitrou :
This network drive is actually mapped through the VirtualBox guest additions.
Under Python 2.7 (official 64-bit MSI installer), this works fine:
>>> s = 'Z:\\__svn__\\Lib\\test\\keycert.pem'
>>> os.stat(s)
nt.stat_result(st_mod
Antoine Pitrou added the comment:
And 3.1 works fine.
--
___
Python tracker
<http://bugs.python.org/issue10179>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Hmm, it looks like this is actually VirtualBox-specific.
It works with another network drive mapped on Y:
>>> os.stat(r"y:")
nt.stat_result(st_mode=16895, st_ino=0, st_dev=0, st_nlink=0, st_uid=0,
st_gid=0, st_size=0, st_atime=1287784175,
Antoine Pitrou added the comment:
Yes, indeed. It was critical before I found out that it's VirtualBox-specific.
--
priority: critical -> normal
___
Python tracker
<http://bugs.python.org
Antoine Pitrou added the comment:
This patch seems to do the trick, although I'm not sure it warrants including
in Python.
--
keywords: +patch
Added file: http://bugs.python.org/file19342/osstat.patch
___
Python tracker
<http://bugs.py
Antoine Pitrou added the comment:
Case's patch fixes test_builtin and test_complex failures on Windows 7 64-bit.
But there's still a failure in test_dictviews:
==
FAIL: test_items_set_
Changes by Antoine Pitrou :
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue9778>
___
___
Python-bugs-list mailing list
Unsubscri
Antoine Pitrou added the comment:
This patch seems to fix all aforementioned failures.
--
Added file: http://bugs.python.org/file19343/hashw64.patch
___
Python tracker
<http://bugs.python.org/issue9
New submission from Antoine Pitrou :
In Python 3, pickle accepts to serialize a file object, but the result is
nonsensical when unpickled. I think we should explicitly forbid pickling of
FileIO, Buffered{Reader,Writer} and TextIOWrapper objects.
--
components: IO, Library (Lib
Antoine Pitrou added the comment:
Ok, I've committed them in r85808.
--
status: open -> pending
___
Python tracker
<http://bugs.python.org/issue9778>
___
Antoine Pitrou added the comment:
Here is a patch, but issue10173 must probably be fixed first.
--
dependencies: +Don't pickle TestCase instances in test_multiprocessing
keywords: +patch
Added file: http://bugs.python.org/file19344/pickleio.
Antoine Pitrou added the comment:
> Can you try my patch in #10027? Does this also fail?
No, your patch seems to fix the issue.
--
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
The test_capi problem is not 64-bit-specific (see issue9116).
As for test_concurrent_futures, I also have a failure (not the same one) in
both 32-bit and 64-bit builds here. I'm gonna open a separate
New submission from Antoine Pitrou :
I get this failure quite reliably on a Windows 7 VM, in both 32-bit and 64-bit
builds:
==
FAIL: test_map_timeout (test.test_concurrent_futures.ProcessPoolExecutorTest
Antoine Pitrou added the comment:
> The patch modifies _io.TextIOWrapper, but not _pyio.TextIOWrapper. Is
> there a reason?
Yes, two of them:
- modifying _pyio.Buffered* is enough to trigger the TypeError
- _pyio.StringIO inherits from TextIOWrapper, and it must be pick
Antoine Pitrou added the comment:
Committed in r85810, thank you.
--
nosy: +pitrou
resolution: -> fixed
status: open -> closed
versions: -Python 3.3
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
> I don't see why Buffered or TextIO's shouldn't be pickleable, ISTM
> their pickleability should be based on what the underlying file obj
> is.
That could be. Right now, though, pickling them gives nonsensical
results and I think it wo
Antoine Pitrou added the comment:
> These changes cause some regressions:
> - distutils builds third-party extensions with LDFLAGS, which were
> used to build CPython. (This is more important regression.)
> This problem concerns Python 2.7 and 3.2.
Well, is this a problem? This
Antoine Pitrou added the comment:
> Antoine, is there more that remains to be done on this, or can it be closed?
I don't know really. I have done what I thought necessary on
memoryview/buffer maintenance, and I don't really want to g
Antoine Pitrou added the comment:
> I doubt I, or Ask will have the time to rewrite the entire
> multiprocessing test suite right now to work around the change
> Antoine.
Well, I'm not asking anyone to rewrite the entire multiprocessing test suite;
and, besides, I've prov
Antoine Pitrou added the comment:
I think the docs should also make it clear that these flags are only supported
by os.lseek() (unless you have tested the IO lib to work properly, that is, but
in this case it would be nice to add unit tests
Antoine Pitrou added the comment:
> I will update documentation.
>
> Antoine, it is difficult to write a testcase when I can only test
> under a system with ZFS. I don't think we have a buildbot with
> Solaris/*BSD and ZFS.
If you ascertain yourself that the test works un
Antoine Pitrou added the comment:
> I've wrapped the whole of get_frame_marker_info with a
> PyErr_Fetch/PyErr_Restore pair: the PyUnicode_AsUTF8String calls could
> fail with a MemoryError, and we don't want to confuse the regular
> exception handling within ceval.
If
Changes by Antoine Pitrou :
--
assignee: nobody -> d...@python
nosy: +d...@python
versions: +Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
Agreed with Benjamin. There is already a visible issue with the patch: it
breaks compatibility because the Py_VISIT() argument must now be an lvalue.
--
___
Python tracker
<http://bugs.python.org/issue10
Antoine Pitrou added the comment:
Unless we want to test manually each memory allocation in the interpreter, the
only reasonable way seems to be some kind of fuzzing (perhaps using a
reproducible random seed).
--
nosy: +haypo
___
Python tracker
Antoine Pitrou added the comment:
Shouldn't this be closed? Most of this has been done and we can't do the rest
anyway, without breaking backwards compatibility.
--
nosy: +pitrou
status: open -> pending
___
Python tracker
<http:/
Antoine Pitrou added the comment:
Is it still reproduceable with 2.7, 3.1 or 3.2?
--
___
Python tracker
<http://bugs.python.org/issue3362>
___
___
Python-bug
Antoine Pitrou added the comment:
> Don't you know http://www.nongnu.org/failmalloc/?
This doesn't answer the question of what and how to test.
--
___
Python tracker
<http://bugs.pytho
New submission from Antoine Pitrou :
Sun/Oracle uses the following patch to fix building of the socket module, since
on Solaris "netpacket/packet.h" is incompatible with its Linux counterpart.
Otherwise, it fails with the following messages:
/home/antoine/py3k/gcc/Modules/socketmo
Antoine Pitrou added the comment:
Here is a working patch for py3k. Tested under OpenSolaris with both gcc and
Sun C.
--
keywords: +patch
nosy: +laca
Added file: http://bugs.python.org/file19371/buildsocket.patch
___
Python tracker
<h
Antoine Pitrou added the comment:
For the record, replacing /dev/null with conftest.out in the configure test
solves the detection problem (and allows Python to build cleanly). However,
there is then a problem in test_systemtap (even when replacing "stap" with
"dtrace")
Antoine Pitrou added the comment:
(my last message was about building on OpenSolaris)
--
___
Python tracker
<http://bugs.python.org/issue4111>
___
___
Python-bug
Antoine Pitrou added the comment:
> Doing so would imply running each test many tens of thousands of
> times, so perhaps we could run "-c pass" to establish at what serialno
> the interpreter has fully started up, then use that as a starting
> point when testing other
Antoine Pitrou added the comment:
It sounds more like an issue in socket.close(), right?
--
nosy: +exarkun, loewis, pitrou
___
Python tracker
<http://bugs.python.org/issue10
New submission from Antoine Pitrou :
This recurrent crash appeared recently under the XP-4 buildbot, between r85816
and r85819. But none of these revisions looks related to potential file issues.
Each time the test just finishes with:
[...]
test_file2k
program finished with exit code
Antoine Pitrou added the comment:
> This is not a problem under Solaris 10. I guess it is a problem with
> OpenSolaris/OpenIndiana/Illumos.
>
> Can you confirm?.
It's with the most recent OpenSolaris development build (build 134).
--
_
Antoine Pitrou added the comment:
> Jesús Cea Avión added the comment:
>
> Could this to be considered a bug in OpenSolaris?.
That's a good question. Perhaps Laca (who wrote the original patch) can
chime in.
> If not, I think this fix should be backported to 2.5/2.6/2.7
Antoine Pitrou added the comment:
You can't add buffer protocol support to cStringIO in a bugfix release, since
it would be a new feature.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/is
Antoine Pitrou added the comment:
Actually, there's a better patch in #8852.
--
resolution: -> duplicate
status: open -> closed
superseder: -> _socket fails to build on OpenSolaris x64
___
Python tracker
<http://bugs.pyth
Antoine Pitrou added the comment:
David's patch works here (OpenSolaris build 134).
--
components: +Build, Extension Modules
nosy: +laca, movement, pitrou
resolution: -> accepted
stage: -> commit review
versions: +Python 2.7, Python 3.1, Python 3.2
Antoine Pitrou added the comment:
Ok, here is an updated patch with finer-grained constants injection.
--
Added file: http://bugs.python.org/file19383/buildsocket.patch
___
Python tracker
<http://bugs.python.org/issue8
Antoine Pitrou added the comment:
There's a patch in issue9295 which might fix a similar problem
("test_close_open_print_buffered sometimes crashes"). Could you try it?
--
___
Python tracker
<http://bugs.pyt
Antoine Pitrou added the comment:
According to http://www.w3.org/TR/xml-names/:
“The prefix xml is by definition bound to the namespace name
http://www.w3.org/XML/1998/namespace. It MAY, but need not, be declared, and
MUST NOT be bound to any other namespace name. Other prefixes MUST NOT be
2001 - 2100 of 16792 matches
Mail list logo
