I haven't yet tried posting a query to a FreeBSD list, as it could simply
be a bug on amd64, but I was wondering whether there was anything (other
than deactivating tests and documenting use of ulimit -v on this
platform) that could be done to work around this behaviour.
I think it should be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Barry Warsaw wrote:
On behalf of the Python development team and the Python community, I am
happy to announce the first release candidate for Python 2.6.
In http://www.python.org/download/releases/2.6/ , release date for
2.6rc1 is 20-Aug-2008. That
Benjamin Peterson wrote:
def engage_py3k_warning():
flag = ctypes.c_int.in_dll(ctypes.pythonapi, Py_Py3kWarningFlag)
flag.value = 1
Note that tricks like this won't necessarily enable all python 3
warnings for modules that have been imported before the flag gets set.
To avoid
Hi Nick,
I am aware of that (but others might not, so you are right to point this
out).
I did follow both Christian's and Benjamin's suggestions. The
implementation at the mod_wsgi C level, which is before any module
loading is more permanent, but the ctypes trick doesn't require an
apache2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 17, 2008, at 5:59 AM, Jesus Cea wrote:
Barry Warsaw wrote:
On behalf of the Python development team and the Python community,
I am
happy to announce the first release candidate for Python 2.6.
In
Martin v. Löwis wrote:
I haven't yet tried posting a query to a FreeBSD list, as it could simply
be a bug on amd64, but I was wondering whether there was anything (other
than deactivating tests and documenting use of ulimit -v on this
platform) that could be done to work around this behaviour.
On Sep 17, 2008, at 10:53 AM, Andrew MacIntyre wrote:
Martin v. Löwis wrote:
I haven't yet tried posting a query to a FreeBSD list, as it could
simply
be a bug on amd64, but I was wondering whether there was anything
(other
than deactivating tests and documenting use of ulimit -v on this
Unbelievable as this may seem, this crazy over-committing malloc
behavior is by now a classic -- I first fought against it in 1990,
when IBM released AIX 3 for its then-new RS/6000 line of workstations;
in a later minor release they did provide a way to optionally switch
this off, but, like on
I'll take this up with FreeBSD folk, but I'm open to ideas as to how
best to deal with the problem in the context of the test suite pending
resolution by FreeBSD.
Not sure what the test purpose is: if it is to test that you get a
MemoryError in cases where you ask for more than Python could
On Wed, Sep 17, 2008 at 08:21:55AM -0700, Alex Martelli wrote:
Unbelievable as this may seem, this crazy over-committing malloc
behavior is by now a classic -- I first fought against it in 1990,
when IBM released AIX 3 for its then-new RS/6000 line of workstations;
in a later minor release
Giampaolo Rodola' [EMAIL PROTECTED] wrote:
2 - By reading ssl.py code I noticed that when do_handshake_on_connect
flag is False the do_handshake() method is never called. Is it
supposed to be manually called when dealing with non-blocking sockets?
Yes. Look at the example client in
Giampaolo Rodola' [EMAIL PROTECTED] wrote:
I change my question: how am I supposed to know when the SSL hanshake
is completed? When pending() returns False?
When do_handshake() doesn't raise an exception.
Bill
___
Python-Dev mailing list
Giampaolo Rodola' [EMAIL PROTECTED] wrote:
In the meanwhile I noticed something in the ssl.py code which seems to
be wrong:
def recv (self, buflen=1024, flags=0):
if self._sslobj:
if flags != 0:
raise ValueError(
non-zero flags
2008-09-17 15:46:19 Barry Warsaw napisał(a):
On Sep 17, 2008, at 5:59 AM, Jesus Cea wrote:
Barry Warsaw wrote:
On behalf of the Python development team and the Python community,
I am
happy to announce the first release candidate for Python 2.6.
In
Ah, now I remember. It seems that sometimes when SSL_ERROR_WANT_READ
was returned, things would block; that is, the handle_read method on
asyncore.dispatcher was never called again, so the SSLSocket.recv()
method was never re-called. There are several levels of buffering going
on, and I never
On Wed, 17 Sep 2008 10:40:01 PDT, Bill Janssen [EMAIL PROTECTED] wrote:
Ah, now I remember. It seems that sometimes when SSL_ERROR_WANT_READ
was returned, things would block; that is, the handle_read method on
asyncore.dispatcher was never called again, so the SSLSocket.recv()
method was never
Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On Wed, 17 Sep 2008 10:40:01 PDT, Bill Janssen [EMAIL PROTECTED] wrote:
Ah, now I remember. It seems that sometimes when SSL_ERROR_WANT_READ
was returned, things would block; that is, the handle_read method on
asyncore.dispatcher was never called
On Sep 17, 2008, at 12:45 PM, Martin v. Löwis wrote:
I'll take this up with FreeBSD folk, but I'm open to ideas as to how
best to deal with the problem in the context of the test suite
pending
resolution by FreeBSD.
Not sure what the test purpose is: if it is to test that you get a
There is an option at least on linux to hack using ld preload to use
another memory manager that respond the way needed... at least that was
what I was told today at lunch. (if ulimit is not enough for any reason).
For Python, there would be much less hackish ways. Most if not all calls
to
Bill Janssen wrote:
Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On Wed, 17 Sep 2008 10:40:01 PDT, Bill Janssen [EMAIL PROTECTED] wrote:
Ah, now I remember. It seems that sometimes when SSL_ERROR_WANT_READ
was returned, things would block; that is, the handle_read method on
Ok, here's some news, in case they can be of some interest.
I managed to write an asyncore disptacher which seems to work.
I used my test suite against it and 70 tests passed and 2 failed.
The tests failed because at a certain point a call to do_handhsake
results in an EOF exception, which is very
On Sep 17, 1:32 am, Anthon van der Neut [EMAIL PROTECTED] wrote:
With a minor modification to the Makefile I was able to getmod_wsgi
v2.3 to work with python2.6rc1.
Which I believe was still required only because you have only
installed static Python library. :-)
I promptly got a warning in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On behalf of the Python development team and the Python community, I
am happy to announce the second and final planned release candidate
for Python 2.6, as well as the first release candidate for Python 3.0.
These are release candidates, so
23 matches
Mail list logo
