Hello
I was having a very nasty fd leak recently where I've leaked more than 200k
FDs, allocating more than 1Gbytes of ram in kernel space. It was my
fault alright,
but I thought I'd mention it here so maybe you'll put a little NOTE
section in the
documentation mentioning that you have to os.cl
Le mercredi 06 octobre 2010 09:34:05, Kálmán Gergely a écrit :
> Nevertheless what are your thoughts on this? Should I file a bug report
> for it?
It will be fixed faster if you open an issue and attach a patch ;-)
--
Victor Stinner
http://www.haypocalc.com/
_
R. David Murray writes:
> version of headers to the email5 API, but since any such data would
> be non-RFC compliant anyway, [access to non-conforming headers by
> reparsing the bytes] will just have to be good enough for now.
But that's potentially unpleasant for, say, Mailman. AFAICS, what
2010/10/6 brian.quinlan :
> Author: brian.quinlan
> Date: Wed Oct 6 15:05:45 2010
> New Revision: 85288
>
> Log:
> Fixes 9903: test_concurrent_futures writes on stderr
>
> Modified:
> python/branches/py3k/Lib/concurrent/futures/_base.py
> python/branches/py3k/Lib/test/test_concurrent_futures.p
On Wed, 06 Oct 2010 12:22:18 +0900, "Stephen J. Turnbull"
wrote:
> Nick Coghlan writes:
>
> > - if you pass in bytes data and know what you are doing, then you can
> > access that raw bytes data and do your own decoding
>
> At what level, though?
>
> To take an interesting example I used to
On Wed, 06 Oct 2010 22:55:00 +0900, "Stephen J. Turnbull"
wrote:
> R. David Murray writes:
>
> > version of headers to the email5 API, but since any such data would
> > be non-RFC compliant anyway, [access to non-conforming headers by
> > reparsing the bytes] will just have to be good enough
R. David Murray writes:
> 5. Return the content, with non-ASCII bytes replaced with ?
> characters.
That hadn't occurred to me (and it makes me sick to contemplate it).
That said, this is probably good enough for Mailman-like apps to limp
along for "most" users. It's certainly good enoug
R. David Murray writes:
> So the only parsing issue is if Mailman cares about *the non-ASCII
> bytes* in the headers it cares about. If it has to modify headers that
> contain non-ASCII bytes (for example, addresses and Subject) and cares
> about preserving the non-ASCII bytes, then there is
