Antoine Pitrou added the comment:
Both patches look ok to me.
--
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue1441530>
___
___
Python-bug
Antoine Pitrou added the comment:
This occurs when running the GC and then calling the finalization of an IO
object, which temporarily resurrects the object to call its close() method:
#0 0x7fc20bc1609b in raise () from /lib64/libpthread.so.0
#1 0x005328e7 in
Antoine Pitrou added the comment:
Here is a quick script to reproduce. It seems that the type of the object has
to be caught in a reference cycle for this to happen: apparently the
descriptors start being deallocated but the method cache isn't updated yet (?).
--
Antoine Pitrou added the comment:
Ezio, in the meantime, you can simply put the FakeSocket declaration at the top
level.
--
___
Python tracker
<http://bugs.python.org/issue12
Antoine Pitrou added the comment:
Tarek, you must use LD_LIBRARY_PATH.
--
___
Python tracker
<http://bugs.python.org/issue10126>
___
___
Python-bugs-list mailin
Antoine Pitrou added the comment:
And apparently some buildbot doesn't like it:
http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/57/
==
FAIL: test_oscloexec (test.test_posix.PosixT
Antoine Pitrou added the comment:
> Python doesn't suppose atomic open+CLOEXEC anymore, I consider this as a
> regression from Python 2 (which support open("re") with the GNU libc).
It has never been documented (nor supported) so, no, I wouldn't consider
it a regr
Changes by Antoine Pitrou :
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue12155>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> I like this solution, but I don't know how to test that the kernel
> doesn't support O_CLOEXEC. My commit bff9265d677d will tell use the
> value of O_CLOEXEC on the
> "Linux-2.6.22-vs2.2.0.7-gentoo-i686-Intel-R-_Xeon-TM-_CP
Changes by Antoine Pitrou :
--
nosy: +charles-francois.natali, haypo
___
Python tracker
<http://bugs.python.org/issue10115>
___
___
Python-bugs-list mailin
Antoine Pitrou added the comment:
If there are use cases of Stream{Reader,Writer} which are not covered by
TextIOWrapper, it would be nice to know so that we can improve TextIOWrapper.
After all, there should be one obvious way to do it ;)
By the way, something interesting (probably
Antoine Pitrou added the comment:
> TextIOWrapper() is conceptually something completely different. It's
> more something like StreamReaderWriter().
That's a rather strange assertion. Can you expand?
TextIOWrapper supports read-only, write-only, read-write, unseekable and
Antoine Pitrou added the comment:
> Antoine, do you think we can commit this as-is (i.e. without specific
> test)?
Yes.
> If yes, to what branches (I'm not really sure of what kind of change is
> allowed for each branch, is there a document somewhere detailing the
> of
New submission from Antoine Pitrou :
Looks like either packaging or test_packaging forgets to clean up after itself:
results for 9a16fa0c9548 on branch "default"
test_packaging leaked [193, 193, 193] references, sum=579
--
assig
Antoine Pitrou added the comment:
IMO this was all obsolete long ago, when we replaced stdout-based comparison of
test results with proper assert* method calls.
--
___
Python tracker
<http://bugs.python.org/issue12
Antoine Pitrou added the comment:
> Probably because new extension modules are built and imported on every run.
Well, test_distutils does the same, doesn't it?
--
___
Python tracker
<http://bugs.python.org
Antoine Pitrou added the comment:
Let's see:
-> test_command_bdist_dumb.py leaks:
test_packaging leaked [7, 7] references, sum=14
-> test_dist.py leaks:
test_packaging leaked [65, 65] references, sum=130
-> test_mixin2to3.py leaks:
test_packaging leaked [60, 60] refer
Antoine Pitrou added the comment:
In test_command_bdist, the leak is in test_simple_built().
--
___
Python tracker
<http://bugs.python.org/issue12167>
___
___
Antoine Pitrou added the comment:
In test_mixin2to3.py, the leak is shared between the 3 test methods.
--
___
Python tracker
<http://bugs.python.org/issue12
Antoine Pitrou added the comment:
In test_pypi_dist, the leak is shared between test_download() and test_unpack().
--
___
Python tracker
<http://bugs.python.org/issue12
Antoine Pitrou added the comment:
That's not really useful. If you want to use an SSL context, build your own
opener:
opener = build_opener(HTTPSHandler(context=mycontext))
opener.open(...)
--
___
Python tracker
<http://bugs.python.org/is
Antoine Pitrou added the comment:
> BufferedReader.read() calls FileIO.read() until FileIO.read() returns
> an empty byte string. Why not calling FileIO.read() only once?
BufferedReader doesn't call FileIO.read, it calls .read().
The latter can be e.g. a socket and call recv(). If
Antoine Pitrou added the comment:
> FileIO.readall() reads the file position and size before each call to
> read(), to adjust the buffer size.
>
> Moreover FileIO.readall() calls lseek() on Windows: it should use
> _lseeki64() instead, to handle correctly file bigger than 2 GB (
Antoine Pitrou added the comment:
+raw = f
+if hasattr(raw, 'buffer'):
+raw = raw.buffer
+if hasattr(raw, 'raw'):
+raw = raw.raw
f.close()
self.assertRaises
Antoine Pitrou added the comment:
> bufferedreader_readall.patch: BufferedReader.read(None) calls
> raw.readall() if available.
Have you run any benchmarks?
--
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
About rawiobase_readall.patch: why do you use PyObject_Size() if you know
chunks is a list? PyList_GET_SIZE is much more efficient.
About bufferedreader_readall.patch:
+PyBytes_Concat(&data, all);
+if (data ==
Antoine Pitrou added the comment:
Ok, thanks for the patches. Some further comments:
- the function generating the flags should be exported (with a private name),
so that it can be reused by Lib/test/[test_]support.py. Duplicate code is
error-prone, especially when enumerating command-line
Antoine Pitrou added the comment:
Committed, thank you!
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
> So, SOCK_CLOEXEC is available.
> Note that I don't like the idea of falling back to FD_CLOEXEC since
> it's not atomic, and some people might rely on this.
> Can we close this issue?
Well, this is apparently a feature request for soc
Antoine Pitrou added the comment:
For the record, the best effort approach is already used in subprocess (check
subprocess_cloexec_pipe() in Modules/_posixsubprocess.c).
Speaking of which, the os module could expose the pipe2() function
Antoine Pitrou added the comment:
> So, do you think that fileio_readall.patch and
> bufferedreader_readall-2.patch should be commited, or these changes
> are useless?
They should be committed.
Thank you :)
--
___
Python track
Changes by Antoine Pitrou :
--
nosy: +haypo
type: performance -> resource usage
versions: +Python 3.3 -Python 2.6, Python 2.7
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
> > What needs to happen to get recvmsg() supported in Python?
>
> Well, I guess that the only reason is that no committer is motivated
> enough to bring this into Python: it's a rather large patch, and
> honestly, I'm not sure t
Antoine Pitrou added the comment:
> That's because of the _PyIO_ConvertSsize_t converter, which silently
> converts None to -1.
> There's probably a good reason for doing this in the _io module
I'm not sure about the original reason, but I find None as the default
Antoine Pitrou added the comment:
> My patch tries to fix interlaced read-write by always calling flush(),
Why do you need to call flush()? Can't you read from the buffer?
--
___
Python tracker
<http://bugs.python.org
Antoine Pitrou added the comment:
> "In CPython, json.dumps(o), by itself, is faster than json.dump(o,f),
> at the expense of using more space, because it creates the entire
> string at once, instead of incrementally writing each piece of o to f.
> However, f.write(json.dum
Changes by Antoine Pitrou :
--
resolution: accepted -> fixed
___
Python tracker
<http://bugs.python.org/issue1625>
___
___
Python-bugs-list mailing list
Un
Changes by Antoine Pitrou :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue9972>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Using your test script fixed (on Python 3.3), I get the following numbers:
Starting multiproc...done in 2.1014609336853027 s.
Starting futures...done in 20.209479093551636 s.
Starting futures "fixed"...done in 2.026125907897949 s.
So there's a
Antoine Pitrou added the comment:
> If being pretty is the only reason for this choice, then I think that
> documenting the method as
>
> method:: read([n])
>
> is simpler and cleaner .
>
> But you've got much more experience than me, so I won't argue a
Antoine Pitrou added the comment:
> Hmm, thinking about it, I don't see any reason to make the flags argument
> optional.
> Here's a patch changing that (also, pipe2 is now declared as METH_O instead
> of METH_VARAR
Antoine Pitrou added the comment:
> Note that I didn't test LMTP. Should I or is it obvious enough that the
> change is ok?
Thank you for the patch! I think it's ok. I'll give it a try and commit
if everything is alright.
--
_
Changes by Antoine Pitrou :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
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:
Didn't you forget to attach the patch?
--
___
Python tracker
<http://bugs.python.org/issue12021>
___
___
Python-bugs-list m
Antoine Pitrou added the comment:
Ok, the dependencies are now committed. Here is a new patch addressing
Charles-François' comments: select() is now called before each call to read()
when sentinels are given, to avoid race conditions.
--
stage: -> patch review
Added fi
Antoine Pitrou added the comment:
I'm not sure why you're creating a separate test file. There are already
signals-related tests in test_io. Also, perhaps you can reuse the idioms used
there, rather than spawn subprocesses.
--
stage: ->
Antoine Pitrou added the comment:
Well, the HTTP RFC does indicate that the redirection URI (in the Location
header: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30) must
be an absolute URI, but I also agree that using a relative URI in that context
is a common use-case
Antoine Pitrou added the comment:
I don't think readline is "special-cased":
$ echo "1/0" > logging.py
$ cpython/default/python
Python 3.3a0 (default:d8502fee4638+, Jun 6 2011, 19:13:58)
[GCC 4.4.3] on linux2
Type "help", "copyright", "c
Antoine Pitrou added the comment:
> If you make an HTTPS connection without checking the certificate, what
> security does it add?
Well, it does prevent the most trivial class of attacks (sniffing).
That said, Python has support for certificate checking, especially in 3.2+, so
you shou
Antoine Pitrou added the comment:
Indeed, I don't think that's appropriate. Also, it's not about ++ in general
but a particular use of it.
--
nosy: +gvanrossum, pitrou
resolution: -> rejected
status: open -> pending
type
Antoine Pitrou added the comment:
Which version of Python are you testing on? It works fine using 3.2 and 3.3
here, under Windows 7 64-bit.
Anyway, I would suggest to batch your write in smaller chunks (say, 2048 bytes
each). Also, you may try sendall() instead.
--
nosy: +pitrou
Antoine Pitrou added the comment:
The 3.x doc states that "GzipFile supports the io.BufferedIOBase interface,
including iteration and the with statement. Only the truncate() method isn’t
implemented". This implies that it also supports close().
--
nosy: +pitrou
versions: -
Changes by Antoine Pitrou :
--
nosy: +amaury.forgeotdarc
___
Python tracker
<http://bugs.python.org/issue12198>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> If there are a few of these idioms, I'm not against adding a new
> section to PEP 7 (something like the "Programming Recommendations"
> section in the PEP 8). It's just not worth doing it for the "*p++ =
> x;" idiom
Antoine Pitrou added the comment:
> The difference is that logging is not imported at startup. So, however
> os (and friends, there are a lot of modules in sys.modules at startup)
> is imported, it is different from how readline.so is imported.
For the record, os is imported by the _
Changes by Antoine Pitrou :
--
components: +Library (Lib) -Extension Modules
nosy: +r.david.murray
stage: -> patch review
type: -> behavior
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
I'm not sure if that's deliberate, but the new attributes don't appear in the
result repr():
>>> s = os.stat("LICENSE")
>>> s
posix.stat_result(st_mode=33204, st_ino=524885, st_dev=2053, st_nlink=1,
st_uid=500, st_
Antoine Pitrou added the comment:
So, concurrent.futures is fixed now. Unless someone wants to patch
multiprocessing.Pool, I am closing this issue.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
_
Antoine Pitrou added the comment:
Patch looks good to me, thank you :)
--
___
Python tracker
<http://bugs.python.org/issue12021>
___
___
Python-bugs-list mailin
Antoine Pitrou added the comment:
Why not use signalfd() when available?
--
___
Python tracker
<http://bugs.python.org/issue12187>
___
___
Python-bugs-list mailin
Antoine Pitrou added the comment:
> Sorry, I attached wrong example version. It uses repeated
> sslsock.write() of the same buffer after catching
> SSL_ERROR_WANT_WRITE. It delivers the full block but this is a
> blocking operation.
In "normal" non-blocking code you wou
Antoine Pitrou added the comment:
> ossaudiodev's writeall method doesn't check that the FD is less than
> FD_SETSIZE when passing it to FD_SET: since FD_SET typically doesn't
> do bound check, it will write to a random location in memory (in this
> case on the sta
Antoine Pitrou added the comment:
Victor, how can there be hundreds of crashes? Isn't the process supposed to
terminate when a crash occurs?
There are several crashes in test_signal, so it's not only test_multiprocessing:
Thread 0xa000d000:
File "/Users/db3l/buildarea/
Antoine Pitrou added the comment:
Well, I agree on the principle, but it is a change in behaviour and would
probably break some user code...
Perhaps by adding some new argument to the mmap constructor? (dup_fd = True)
--
___
Python tracker
<h
Antoine Pitrou added the comment:
Nit: when a patch gets committed and the issue closed, the preferred resolution
is "fixed" ;)
(see http://docs.python.org/devguide/triaging.html#resolution)
--
resolution: accepted -> fixed
___
P
Antoine Pitrou added the comment:
Good idea, and thanks for posting a patch! This is a new feature, so 3.3-only.
Also, you'll need to update the docs (Doc/library/zlib.rst, presumably) to add
the new module method/attribute (with a suitable "versionadded" tag).
Nitpicking:
Antoine Pitrou added the comment:
I don't see any discrepancy here (with Python 3.3). Under both Linux and
Windows, the client thread prints:
ERR [Errno 3] _ssl.c:1126: The operation did not complete (write)
done
The only difference is that the server thread receives 128KB under Linux
Antoine Pitrou added the comment:
> I started a draft in python. I am attaching the _pyio version along
> with tests. I will continue work on the C implementation and
> eventually documentation if this is well received. It seems
> straightforward, I am interested to see what yo
Antoine Pitrou added the comment:
See issue12197 for a related request.
--
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue8
Antoine Pitrou added the comment:
Is someone investigating this?
--
___
Python tracker
<http://bugs.python.org/issue12167>
___
___
Python-bugs-list mailin
Antoine Pitrou added the comment:
> I’m afraid I don’t understand enough to fix this. I looked at
> test_simple_built in test_command_bdist_dumb and found no C code
> involved.
It means that either packaging or test_packaging keeps references to
more and more objects.
You don't
Antoine Pitrou added the comment:
> Two patches attached:
> - a patch checking that the ossaudiodev object isn't closed
> - a patch adding _PyIsSelectable_fd()
In oss_check_closed.diff, you might want to add tests for the other
methods as well. Otherwi
Antoine Pitrou added the comment:
Less disruptive approach:
old_process = _current_process
_current_process = self
try:
util._finalizer_registry.clear()
util._run_after_forkers()
finally:
del old_process
This will delay
Antoine Pitrou added the comment:
> For oss_check_closed.diff, should I apply it to default only or to
> every branch?
Only default I'd say.
--
___
Python tracker
<http://bugs.python.
Changes by Antoine Pitrou :
--
nosy: +orsenthil
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue12315>
___
___
Python-bugs-list mai
New submission from Antoine Pitrou :
The 3.x buildbots are red following the latest commits:
==
ERROR: test_cfg_to_args (packaging.tests.test_util.UtilTestCase
Antoine Pitrou added the comment:
It's a potential security issue.
--
nosy: +neologix, rosslagerwall
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/i
Changes by Antoine Pitrou :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue7732>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
stage: test needed -> patch review
___
Python tracker
<http://bugs.python.org/issue2122>
___
___
Python-bugs-list mailing list
Un
Changes by Antoine Pitrou :
--
nosy: +flox
___
Python tracker
<http://bugs.python.org/issue12323>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +flox
___
Python tracker
<http://bugs.python.org/issue12322>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +flox
___
Python tracker
<http://bugs.python.org/issue12321>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
I would expect changing sys.platform will also break a lot of third-party code.
Perhaps sys.platform can still be 'linux2' under Linux 3.x? After all, there's
no significant change that deserves changing sys.platform.
-
Antoine Pitrou added the comment:
Hello,
Thanks for the patch.
>I would suggest making it a programming error for the overlapped
>object to be deallocated while the operation is still pending, and
>to print a RuntimeError if that happens. (This does not prevent us
>
Antoine Pitrou added the comment:
> > The change to sys.platform=='linux' would break code even on current
> > platforms.
>
> Correct. Compared to introducing 'linux3', I consider this the better
> change - it likely breaks earlier (i.e. when porting
Antoine Pitrou added the comment:
This code has changed a lot in Python 3.3 (it is now located in
Lib/multiprocessing/connection.py). Can you post a patch against the
development tip ("default" branch)?
See http://docs.python.org/devguide/setup.html if you need more i
Changes by Antoine Pitrou :
--
nosy: +orsenthil
___
Python tracker
<http://bugs.python.org/issue12319>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Antoine Pitrou :
The problem is that tearDown() tries to rmdir() the current directory, which is
forbidden under Solaris and returns EINVAL:
>>> os.getcwd()
'/home/antoine/t/t'
>>> os.rmdir("/home/antoine/t/t")
Traceback (most re
Changes by Antoine Pitrou :
--
assignee: -> tarek
components: +Distutils2
nosy: +alexis, tarek
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
Well, using $(prefix)/include to fetch development headers sounds like the
wrong strategy anyway. Just because you e.g. install into /usr/local doesn't
mean your zlib is inside /usr/local too.
And if that makes people use our own zlib headers by mi
Antoine Pitrou added the comment:
I can't reproduce. Victor?
Z:\default>PCbuild\amd64\python_d.exe
Python 3.3a0 (default, Jun 8 2011, 17:49:13) [MSC v.1500 64 bit (AMD64)] on
win32
Type "help", "copyright", "credits" or "license" for more in
Antoine Pitrou added the comment:
> pipe_interruptible.patch is a patch to support to making poll()
> interruptible. It applies on top of pipe_poll_2.patch.
Hmm, it seems to me that it should be done in _poll() instead. Otherwise,
recv() will not be interruptible, will it?
Also,
Antoine Pitrou added the comment:
Nick, you just have to write: tau = 2 * math.pi
and you're done.
> there are million of other constants
Actually, I've heard there are an infinity of them.
--
nosy: +pitrou
resolution: -> rejected
status:
Changes by Antoine Pitrou :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue12345>
___
___
Python-bugs-list mailing list
Unsubscri
Antoine Pitrou added the comment:
This is not a bug. With a non-blocking socket, the handshake itself is
non-blocking, so you have to be prepared to retry. Your snippet also fails
under Python 2.6 for me, so this isn't a regression either.
If you want to know how to do a non-blo
Antoine Pitrou added the comment:
> I am not getting the error in the handshake. I am getting it when
> transfering data, after a few Kbytes are already transfered.
Your traceback (and mine as well) occurs in wrap_socket() which itself calls
do_handshake(). I don't understand ho
Antoine Pitrou added the comment:
Ah, ok, looks like your messages crossed each other. Can you try to devise
another test case, then?
Or, at least, explain the context and how and where it fails?
--
___
Python tracker
<http://bugs.python.
Antoine Pitrou added the comment:
Note: the only significant changes in the ssl module on branch 2.7 have been
742d73a99425 and 7f99ac53014a.
> Protecting my "reads" retrying when getting this exception does the
> trick, but now my code is convoluted and never before I had
Antoine Pitrou added the comment:
> If now I can get a "retry" while writing, what is the logic?. Does
> Python retry automatically, internally?.
No, Python doesn't retry automatically. You have to call send() again with the
same buffer.
(if Python retried, it would ma
801 - 900 of 16792 matches
Mail list logo