+1 from me for both tracemalloc and failmalloc in the same vein as
faulthandler (and using similar API concepts to faulthandler).
While I like the flat top level naming structure, we should clearly
document these as implementation dependent runtime services. Other
implementations may not provide t
On 1 Sep 2013 05:18, "Stefan Behnel" wrote:
>
> Nick Coghlan, 31.08.2013 18:49:
> > On 25 Aug 2013 21:56, "Stefan Behnel" wrote:
> > One key point to note is that it *doesn't* call
> > _PyImport_FixupExtensionObject, which is the API that handles all
the
> > PEP 3121 per-module state s
Le 31 août 2013 19:09, "Gregory P. Smith" a écrit :
> First, I really like this. +1
Current votes: +3 (i also want tracemalloc!). No opposition against such
addition.
> We should be consistent with faulthandler's options. Why do you not want
to support both the env var and enable()/disable() fu
Antoine Pitrou, 31.08.2013 21:27:
> On Sat, 31 Aug 2013 21:16:10 +0200
> Stefan Behnel wrote:
>>> Our experience is very different - my perspective is that the normal case
>>> either eschews C level global state in the extension module, because it
>>> causes so many problems, or else just completel
On Sat, 31 Aug 2013 21:16:10 +0200
Stefan Behnel wrote:
> > Our experience is very different - my perspective is that the normal case
> > either eschews C level global state in the extension module, because it
> > causes so many problems, or else just completely ignores subinterpreter
> > support
Nick Coghlan, 31.08.2013 18:49:
> On 25 Aug 2013 21:56, "Stefan Behnel" wrote:
> One key point to note is that it *doesn't* call
> _PyImport_FixupExtensionObject, which is the API that handles all the
> PEP 3121 per-module state stuff. Instead, the idea will be for modules
> that do
Sorry, this is mine.
This is related to http://bugs.python.org/issue11798
Error happens when tests regrtest executed with -R option.
I've temporary disabled this feature until finally fix it.
On Sat, Aug 31, 2013 at 8:23 PM, Ethan Furman wrote:
> Am I the only one experiencing this?
>
> 262 tests
On Sat, 31 Aug 2013 10:23:27 -0700
Ethan Furman wrote:
> Am I the only one experiencing this?
http://bugs.python.org/issue11798 perhaps?
Regards
Antoine.
> 262 tests OK.
> 93 tests failed:
> test___all__ test_abc test_array test_ast test_asynchat
> test_asyncore test_bisect test_buf
Am I the only one experiencing this?
262 tests OK.
93 tests failed:
test___all__ test_abc test_array test_ast test_asynchat
test_asyncore test_bisect test_buffer test_bufio test_bytes
test_codeccallbacks test_codecs test_colorsys test_compileall
test_configparser test_contextlib t
2013/8/29 Victor Stinner :
> Charles-François Natali and Serhiy Storchaka asked me to add this
> module somewhere in Python 3.4: "how about adding pyfailmalloc to the
> main repo (maybe under Tools), with a script making it easy to run the
> tests suite with it enabled?"
There are two reasons I th
First, I really like this. +1
On Wed, Aug 28, 2013 at 6:07 PM, Victor Stinner wrote:
> 2013/8/29 Victor Stinner :
> > My proposed implementation for Python 3.4 is different:
> >
> > * no enable() / disable() function: tracemalloc can only be enabled
> > before startup by setting PYTHONTRACEMALLO
Oops, had a draft from a few days ago that I was interrupted before
sending. Finished editing the parts I believe are still relevant.
On 25 Aug 2013 21:56, "Stefan Behnel" wrote:
>
> Nick Coghlan, 24.08.2013 23:43:
> > On 25 Aug 2013 01:44, "Stefan Behnel" wrote:
> >> Nick Coghlan, 24.08.2013 16:
On Fri, Aug 30, 2013 at 10:57 AM, Guido van Rossum wrote:
> I don't have a strong opinion on this either. The distinction between
> send() and send_all() makes sense to me though (send_all() works hard to
> get all your data out, send() only does what it can quickly).
>
> Personally for calls lik
On 1 Sep 2013 00:10, "Stefan Behnel" wrote:
>
> *bump*
>
> Does this sound like a viable solution?
This isn't likely to progress until we have Eric's PEP 451 to a point where
it's ready for python-dev discussion and pronouncement.
However, the revised loader API is being designed to allow for th
R. David Murray writes:
> Full validation is something that is currently a "future
> objective".
I didn't mean it to be anything else. :-)
> There's infrastructure to do it, but not all of the necessary knowledge
> has been coded in yet.
Well, I assume you already know that there's no way t
On Sat, 31 Aug 2013 18:57:56 +0900, "Stephen J. Turnbull"
wrote:
> R. David Murray writes:
>
> > But I would certainly appreciate review from anyone so moved, since I
> > haven't gotten any yet.
>
> I'll try to make time for a serious (but obviously partial) review by
> Monday.
Thanks.
> I
On Sat, 31 Aug 2013 20:37:30 +1000, Steven D'Aprano wrote:
> On 31/08/13 15:21, R. David Murray wrote:
> > If you've read my blog (eg: on planet python), you will be aware that
> > I dedicated August to full time email package development.
> [...]
>
>
> The API looks really nice! Thank you for p
*bump*
Does this sound like a viable solution?
Stefan
Stefan Behnel, 25.08.2013 14:36:
> Hi,
>
> thanks for bringing this up. It clearly shows that there is more to this
> problem than I initially thought.
>
> Let me just add one idea that your post gave me.
>
> PJ Eby, 25.08.2013 06:12:
>>
Steven D'Aprano writes:
> which may explain why Stephen Turnbull's reply contains mojibake.
Nah. It was already there, I just copied it. Could be my MUA's
fault, though; I've tweaked it for Japanese, and it doesn't handle odd
combinations well.
___
On 31/08/13 15:21, R. David Murray wrote:
If you've read my blog (eg: on planet python), you will be aware that
I dedicated August to full time email package development.
[...]
The API looks really nice! Thank you for putting this together.
A question comes to mind though:
All input strings
R. David Murray writes:
> But I would certainly appreciate review from anyone so moved, since I
> haven't gotten any yet.
I'll try to make time for a serious (but obviously partial) review by
Monday.
I don't know if this is "serious" bikeshedding, but I have a comment
or two on the example:
21 matches
Mail list logo