Antoine Pitrou added the comment:
Committed in r85858 (3.2), r85859 (3.1) and r85860 (2.7). Thank you!
--
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bug
Antoine Pitrou added the comment:
Duplicate of issue10038.
--
nosy: +pitrou
resolution: -> duplicate
status: open -> closed
superseder: -> Returntype of json.loads() on strings
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
Committed in r85868 (3.2), r85869 (3.1) and r85870 (2.7). Thank you.
--
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bug
Changes by Antoine Pitrou :
--
assignee: -> ronaldoussoren
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue10215>
___
___
Python-bugs-lis
Changes by Antoine Pitrou :
--
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue6715>
___
___
Python-bugs-list mailing list
Unsub
Changes by Antoine Pitrou :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue9981>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Is it CPython-specific?
Does "currently executing" also include "currently closing"?
--
nosy: +pitrou
___
Python tracker
<http://bug
Changes by Antoine Pitrou :
--
nosy: +rhettinger
type: -> behavior
versions: +Python 3.2 -Python 2.6
___
Python tracker
<http://bugs.python.org/issu
Changes by Antoine Pitrou :
--
nosy: +barry, loewis
___
Python tracker
<http://bugs.python.org/issue6103>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
stage: committed/rejected -> patch review
___
Python tracker
<http://bugs.python.org/issue10116>
___
___
Python-bugs-list mai
Antoine Pitrou added the comment:
Hirokazu, I've committed your 2.7 patch in r85892. Let's see what the buildbots
say.
--
resolution: -> fixed
status: open -> pending
versions: -Python 2.6
___
Python tracker
<http://bugs.p
Antoine Pitrou added the comment:
Apparently it's fixed!
--
stage: needs patch -> committed/rejected
status: pending -> closed
___
Python tracker
<http://bugs.python
Antoine Pitrou added the comment:
I've committed the aforementioned patch (r85892) and this seems to be fixed.
Thank you!
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.
Antoine Pitrou added the comment:
Updated patch against py3k.
--
Added file: http://bugs.python.org/file19403/memerror.patch
___
Python tracker
<http://bugs.python.org/issue5
Antoine Pitrou added the comment:
+1 for fixing this in-tree. We need a patch, though ;)
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue10
Antoine Pitrou added the comment:
I can't manage to reproduce the issue with PyExc_RecursionErrorInst. It seems
this instance is only used in a very select condition, that is, when the
recursion limit is hit when trying to "normalize" an exception. Therefore, I
will add
Antoine Pitrou added the comment:
Patch with improved tests committed in r85896 (3.2) and r85898 (3.1).
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
I would need opinions on one more thing. The current patch warns when a socket
has not been explicitly closed. But it does so even when the socket isn't bound
at all. e.g.:
$ ./python -c "import socket; socket.socket()"
-c:1: ResourceWa
Changes by Antoine Pitrou :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue10217>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +sable
___
Python tracker
<http://bugs.python.org/issue10222>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Could you upload the patch to http://codereview.appspot.com/?
--
___
Python tracker
<http://bugs.python.org/issue6715>
___
___
Antoine Pitrou added the comment:
> If a new, unbound socket uses some form of OS resource, then a warning
> is needed. Is their an equivalent limitation like there is with file
> descriptors as to how many an OS can possibly have open at once?
A socket *is* a file descriptor (under
Antoine Pitrou added the comment:
> @pitrou: Why is this marked "Python 3.3"? If the error handling in
> the C module is corrected, it's in a good enough shape to be committed
> before 3.2b1, and the remaining bugs ironed out until final.
I think it needs a real review
Antoine Pitrou added the comment:
> That's what I'm referring to: most Python applications are
> written with the fact in mind, that garbage collection will
> close the files or socket.
>
> That's a perfectly fine way of writing Python applications,
Some peo
Antoine Pitrou added the comment:
You forgot to attach your patch.
--
___
Python tracker
<http://bugs.python.org/issue10227>
___
___
Python-bugs-list mailin
New submission from Antoine Pitrou :
This is only when several dbm modules are compiled in (e.g. "gnu" and "dumb"):
$ ./python -m test.regrtest -R 3:2 test_dbm
[1/1] test_dbm
beginning 5 repetitions
12345
test test_dbm failed -- Traceback (most recent call last):
File
Antoine Pitrou added the comment:
The sequence protocol (if I'm not confused) only work with a PyObject ** array.
--
___
Python tracker
<http://bugs.python.org/is
Antoine Pitrou added the comment:
Here is an updated patch (also fixes a small refleak).
--
Added file: http://bugs.python.org/file19411/deallocwarn4.patch
___
Python tracker
<http://bugs.python.org/issue10
Antoine Pitrou added the comment:
> As an additional point: the PyMemoryObject has a "base" member that I
> think is redundant. the "view.obj" should be sufficient.
Yes, that's what I think as well.
--
___
Python t
New submission from Antoine Pitrou :
This is probably caused by r85223.
$ ./python -m test.regrtest -R 3:2 test_gettext
[1/1] test_gettext
beginning 5 repetitions
12345
test test_gettext failed -- Traceback (most recent call last):
File "/home/antoine/py3k/deallocwarn/Lib/test/test_gette
Antoine Pitrou added the comment:
I've committed the patch in r85920; let's watch the buildbots. Also, you'll see
many warnings in the test suite if compiled --with-pydebug.
--
resolution: -> fixed
stage: -> committed/rejected
_
Antoine Pitrou added the comment:
> I'd have to take another look with the profiler to figure out how
> bytes slicing in 3.0 works, but I suspect that it is somehow
> fasttracked passed the creation of slice objects, etc.
I don't think it is fasttracked at all.
Even pl
Antoine Pitrou added the comment:
> Whether you write an application with automatic closing of
> the file/socket at garbage collection time in mind, or you explicitly
> close the file/socket, the timing is the same.
No, because objects can be kept alive through tracebacks (or referen
Antoine Pitrou added the comment:
> The warning will trigger without any reason.
Well, by now you should have understood the reason, so I conclude that
you are either 1) deaf 2) stupid 3) deliberately obnoxious.
This is my last answer to you on this topic. Good
Antoine Pitrou added the comment:
The buildbots showed no major issue, so this issue is now resolved. The
warnings expose a lot of issues in the stdlib that deserve addressing, though ;)
--
status: open -> closed
___
Python tracker
&l
New submission from Antoine Pitrou :
This fixes all the warnings because of files not closed explicitly in
test_tarfile.
--
components: Library (Lib)
files: tarfileclose.patch
keywords: patch
messages: 119909
nosy: lars.gustaebel, pitrou
priority: normal
severity: normal
stage: patch
Antoine Pitrou added the comment:
> Thanks for catching this. Attached patch fixes the error with -R and
> works without -R too, please review.
It looks good to me.
--
___
Python tracker
<http://bugs.python.org/i
New submission from Antoine Pitrou :
Since r85920, test_subprocess has been showing a bunch of ResourceWarnings.
It seems that the pipe objects don't get explicitly closed in wait() or
__del__, while they do in communicate().
--
components: Library (Lib), Tests
messages: 119916
Antoine Pitrou added the comment:
Committed in r85931 (3.2), r85932 (3.1) and r85933 (2.7).
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
New submission from Antoine Pitrou :
Changing it can produce failures, e.g.:
$ COLUMNS=178 ./python -m test.regrtest -v test_argparse
This can be seen on one of the buildbots:
http://www.python.org/dev/buildbot/all/builders/PPC%20Leopard%203.x/builds/685/steps/test/logs/stdio
Antoine Pitrou added the comment:
Already reported actually.
--
resolution: -> duplicate
status: open -> closed
superseder: -> test_argparse.py: 80 failures if COLUMNS env var set to a value
other than 80
___
Python track
Antoine Pitrou added the comment:
As noted in issue10235, this is responsible for buildbot failures:
http://www.python.org/dev/buildbot/all/builders/PPC%20Leopard%203.x/builds/685/steps/test/logs/stdio
--
nosy: +janssen, pitrou
___
Python tracker
New submission from Antoine Pitrou :
A buildbot has shows occasional failures in the Barrier tests:
[299/349] test_threading
[39130 refs]
[39501 refs]
[39501 refs]
[39491 refs]
[39499 refs]
Unhandled exception in thread started by
Traceback (most recent call last):
File
"/home/build
Changes by Antoine Pitrou :
--
nosy: +brett.cannon
___
Python tracker
<http://bugs.python.org/issue10233>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Thanks for the review. I've committed a modified patch in r85955.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.pyth
Antoine Pitrou added the comment:
I think there should be a try..finally block so that those files get closed
even when there's an error in-between.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/is
Antoine Pitrou added the comment:
> How does v2 look?
Nice, thank you!
--
___
Python tracker
<http://bugs.python.org/issue10246>
___
___
Python-bugs-list mai
Antoine Pitrou added the comment:
I also get a failure here:
==
FAIL: test_default_timeout (test.test_threading.BarrierTests)
--
Traceback (most recent call
Antoine Pitrou added the comment:
Committed in r85975 (3.2). I guess we'll do a big svnmerge to other branches
later.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: +Python 3.2 -Python 3.3
___
Changes by Antoine Pitrou :
--
nosy: +loewis
stage: -> patch review
type: -> resource usage
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/i
Changes by Antoine Pitrou :
--
nosy: +orsenthil
stage: -> patch review
type: -> resource usage
versions: +Python 3.2 -Python 3.3
___
Python tracker
<http://bugs.python.org/i
Changes by Antoine Pitrou :
--
Removed message: http://bugs.python.org/msg119981
___
Python tracker
<http://bugs.python.org/issue10247>
___
___
Python-bugs-list m
Changes by Antoine Pitrou :
--
nosy: -donlorenzo
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10247>
___
__
Antoine Pitrou added the comment:
Committed in r85977, thanks.
--
nosy: +pitrou
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: +Python 3.2 -Python 3.3
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
Fixed in r85978, thank you.
--
nosy: +pitrou
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: +Python 3.2 -Python 3.3
___
Python tracker
<http://bugs.python.or
Changes by Antoine Pitrou :
--
stage: -> patch review
type: -> resource usage
versions: +Python 3.2 -Python 3.3
___
Python tracker
<http://bugs.python.org/i
Changes by Antoine Pitrou :
--
nosy: +amaury.forgeotdarc, benjamin.peterson
stage: -> patch review
type: -> resource usage
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.3
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
It should be closed only if closefd is true.
Does it fix a warning in the test suite? Otherwise I think it would need its
own test.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue10
Antoine Pitrou added the comment:
Confirmed on Python 3.2.
--
nosy: +haypo, loewis, pitrou
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issue10
Antoine Pitrou added the comment:
Committed in r85982, thank you. I will backport later.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
Not sure this is a blocker. There are various assembler syntaxes for x86 and
chances are LLVM uses a different one from gcc.
--
assignee: -> theller
nosy: +georg.brandl, pitrou, theller
___
Python tracker
&l
Antoine Pitrou added the comment:
The errno printed here is just an error which is expected and tested for. The
verbose run was ok, it's the silent run just before which produced an error (or
several), but unfortunately:
test test_ssl failed -- multiple errors occurred; run in verbose
Antoine Pitrou added the comment:
Committed in r85983, thank you.
--
nosy: +pitrou
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
Some comments about the patch:
- this seems to be some dead code:
if (nattrs <= 1) {
if (!PyArg_UnpackTuple(args, "attrgetter", 1, 1, &attr))
return NULL;
- you can't call PyUnicode_GET_SIZE or PyUnicode_AS_U
Changes by Antoine Pitrou :
--
type: feature request -> resource usage
versions: +Python 2.7, Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issu
Changes by Antoine Pitrou :
--
nosy: +eric.araujo, ncoghlan
___
Python tracker
<http://bugs.python.org/issue10263>
___
___
Python-bugs-list mailing list
Unsub
Antoine Pitrou added the comment:
The PyUnicode_GET_SIZE issue was still there, but I've fixed it and committed
in r86036. Thanks for your contribution!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: ope
Antoine Pitrou added the comment:
> It's possible that this change will lead to fds leaking if someone is
> passing in a fd
I don't think so, why do you say that?
That said, there's an indentation problem in your patch.
--
nosy: +pitrou
_
Changes by Antoine Pitrou :
--
nosy: +giampaolo.rodola, r.david.murray
stage: -> patch review
type: -> resource usage
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
Now that the previous patch has been committed, could you post a patch against
current SVN?
--
nosy: +pitrou
type: -> resource usage
versions: +Python 3.2 -Python 3.3
___
Python tracker
<http://bugs.pyth
Antoine Pitrou added the comment:
Oops, sorry. I hadn't seen that this was about a different function.
I've committed the patch in r86037.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.py
New submission from Antoine Pitrou :
This can be seen on all 3 branches:
$ ./python -m test.regrtest -uall -R 3:2 test_ttk_guionly
[306/349] test_ttk_guionly
beginning 5 repetitions
12345
.
test_ttk_guionly leaked [590, 590] references, sum=1180
--
components: Tkinter
messages
Antoine Pitrou added the comment:
I feel guilty of having said, some months ago, that "Well, I wouldn't say
bz2module is the best module out there, but as you say it's probably good
enough" (my words).
It's true that bz2module is not awful in terms of coding style or
Antoine Pitrou added the comment:
Committed in r86067. Thank you Brian!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Antoine Pitrou :
The issue here is that ssl is using its own exception class rather than the
socket module's "timeout" class:
test test_httplib failed -- Traceback (most recent call last):
File
"/Users/pythonbuildbot/buildarea/3.x.hansen-osx-
Antoine Pitrou added the comment:
I would prefer assertRegex to assertRegexp.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue10273>
___
___
Antoine Pitrou added the comment:
This looks useful indeed.
--
nosy: +jyasskin, pitrou
___
Python tracker
<http://bugs.python.org/issue10260>
___
___
Python-bug
Antoine Pitrou added the comment:
Right, IMAP_SSL should first accept an additional context argument as noted in
issue10274. Then it can be patched to optionally call ssl.match_hostname on the
server certificate. That second part can mimick what is done by HTTPSConnection:
http
Antoine Pitrou added the comment:
Sorry, the actual issue number is issue8808.
--
dependencies: +imaplib should support SSL contexts -imaplib should provide a
means to validate a remote server ssl certificate(s)
___
Python tracker
<h
Antoine Pitrou added the comment:
Well, the problem is that the "appropriate test" is not easy to guess a priori,
so it would be useful for the stdlib to provide the right tool for the job.
As for where it should live, I have no strong opinion, but it's true that the
ti
Antoine Pitrou added the comment:
> > Well, the problem is that the "appropriate test" is not easy to guess a
> > priori, so it would
> > be useful for the stdlib to provide the right tool for the job.
>
> This sounds like an argument against this feature, no
Changes by Antoine Pitrou :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue10281>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue10280>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Degrade; this old implementation (urllib vs urllib2) shoud be phased out IMO.
This issue shows that I was myself fooled by the urllib.request documentation.
--
___
Python tracker
<http://bugs.python.org/issue8
Changes by Antoine Pitrou :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue10287>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Just my 2 cents:
- I think dedocumenting the type-specific methods is fine (it doesn't mean
removing them, though); or perhaps relegate them to some advanced section
- It's unfortunate that the renaming suggestion comes so late; I'm not su
Antoine Pitrou added the comment:
> I spent some time thinking of a name. I tried wait_predicate and
> predicate_wait, but wait_for seemed natural. Any other ideas?
> How about wait_until_true?
wait_for is ok IMO.
> My original method had this as a free function, but I moved i
Antoine Pitrou added the comment:
Andrew, thank you for posting a patch.
I have a couple of comments:
* the command-line option for the SSLContext won't work, since a context is a
custom object, not a string; I would rework this part anyway, since I don't
think separate options fo
Antoine Pitrou added the comment:
Hirokazu's patch works for me.
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue10267>
___
_
Changes by Antoine Pitrou :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue10294>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
I would rename Py_BREAKPOINT to _Py_BREAKPOINT since we don't really want to
support this. Also, why do you allow any arguments to sys._breakpoint()?
--
nosy: +pitrou
___
Python tracker
<http://bugs.py
Antoine Pitrou added the comment:
> And my text string is "\xC9ric", that's all.
You mean b"\xC9ric", right?
> If you look at the source of the articles, you will for instance see
> that the Subject: header field is not MIME-encoded. It is directly
> writ
Antoine Pitrou added the comment:
Yes, there are probably many holes like this. I've done what I could to make
the simple cases (builtin types) to work, but the spec is rotten from the
start. Blame the numpy people, sorry.
--
nosy: +nco
Antoine Pitrou added the comment:
> As far as I know, PEP 3118 serves its purpose of allowing extension
> modules like numpy and PIL to share data without needing to copy it
> around all the time. It's just that memoryview wasn't really part of
> that purpose (since all th
Antoine Pitrou added the comment:
I've fixed it according to your suggestion (take the max of the advertised
version) in r86129. Thank you!
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.
Antoine Pitrou added the comment:
I am wondering how to return the corresponding information. Should the field be
totally absent from the returned dictionary, should it map to the empty string,
or should it map to None?
I'm leaning towards the latter (map to None), but perhaps the
Antoine Pitrou added the comment:
> Antoine, a news client could guess it because of the Content-Type:
> header field (in this example, it mentions charset="gb2312").
> Yet, articles without a Content-Type: header field exist in the
> wild...
Unless I'm mistaken, Con
Antoine Pitrou added the comment:
Here is a patch for returning None on absent fields.
(works with trigofacile.com)
--
keywords: +patch
Added file: http://bugs.python.org/file19471/nntpover.patch
___
Python tracker
<http://bugs.python.
Antoine Pitrou added the comment:
> Read the "Releasing the buffer" section in PEP 3118 again. Unless I'm
> misunderstanding you completely, the rules you're asking for are
> already in place: those fields are entirely the responsibility of the
> exporting obj
Antoine Pitrou added the comment:
> OK, thanks.
> By the way, why is the token stripped?
> token = token[len(h):].lstrip(" ")
>
> "X-Header: test \r\n" in an header is kept in the overview as-is.
> I do not see why " test " should
2101 - 2200 of 16792 matches
Mail list logo
