Antoine Pitrou added the comment:
Ok. How about this patch now?
(I'm trying to solve this in a clean way :))
--
keywords: +patch
Added file: http://bugs.python.org/file18861/gildestroy.patch
___
Python tracker
<http://bugs.python.org/i
Changes by Antoine Pitrou :
--
nosy: +janssen
___
Python tracker
<http://bugs.python.org/issue8445>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
I agree that this follows Unix behaviour: a read-only file is a file whose
contents cannot be modified, but you can replace it with another totally
different file. You can also delete it, by the way (*).
Also, even if this weren't the desired beha
Changes by Antoine Pitrou :
--
stage: unit test needed ->
type: behavior -> feature request
versions: -Python 2.7, Python 3.1
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
Can you try using CC="cc -m64" OPT="-O3" instead?
(replace "cc" with the proper compiler name, of course)
--
nosy: +pitrou
___
Python tracker
<
Antoine Pitrou added the comment:
Fix committed in r84774. Thank you!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
> Right. That's why I'm thinking that we should introduce some. TLS
> creation *can* fail, and it is unfortunate that the original
> introduction of this API forgot to consider that. Your patch did
> (de facto) introduce an error return c
Antoine Pitrou added the comment:
> Is specifying CC the recommended way to build 64 bit python?
Currently, yes. LDFLAGS is supposed to work, but it doesn't (open bug: #9437).
--
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
Is there any point in creating another extension module?
We already have Modules/getpath.c which receives various configuration values
at compile-time, themselves exposed as sys.prefix and friends. The simpler the
better, IMO.
sysconfig can choose to expose
Antoine Pitrou added the comment:
Indeed. However, the ZipFile itself knows whether to close the file
(self._filePassed). By adding a constructor argument to ZipExtFile and a
__del__ method, it would solve the issue.
--
nosy: +pitrou
stage: -> needs patch
versions: +Python
Antoine Pitrou added the comment:
Here is an updated patch, but it's a work in progress.
Since we are breaking compatibility anyway, I think a larger cleanup is
deserved. For example:
- remove old exception aliases
- make return types consistent (for example, newgroups() should ret
Antoine Pitrou added the comment:
You shouldn't use DEBUG_LEAK except for debugging purposes :)
As the doc mentions: “To debug a leaking program call
gc.set_debug(gc.DEBUG_LEAK). Notice that this includes gc.DEBUG_SAVEALL,
causing garbage-collected objects to be saved in gc.garbag
Antoine Pitrou added the comment:
> cc_r does not seems to be able to compile py3k, so it seems to be a bad
> idea to force it by default.
Python should be able to compile with any C89-compliant compiler, so it seems a
good idea to open a bug for compile errors instead.
In this case, t
Antoine Pitrou added the comment:
Nice, thank you. I will look at the patch and commit it if everything's fine.
> A nicer solution is to simply make socket.socket actually be a simple
> subclass of _socket.socket rather than the weird decorator it is now.
> This has already h
Changes by Antoine Pitrou :
--
dependencies: +nntplib cleanup
___
Python tracker
<http://bugs.python.org/issue1926>
___
___
Python-bugs-list mailing list
Unsub
Antoine Pitrou added the comment:
It should be noted that there are two possibilities for encrypted NNTP:
- NNTPS, that is NNTP-over-SSL on port 563, as proposed here
- plain NNTP with the STARTTLS capability as described in RFC 4642
For the record, gmane provides the former (on
Changes by Antoine Pitrou :
--
nosy: +sable
___
Python tracker
<http://bugs.python.org/issue6164>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +sable
___
Python tracker
<http://bugs.python.org/issue6006>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> Antoine, any reason not to put the close in the ZipFileExt close method
> instead of a __del__ method? (And document it, of course).
You are right, a close() method would be enough.
Furthermore, ZipExtFile already supports the context manager pr
Antoine Pitrou added the comment:
The recvfrom() signature is wrong (it doesn't take an address argument). Here
is an updated patch.
--
Added file: http://bugs.python.org/file18880/issue9729-2.patch
___
Python tracker
<http://bugs.py
New submission from Antoine Pitrou :
SSLSocket.recvfrom includes an `addr` argument in its signature, but
socket.recvfrom doesn't take such an argument. It should be removed.
(obviously, this method is neither tested nor used in the real-world...)
In 2.7, this is taken care of by the pat
Antoine Pitrou added the comment:
sendto() has a similar problem. socket.sendto() takes (data, flags=0, addr),
but SSLSocket.sendto() incorrectly forwards the arguments. Updated patch
attached.
--
Added file: http://bugs.python.org/file18881/issue9729-3.patch
Antoine Pitrou added the comment:
Similar problem for sendto() (again, see issue9729).
socket.sendto() has an interesting signature (the middle `flags` argument is
optional, not the following `addr`...).
--
title: Wrong signature for SSLSocket.recvfrom -> Wrong signature
Antoine Pitrou added the comment:
Here is a further, still work-in-progress, patch. I'm posting it here so that
interested people can give advice.
--
Added file: http://bugs.python.org/file18882/nntplib_cleanup3.patch
___
Python tracker
Antoine Pitrou added the comment:
Patch committed in r84806.
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
Fixed in r84807 (3.x) and r84809 (3.1).
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Changes by Antoine Pitrou :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue1552>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Antoine Pitrou :
SocketIO claims to implement RawIOBase, but it lets blocking IO errors pass
through on non-blocking sockets:
>>> s = socket.create_connection(("python.org", 80)); s.settimeout(0.0)
>>> f = s.makefile("rb", bu
Antoine Pitrou added the comment:
socketpair() was fixed in 3.x in r84813.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
The problem with RawIOBase.read is fixed in r84814.
--
___
Python tracker
<http://bugs.python.org/issue9854>
___
___
Python-bug
Antoine Pitrou added the comment:
Here is a patch.
The tests are only run for unbuffered objects (buffering=0), since the
behaviour of buffered objects is driven by BufferedReader and friends, not by
the wrapped SocketIO.
--
keywords: +patch
nosy: +giampaolo.rodola
Added file: http
Changes by Antoine Pitrou :
Removed file: http://bugs.python.org/file18883/sockio_nonblock.patch
___
Python tracker
<http://bugs.python.org/issue9854>
___
___
Python-bug
Changes by Antoine Pitrou :
Added file: http://bugs.python.org/file18884/sockio_nonblock.patch
___
Python tracker
<http://bugs.python.org/issue9854>
___
___
Python-bug
New submission from Antoine Pitrou :
Raising SkipTest when in a tearDown method is reported as an error, rather than
a skipped test.
Now doing this sounds like a weird use case, but it would be actually useful
when you have a worker thread, and the tearDown method collects the exception
Antoine Pitrou added the comment:
Le mardi 14 septembre 2010 à 23:19 +, Giampaolo Rodola' a écrit :
> I've never used socket.socket.makefile so I'm not sure, but its
> documentation says:
>
> > The socket must be in blocking mode (it can not have a timeout).
Antoine Pitrou added the comment:
> It looks like 3.1 with computed gotos produces the yet another different
> tracing of list comprehensions:
>
>
> 2: l = [i for
>10: i in
> 1: range(10)]
Well, this kind of thing is going to depend on the exact
Antoine Pitrou added the comment:
You should make sure that all operations (except close() itself) raise
ValueError. Currently:
>>> f = gzip.open("test.gz", "rb")
>>> f.close()
>>> f.read()
b''
>>> f.seek(0)
0
Also, you
Changes by Antoine Pitrou :
--
Removed message: http://bugs.python.org/msg116438
___
Python tracker
<http://bugs.python.org/issue9315>
___
___
Python-bugs-list m
New submission from Antoine Pitrou :
RawIOBase is defined as having the readinto() method but it doesn't. It should
at least have a failing one (raising io.UnsupportedOperation like the
BufferedIOBase.{read,readinto} methods do).
This is, of course, mainly for auto-documenting purposes
Changes by Antoine Pitrou :
--
nosy: +benjamin.peterson, stutzbach
___
Python tracker
<http://bugs.python.org/issue9858>
___
___
Python-bugs-list mailin
Antoine Pitrou added the comment:
> +1 for a failing one. (Does the base implementation not raise?)
The base implementation doesn't exist :)
> Is it even possible to implement a real one without buffering?
FileIO does. It's the same as read(), except that you read into an
Antoine Pitrou added the comment:
It works here (Linux). Did you try make distclean first? Also, try to remove
the various files created by configure.
(what is VPATH?)
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue9
New submission from Antoine Pitrou :
They both return raw tuples, which are not very intuitive to interpret:
>>> email.utils.parsedate_tz("Wed, 15 Sep 2010 09:53:50 -0700 (PDT)")
(2010, 9, 15, 9, 53, 50, 0, 1, -1, -25200)
It would be much better if they returned some kind o
Antoine Pitrou added the comment:
By the way, while as mentioned in the docs “indexes 6, 7, and 8 of the result
tuple are not usable”, perhaps it would be time to fix it? (at least for 6 and
7, aka. wday and yday)
--
___
Python tracker
<h
Antoine Pitrou added the comment:
> Of course, I should have been more clear.
> What I meant is that there's no such thing as explicit and "native" as
> setblocking() for plain files.
Indeed. It would probably be a nice addition, assuming it is portable
enough.
> &g
New submission from Antoine Pitrou :
Ordered dicts pretend to have the memory consumption as dicts:
>>> import sys, collections
>>> sys.getsizeof({})
280
>>> sys.getsizeof(collections.OrderedDict())
280
--
components: Library (Lib)
messages: 116481
nosy:
Changes by Antoine Pitrou :
Added file: http://bugs.python.org/file18894/nntplib_cleanup4.patch
___
Python tracker
<http://bugs.python.org/issue9360>
___
___
Python-bug
Antoine Pitrou added the comment:
How do you want to "handle this in general"?
--
___
Python tracker
<http://bugs.python.org/issue9865>
___
___
Python-b
Antoine Pitrou added the comment:
As I said in #9315, I think this kind of thing (bytecode traces) is an
implementation detail; the changes in results shouldn't be regarded as breaking
compatibility.
The only problem I could see would be if a whole line of code would be
"
Antoine Pitrou added the comment:
> > How do you want to "handle this in general"?
>
> Possibly by adding up __sizeof__'s of base and __dict__ in a generated
> function? With a special handling of slots ...
I agree that in the general case this would be better
Changes by Antoine Pitrou :
--
nosy: +exarkun, giampaolo.rodola
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
> It appears that there is a known issue with Windows sockets where this
> type of problem may occur with non-blocking sockets. It is described in
> the msdn documentation for WSAAsyncSelect()
> (http://msdn.microsoft.com/en-us/library/ms74154
Antoine Pitrou added the comment:
Le jeudi 16 septembre 2010 à 11:13 +, Martin v. Löwis a écrit :
> Martin v. Löwis added the comment:
>
> > @Martin: yep, I know we still need to install pyconfig.h and
> > Makefile, but we shouldn't need to parse them to get program
Antoine Pitrou added the comment:
The patch looks good.
--
___
Python tracker
<http://bugs.python.org/issue9865>
___
___
Python-bugs-list mailing list
Unsub
Antoine Pitrou added the comment:
Some parts of the stdlib already retry manually (such as SocketIO, subprocess,
multiprocessing, socket.sendall), so it doesn't sound unreasonable for the IO
lib to retry too.
There are/were other people complaining in similar cases: #7978, #16
Antoine Pitrou added the comment:
> Because Python's signal handlers only set a flag and do the actual
> action later on blindly rerunning system calls when errno == EINTR may
> result in programs that don't seem to react to signals at all.
You just need to call PyErr_Check
Antoine Pitrou added the comment:
So it means we should indeed retry on a socket with timeout... But we must take
care not to exceed the original timeout, so we must measure the time taken by
each select() call.
--
___
Python tracker
<h
Antoine Pitrou added the comment:
> As there has been a lot of support for the attached patch what is
> needed to take this forward?
Read my 2010-06-17 message above. Someone needs to update the patch for 3.2,
and preferable show that it still brings an improvement (small micro-benc
Antoine Pitrou added the comment:
It was corrected between 2.6.5 and 2.6.6 (see r79291 and also potentially
r80453).
Here, on the 2.6 maintenance branch:
>>> import socket, time, ssl
>>> s = ssl.wrap_socket(socket.socket())
>>> s.connect(('linuxfr.org
Antoine Pitrou added the comment:
I don't really agree with "negative periods behave like if the period was 0".
Negative periods don't mean anything and should just raise ValueError.
(as for 0, well, we can allow it anyway, although it means the timer just
degenerates int
Antoine Pitrou added the comment:
> May I recommend using libtomcrypt instead of openssl because of the
> advertising problem outlined here?
Changing libraries because of an "advertising problem" doesn't sound
reasonable. The latter is much more easily solved than
Antoine Pitrou added the comment:
> How about nss? As a bonus, this would also avoid making more work for
> Fedora (<http://fedoraproject.org/wiki/FedoraCryptoConsolidation>).
Well, similar question: what will it bring and who will do the work? :)
(Fe
Antoine Pitrou added the comment:
Le vendredi 17 septembre 2010 à 23:14 +, Dave Malcolm a écrit :
> Dave Malcolm added the comment:
>
> On Fri, 2010-09-17 at 23:11 +, Antoine Pitrou wrote:
> > Antoine Pitrou added the comment:
> >
> > > How about nss
Antoine Pitrou added the comment:
> Attached result of a run with stdlib gzip module only. Results
> indicate that performance still is as bad as on Python 2. The Python 3
> gzip module also still makes use of tell() ans seek(). So both
> argument for including this patch are
Antoine Pitrou added the comment:
> What's a little bit odd is that there's a test for the __long__-
> returning-int behaviour in test_class that asserts the return type
> should be int.
If there is a test then the behaviour is probably deliberate, and changing it
would
Antoine Pitrou added the comment:
Apparently it has been fixed somewhere between 2.6.5 and 2.6.6. I get a
segmentation fault in 2.6.5, but an OverflowError in all of {2.6.6, 2.7, 3.1,
3.2}.
--
nosy: +pitrou
___
Python tracker
<h
Antoine Pitrou added the comment:
Barry's request looks reasonable. Any build information will have platform
specificities to it.
On the other hand, this begs the question of why you want to access the Python
makefile at all. Is there any information in there that isn't currently
Antoine Pitrou added the comment:
> There are plenty of tests that check implementation specific internal
> behaviors. I don't think the presence of test alone would mean that it
> can't be changed.
Right. In practice, returning a long instead of an int can produce bugs,
ma
Antoine Pitrou added the comment:
It consistently doesn't here:
0.10013985633850098
0.1001589298248291
(etc.)
What system are you using? There are two factors:
- accuracy of the timeout in the wait() function
- accuracy of the results returned by time()
Apart from a possible bug in P
Antoine Pitrou added the comment:
> You are right, sorry. It's Windows XP Prof, Python 3.2a2.
>
> The differences in OS may be the cause, but the problem doesn't appear
> in 3.1 on the same machine.
The implementation changed between 3.1 and 3.2. On 3.1, wait() with
time
Antoine Pitrou added the comment:
The patch works here (VS 2008).
--
___
Python tracker
<http://bugs.python.org/issue9552>
___
___
Python-bugs-list mailin
Antoine Pitrou added the comment:
Well, the core issue is a disagreement on the way to go.
I would agree with Benjamin's and Christian's proposal, given that it's quite
practical to implement. Guido's proposal means we would have to add new modules
just so that the rel
Antoine Pitrou added the comment:
I'm closing because there doesn't seem to be a genuine bug in Python. But
thanks for reporting anyway! The threading facilities in 3.2 need real-world
testing.
--
resolution: -> invalid
status: o
New submission from Antoine Pitrou :
While trying out vim, I noticed that the files in Misc/Vim are very poor
compared to what is otherwise provided by the vim community:
- highlighting including 3.x syntax:
http://www.vim.org/scripts/script.php?script_id=974
- PEP 8 indentation: http
Antoine Pitrou added the comment:
> Unfortunately, select doesn't necessarily update the timeout variable
> with the remaining time, so we can't rely on this. This would mean
> having the select enclosed within gettimeofday and friends, which
> seems a bit overkill...
W
Antoine Pitrou added the comment:
Fixed in r84878 (3.2), r84879 (2.7) and r84880 (3.1). Thank you!
--
nosy: +pitrou
resolution: -> fixed
status: open -> closed
versions: +Python 2.7, Python 3.1
___
Python tracker
<http://bugs.python.org/
New submission from Antoine Pitrou :
test_subprocess is currently very slow and the main culprit is test_no_leaking
(here, it takes 80s out of the 100s needed for the whole run). This tests
spawns as many subprocesses as would be needed to reach the max file descriptor
limit. Spawning a
Changes by Antoine Pitrou :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue9896>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> A few questions / clarifications:
>
> is errno.EMFILE portable? will that errno test work on both posix and
> windows?
It does (tested under Linux and a Win64 VM).
> should the is_resource_enabled('subprocess') stuff be preserv
Antoine Pitrou added the comment:
Here is a proof of concept patch for Python 3.2. It only wraps recv() and
recv_into(). recvfrom() and recvfrom_into() should receive the same treatment,
at least.
--
stage: -> patch review
Added file: http://bugs.python.org/file18
Changes by Antoine Pitrou :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue9090>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
Removed file: http://bugs.python.org/file18925/selectretry.patch
___
Python tracker
<http://bugs.python.org/issue9090>
___
___
Python-bug
Changes by Antoine Pitrou :
Added file: http://bugs.python.org/file18926/selectretry.patch
___
Python tracker
<http://bugs.python.org/issue9090>
___
___
Python-bugs-list m
Antoine Pitrou added the comment:
Done, thank you.
(r84883, r84884, r84885)
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
> It is also not a convincing argument that new python libraries should
> use OpenSSL if possible just because that is what _ssl uses. Compiling
> Python with OpenSSL support has been optional because it puts
> additional restrictions on the
Antoine Pitrou added the comment:
All buildbots are red.
--
assignee: tarek -> orsenthil
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
> Since libtomcrypt is public domain, you could incorporate the source
> into the tree without making it a binary dependency.
And then we have to maintain our copy ourselves. I'm not sure why you
think this is better than depending on a system-w
Antoine Pitrou added the comment:
Patch looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue9786>
___
___
Python-bugs-list mailing list
Unsub
Antoine Pitrou added the comment:
> It may be worthwhile investigating adding the EVP interface
> from evpy (with the ctypes bindings converted to real C wrappers)
> to pyOpenSSL and then adding the pyOpenSSL package to the stdlib.
pyOpenSSL being LGPL'ed, I'm not sure this
Antoine Pitrou added the comment:
> pyOpenSSL is stable, in production use and
> has a decent API. The ssl module is good enough for HTTPS client
> use. pyOpenSSL provides a robust server side implementation with
> all the required certificate and context handling needed for this.
&
Changes by Antoine Pitrou :
--
assignee: -> jnoller
nosy: +jnoller
___
Python tracker
<http://bugs.python.org/issue9897>
___
___
Python-bugs-list mai
Antoine Pitrou added the comment:
You can look at Python/compile.c (the ast-to-bytecode compiler),
Python/peephole.c (the bytecode optimizer), Python/marshal.c (the on-disk
bytecode serializer/unserialize).
First step could be to actually disable the optimizer (see PyCode_Optimize in
Antoine Pitrou added the comment:
Here is the current state of the cleanup work. Coding is roughly finished; most
methods are unit-tested. The documentation remains to be done. Review welcome.
--
stage: -> patch review
Added file: http://bugs.python.org/file18931/nntplib_clean
Changes by Antoine Pitrou :
Removed file: http://bugs.python.org/file18928/unnamed
___
Python tracker
<http://bugs.python.org/issue8998>
___
___
Python-bugs-list mailin
Antoine Pitrou added the comment:
> To make the distinction easier to remember, would it help if the
> methods that are currently set to return bytes instead accepted the
> typical encoding+errors parameters, with parallel *b APIs to get at
> the raw bytes?
Not really, no. For
New submission from Antoine Pitrou :
test_finalize_with_trace (in test_threading) sometimes fails because of failing
to destroy the GIL (in _PyEval_FiniThreads()). This can be reproduced quite
reliably by launching several copies in parallel:
$ ./python -m test.regrtest -j10 -F test_threading
New submission from Antoine Pitrou :
Under the "x86 debian parallel 3.x" buildbot, there's the following failure:
==
FAIL: test_undecodable_env (test.test_subprocess.POSIX
Antoine Pitrou added the comment:
It can be reproduced quite easily with the right locale:
$ LANG=fr_FR.iso8859-1 ./python -m test.regrtest -v test_subprocess
--
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
Fix attempted in r84912.
--
___
Python tracker
<http://bugs.python.org/issue9902>
___
___
Python-bugs-list mailing list
Unsub
Antoine Pitrou added the comment:
The test fails mostly on very slow machines (not only BSD ones, but also the
Debian sparc buildbot).
Therefore, I've attempted a fix in r84910 by relaxing timings, and simply
skipping the test if it seems we couldn't send the sign
1601 - 1700 of 16792 matches
Mail list logo
