Changes by Antoine Pitrou :
--
versions: +Python 3.2, Python 3.3 -Python 2.4, Python 3.0
___
Python tracker
<http://bugs.python.org/issue6434>
___
___
Python-bug
Antoine Pitrou added the comment:
Here is a patch that fixes some of these handle leaks in Python 3.2.
However, as a general guideline, you shouldn't unload the Python DLL if you
fish to use it later again. Just keep it in memory (the DLL isn't very big, is
it?). Yes, C++ would allo
Antoine Pitrou added the comment:
This is a really weird error. At this point, the child is waiting for a
challenge from the parent, and the challenge is something like 32 bytes long:
message = os.urandom(MESSAGE_LENGTH)
connection.send_bytes(CHALLENGE + message)
So, this can only
Antoine Pitrou added the comment:
Why would you catch IOError after os.mkdir()?
--
___
Python tracker
<http://bugs.python.org/issue13286>
___
___
Python-bug
Changes by Antoine Pitrou :
--
nosy: +orsenthil
___
Python tracker
<http://bugs.python.org/issue13287>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> default - str + shutil.quote_ascii_whitespace
> !q - str + shlex.quote
> !u - unquoted (i.e. no conversion, str.format default behaviour)
The default doesn't look very understandable to me. Why would you quote only
some characters and n
Antoine Pitrou added the comment:
> With the default whitespace escaping (which allows spaces in
> filenames), wildcard matching still works (thus the list of
> directories matching the "../py*" pattern), but with full quoting it
> breaks (thus the "nothing n
Antoine Pitrou added the comment:
It's available in 3.3:
>>> ctx = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
>>> ctx.verify_mode = ssl.CERT_REQUIRED
>>> ctx.set_default_verify_paths()
>>> with ctx.wrap_socket(socket.socket()) as sock:
... sock.co
Antoine Pitrou added the comment:
> If the handle leaks are restricted to the windows implementation of cpython,
> could it not be justified to allow C++ in a patch, I can't think of a C only
> compiler for windows?
Well, I think that would be rather clumsy. I'm not a
Antoine Pitrou added the comment:
> What would you envisage the API for the custom opener to look like?
The same as os.open(), I would say.
--
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
> Before I implement it properly, is this the kind of api that's desired?
Yes, although I think most people would use a closure instead of a dedicated
class.
--
___
Python tracker
<http://bugs
Antoine Pitrou added the comment:
Here is my quick review:
- shouldn't the opener also get the third open() argument (although it
currently seems to always be 0o666)?
- when fdobj is NULL, you shouldn't override the original error
- PyLong_AsLong can fail (if the opener returns to
Antoine Pitrou added the comment:
This looks good to me. I'm slightly worried about what happens when there's a
stale tmp file (for example if the Python process crashed before renaming it).
--
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
> Here's a patch using pseudo-random filenames.
> I used id(path) to generate a random name: it's faster than getpid(),
> and doesn't pollute strace's output (I'm one of strace's biggest
> fan :-).
If you go that way,
Antoine Pitrou added the comment:
> Updated patch:
> * checks for long overflow
> * raises original exception if opener returns null
> * makes it explicit that "opener" must return an open file descriptor.
This looks good to me. You just need to add a "versi
Antoine Pitrou added the comment:
> Here's a patch for Python/import.c using mkstemp(3). AFAICT, mkstemp
> should always be available (on Unix of course).
This looks fine to me. The code simplification tastes good :)
--
___
Python tra
Antoine Pitrou added the comment:
Apparently buildbot failures are caused by this commit:
==
ERROR: test_datetime_before_1900 (test.test_xmlrpc.XMLRPCTestCase
Antoine Pitrou added the comment:
> I am currently working with Bob Arendt (a colleague who works
> frequently with Fedora) to try to put the
> -fno-builtin-memcmp in the .spec file for their Python
Wouldn't it be better to have it enabled by defaul
Antoine Pitrou added the comment:
> > Note we only really see the effect if we make sure that gcc
> > isn't emitting its "special" memcmp: that's why the -fno-builtin-memcmp
> > is SO important on gcc builds!
>
> I'd rather infer the opposite:
Antoine Pitrou added the comment:
Instead of rewriting your own RawIO implementation, why not use _open_osfhandle?
This should be simple now with the "opener" argument.
http://msdn.microsoft.com/en-us/library/bdts1c9x.aspx
--
nos
Antoine Pitrou added the comment:
It's already in the 3.x docs (but not 2.x):
“Strings and buffers
These formats allow to access an object as a contiguous chunk of memory. You
don’t have to provide raw storage for the returned unicode or bytes area. Also,
you won’t have to releas
Antoine Pitrou added the comment:
> why not use _open_osfhandle?
>
> Because it is wrapper for other CRT functions for Windows, like
> close(). In other words it is an emulation. I think Python should not
> create wrapper around wrapper around wrapper...
Why do you think it mak
Antoine Pitrou added the comment:
> > Why do you think it makes a difference?
> Because adding one more dependency on unneeded libraries add the pain.
MSVCRT is unneeded?? What are you talking about?
> Also it limit us on very restricted API of that wrapper. Windows
> native AP
Antoine Pitrou added the comment:
A couple of things:
- the tests are skipped with "unable to bind RDS socket" here (even under
root). Is it expected?
- socket.error is the same as OSError now
- there are some ResourceWarnings abount unclosed sockets when running
Changes by Antoine Pitrou :
--
assignee: -> tarek
components: +Distutils, Distutils2
nosy: +alexis, eric.araujo, loewis, tarek
versions: +Python 3.3 -Python 2.7
___
Python tracker
<http://bugs.python.org/issu
Changes by Antoine Pitrou :
--
components: +IO, Library (Lib)
nosy: +pitrou
versions: -Python 2.6, Python 3.1, Python 3.4
___
Python tracker
<http://bugs.python.org/issue13
Antoine Pitrou added the comment:
Please also see the proposed PEP 3155 -
http://mail.python.org/pipermail/python-ideas/2011-October/012609.html
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue13
Antoine Pitrou added the comment:
> Thoughts?
I would say go for the simpler (that's probably option 3).
--
___
Python tracker
<http://bugs.python.org
Changes by Antoine Pitrou :
--
nosy: +brett.cannon, georg.brandl, ncoghlan
___
Python tracker
<http://bugs.python.org/issue13328>
___
___
Python-bugs-list mailin
Antoine Pitrou added the comment:
Should be fixed now (verified here on Mageia).
--
dependencies: -distutils doesn't byte-compile .py files to __pycache__ during
installation
nosy: +pitrou
resolution: -> fixed
stage: -> committed/rejected
status: ope
Changes by Antoine Pitrou :
--
nosy: +giampaolo.rodola, josiahcarlson, stutzbach
stage: -> patch review
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Changes by Antoine Pitrou :
--
nosy: +brett.cannon, ncoghlan
___
Python tracker
<http://bugs.python.org/issue13314>
___
___
Python-bugs-list mailing list
Unsub
Changes by Antoine Pitrou :
--
nosy: +giampaolo.rodola, josiahcarlson, neologix, stutzbach
stage: -> patch review
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
You have a possible failure here:
+# Set to the current time in the old explicit way.
+os.utime(support.TESTFN, None)
+st1 = os.stat(support.TESTFN)
+# Set to the current time in the new way
+os.utime(support.TESTFN
Antoine Pitrou added the comment:
I think the current behaviour is fine, in that the alternatives are not better
at all. In the absence of a type inherently "superior" to the others (as float
can be to int, except for very large integers :-)), it makes sense to keep the
type of the
Antoine Pitrou added the comment:
I would specify an even smaller "places". We have very slow buildbots.
You could first call utime() with a date far away in the past if you want.
--
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
> The `delta` keyword would actually be better than `places`, especially
> on the slower buildbots. delta=10 would allow up to 10 seconds between
> those utime calls. Is that being too permissive?
I think it's ok. We don't have to test
Antoine Pitrou added the comment:
> I'd still do it like this for portability's sake:
>
> + -find $(srcdir) -depth -name '__pycache__' -exec rm -rf {} ';'
Then you'd probably reintroduce issue8665.
--
_
New submission from Antoine Pitrou :
The utf-7 codec happily encodes lone surrogates, but it won't decode them:
>>> "\ud801".encode("utf-7")
b'+2AE-'
>>> "\ud801\ud801".encode("utf-7")
b'+2AHYAQ-'
>>> &
Antoine Pitrou added the comment:
> No, the -depth argument avoids that.
Ah, you are right, my bad.
--
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
Be aware that execfile() is a simple function call and can be used in any
expression.
--
nosy: +benjamin.peterson, pitrou
___
Python tracker
<http://bugs.python.org/issue13
Changes by Antoine Pitrou :
--
priority: normal -> deferred blocker
___
Python tracker
<http://bugs.python.org/issue13309>
___
___
Python-bugs-list mai
Antoine Pitrou added the comment:
> Wierdly, it looks like BlockingIO is not raised anywhere in the code
> for the C implementation of io.
That would explain why it isn't raised :)
This is a hairy issue: read(n) is documented as returning either n bytes or
nothing. But what if
Changes by Antoine Pitrou :
--
nosy: +giampaolo.rodola, josiahcarlson, stutzbach
___
Python tracker
<http://bugs.python.org/issue12498>
___
___
Python-bugs-list m
Antoine Pitrou added the comment:
> Also, the advantage of the current approach is that at least, no data
> is ever lost
But what about the buggy readline() behaviour?
--
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
> Note that Java's BufferedInputStream and ReadableByteChannel also
> return partial reads.
Apparently, they are specified to, even for blocking streams (which I find a
bit weird, and the language in the docs seems deliberately vague). Python&
Antoine Pitrou added the comment:
> There cannot be a reason input() should be confined to "strict", or can
> there? ;-)
Actually, there's a good reason: in the non-interactive case, input() simply
calls sys.stdin.read(), which doesn't have encoding or error
Antoine Pitrou added the comment:
Here is a patch. The bugfix itself is quite pedestrian, but the test is more
interesting. I did what I could to fork a subprocess into a pseudoterminal so
as to trigger the GNU readline code path. The only limitation I've found is
that I'm unab
Antoine Pitrou added the comment:
> >> But what about the buggy readline() behaviour?
> > Just tell people that if the return value is a string which does not
> > end in '\n' then it might caused by EOF or EAGAIN. They can just call
> > readline() again t
Antoine Pitrou added the comment:
> However when I try your example I get
>
> sys.stdin = io.TextIOWrapper(
> sys.stdin.detach(), 'ascii', 'replace')
> ValueError: underlying buffer has been detached
Which version of Python (and which OS?). It wo
New submission from Antoine Pitrou :
This decrepancy between 2.x and 3.x is witnessed under Windows:
Python 2.7.1 (r271:86832, Nov 27 2010, 17:19:03) [MSC v.1500 64 bit (AMD64)] on
win32
Type "help", "copyright", "credits" or "license" for more
Antoine Pitrou added the comment:
discrepancy, not decrepancy :S
(10038 is WSAENOTSOCK, by the way)
--
___
Python tracker
<http://bugs.python.org/issue13
Antoine Pitrou added the comment:
> I can make it work at the interpreter prompt with your patch applied.
> Sorry for cluttering up the ticket. ;-)
That's ok, thanks a lot for testing.
--
___
Python tracker
<http://bugs.python.
Antoine Pitrou added the comment:
> Finally, since writting a such code is tricky, what do you - all -
> think of making this a generic walker method that would take as
> argument the methods to call on a directory and on a file (or link),
> so that we could reuse it to wri
Antoine Pitrou added the comment:
Oops, sorry. I wonder if it would be possible to test the address returned by
recvfrom(). Same for the flags and ancillary data in recvmsg().
--
___
Python tracker
<http://bugs.python.org/issue7
Antoine Pitrou added the comment:
I also get this error on Mageia. If this can't be fixed, the test should be
skipped or removed.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/is
Antoine Pitrou added the comment:
Committed. I hope the test won't disturb the buildbots.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.pyth
Antoine Pitrou added the comment:
It's because of the cyclic garbage collector. If you call gc.disable() at the
beginning of your benchmark, you'll see that runtimes get more similar in both
cases.
You can also use tuples instead of lists as much as possible, it will reduce
press
Antoine Pitrou added the comment:
Nick, perhaps you want to have a look at http://hg.python.org/features/pathlib/
(it doesn't have a filter_walk equivalent but it could grow one :-))
--
nosy: +pitrou
___
Python tracker
<http://bugs.py
Antoine Pitrou added the comment:
> By always sending capabilities at connection, some servers immediately
> throw an error. I've modified the class initialization to include an
> optional parameter to indicate if this should be disabled.
Which kind of error? As Julien says, w
Antoine Pitrou added the comment:
> What value should we assign to sock->sock_timeout if SOCK_NONBLOCK was
> specified in accept4() call?
The same value as for other non-blocking sockets, IMO.
> And in socket.py should we check as in original accept:
> if getdefaulttimeou
Antoine Pitrou added the comment:
> > The same value as for other non-blocking sockets, IMO.
> There are three possible values I think:
> 1. parent's current sock_timeout
> 2. global default socket timeout
> 3. 0
>
> Can you please tell which one? I assume it sh
Antoine Pitrou added the comment:
> I think the best thing would be to let rmtree fail (provided it closes
> all the FDs it opened)
Agreed.
--
___
Python tracker
<http://bugs.python.org/
Changes by Antoine Pitrou :
--
nosy: +neologix
___
Python tracker
<http://bugs.python.org/issue6397>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Antoine Pitrou :
The 3.x Windows buildbots all fail in test_pep277.
==
FAIL: test_open (test.test_pep277.UnicodeFileTests)
--
Traceback
Antoine Pitrou added the comment:
> Anyway, we can keep using "localhost", but just delete the socket
> timeout in the server.
Please don't. Any problem might then hang the whole test suite.
You can bump it up if you want, though.
> About using getsockname(), the bind
Antoine Pitrou added the comment:
> Please, review attached changeset.
Doesn't look acceptable to me.
--
___
Python tracker
<http://bugs.python.org
Antoine Pitrou added the comment:
> If thread.join had a timeout , we could wait for a while and if the
> thread is still active, do a fake connection and another join.
What's wrong with a socket timeout exactly? Everything you're proposing
is ten times more complicated,
Antoine Pitrou added the comment:
> Antoine, the problem with this test is the timeout. We can set an
> arbitrary timeout, but how big is big enough?.
I would say answering this question is your task, since you have access
to that buildbot.
> The only "cosmetic" pro
Antoine Pitrou added the comment:
> Antoine: Then you would be satisfied if I increase the timeout from 3
> seconds to 60 seconds and clean the event signaling?
Yes!
--
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
> Consider too that if something goes bad enough in the test to skip the
> teardown method,
Such as? tearDown is normally like a "finally" block, it always gets
executed (unless perhaps setUp fails).
--
__
Antoine Pitrou added the comment:
> Stupid mistake. Please, review b93657b239a5.diff (erroneous "sock.close()"
> deleted)
Looks good to me, thanks.
--
___
Python tracker
<http://bugs.py
Changes by Antoine Pitrou :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue13373>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +neologix
stage: -> patch review
versions: +Python 2.7, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Changes by Antoine Pitrou :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue6397>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> That was thorough :-) Seems OK though.
>
> +if (n < size) {
> +PyErr_SetString(PyExc_IOError, "failed to write all pollfds. "
> +"Please, report in http://bugs.python.org/";);
>
> I
Antoine Pitrou added the comment:
> Like any named tuple, the benefits lie in the better repr, and the fact
> that if you only want some fields you don't have to unpack the whole
> tuple.
But, given the common idiom shown by Benjamin, how likely is it that you
manipulate t
Antoine Pitrou added the comment:
Patch committed, thank you for contributing!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
Hi,
> Testing the patch a bit more thoroughly, I found that data received
> from the readable end of the pipe can be corrupted by the C
> implementation. This seems to be because two of the previously
> dormant codepaths did not properly
Antoine Pitrou added the comment:
> Do you mean self->raw_pos should give the same answer as
> self.raw.tell()? (But that seems to be the definition of
> self->abs_pos.) Or is it the buffer offset which corresponds to
> self.raw.t
Antoine Pitrou added the comment:
I've committed an improved version (which also optimizes seek(0); read()).
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.pyth
Antoine Pitrou added the comment:
It is definitely a glibc issue. Here's a C snippet to reproduce:
"""
#include
#include
int main() {
time_t t;
struct tm tmp;
char str[200];
t = time(NULL);
tmp = *gmtime(&t);
tmp.tm_gmtoff = 0;
tmp.tm_zo
Antoine Pitrou added the comment:
> Has it been reported?
Yes, in http://sourceware.org/bugzilla/show_bug.cgi?id=13401
--
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
As Eric, I don't really think it's useful, and it might actually be confusing
(people will start wondering if there's a difference between 0 and NOFLAGS).
--
nosy: +pitrou
___
Python
Antoine Pitrou added the comment:
> Antoine, I appreciate that you took time to fix this bug while I was
> without Internet and without Windows, but unfortunately I will have to
> backout your commit. Postel’s Law doesn’t win here: It is documented
> that the MANIFEST template
Antoine Pitrou added the comment:
> > A "commit adding problem" should be fixed or reverted
> The point is that fixing it may take tome. Reverting is fine by me.
But we have no way of knowing you will be taking tome to do it.
Ideally, you should have reverted it yourself (
Antoine Pitrou added the comment:
I don't think there's a point in adding such an extra argument.
Why don't you just write
self.assertIs(type(myobj), sometype)
? How is the error message not good enough?
--
nosy: +pitrou
___
New submission from Antoine Pitrou :
Complete gc collections currently clear all freelists, except for the freelist
of list objects. Attached patch fixes the omission.
--
components: Interpreter Core
files: listfreelist.patch
keywords: patch
messages: 147530
nosy: pitrou
priority
New submission from Antoine Pitrou :
This patch adds a counting of the number of allocated memory blocks (through
the PyObject_Malloc API). Together with -R, it can help chase those memory
leaks which aren't reference leaks (see c6dafa2e2594).
The sys.getallocedblocks() function is
Antoine Pitrou added the comment:
Victor, can you fix the test failures on Windows and 2.7?
Otherwise the commit should be reverted.
--
___
Python tracker
<http://bugs.python.org/issue7
Antoine Pitrou added the comment:
Dicts also have a freelist which isn't freed either. New patch attached.
--
Added file: http://bugs.python.org/file23672/listdictfreelist.patch
___
Python tracker
<http://bugs.python.org/is
Antoine Pitrou added the comment:
Two things:
- you duplicated the part with "CFUNCTYPE(c_int)(lambda: None)" without
removing the original chunk of code
- some platforms can't compile ctypes, you must handle that case in regrtest
Otherwise, good idea.
-
Antoine Pitrou added the comment:
Fix the return values and add documentation.
--
Added file: http://bugs.python.org/file23673/listdictfreelist.patch
___
Python tracker
<http://bugs.python.org/issue13
Changes by Antoine Pitrou :
--
title: Clear lists freelist in gc.collect() -> Clear lists and dicts freelist
in gc.collect()
___
Python tracker
<http://bugs.python.org/issu
Changes by Antoine Pitrou :
Removed file: http://bugs.python.org/file23672/listdictfreelist.patch
___
Python tracker
<http://bugs.python.org/issue13389>
___
___
Python-bug
New submission from Antoine Pitrou :
#13146 solved the issue of writing pyc files under POSIX. Under Windows, the
problem still exists, as the following buildbot failure shows:
[317/360] test_multiprocessing
Traceback (most recent call last):
File "", line 1, in
File
"D:\c
Changes by Antoine Pitrou :
--
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue13391>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Antoine Pitrou :
The main current user of BufferedReader.read1() is TextIOWrapper. In this
context, read1() is used to signal that we want to bypass binary buffering as
much as possible, since TextIOWrapper does its own buffering. The current
read1() implementation is
Changes by Antoine Pitrou :
Added file: http://bugs.python.org/file23676/textioread.patch
___
Python tracker
<http://bugs.python.org/issue13393>
___
___
Python-bugs-list m
Antoine Pitrou added the comment:
Thanks for the comments, here is a new patch addressing them.
I've kept the C API available in all builds (since it's private), but
sys.getallocatedblocks() is only available in debug builds.
As for the memory leak run results, I think we may have t
201 - 300 of 16792 matches
Mail list logo
