I know (thanks to Google) that much has been said in the past about the
Python Memory Manager. My purpose in posting is simply to given a
use-case example of how the current memory manager (in Python 2.4.X) can
be problematic in scientific/engineering code.
Scipy core is a replacement for Num
On 11/15/05, Scott David Daniels <[EMAIL PROTECTED]> wrote:
> Since I am fiddling with int/long conversions to/from string:
>
> Is the current behavior intentional (or mandatory?):
>
> v = int(' 5 ')
> works, but:
> v = int(' 5
Michiel Jan Laurens de Hoon wrote:
> There are several other reasons why the alternative solutions that came
> up in this discussion are more attractive than IPython:
> 1) AFAICT, IPython is not intended to work with IDLE.
Not so far, but mostly by accident. The necessary changes are fairly easy
Phillip J. Eby wrote:
> At 06:48 PM 11/15/2005 -0500, Michiel Jan Laurens de Hoon wrote:
>
>> Thanks everybody for contributing to this discussion. I didn't expect it
>> to become this extensive.
>> I think that by now, everybody has had their chance to voice their
>> opinion.
>> It seems safe to
At 06:48 PM 11/15/2005 -0500, Michiel Jan Laurens de Hoon wrote:
>Thanks everybody for contributing to this discussion. I didn't expect it
>to become this extensive.
>I think that by now, everybody has had their chance to voice their opinion.
>It seems safe to conclude that there is no consensus on
Thanks everybody for contributing to this discussion. I didn't expect it
to become this extensive.
I think that by now, everybody has had their chance to voice their opinion.
It seems safe to conclude that there is no consensus on this topic.
So what I'm planning to do is to write a small extensi
Since I am fiddling with int/long conversions to/from string:
Is the current behavior intentional (or mandatory?):
v = int(' 5 ')
works, but:
v = int(' 5L ')
fails.
--Scott David Dani
Thanks for your examples. I understand tham sometimes it's a good idea
not to write the HTML inside the function (although it may be nice to
sometimes write it just before the function - and if it's a method,
then we get the same indentation problem.)
However, as you said, sometimes it is desired
On 11/15/05, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
>
> Thanks for the message. I was going to suggest the same thing. I
> think it's primarily a question of how to add an arena layer. The AST
> phase has a mixture of malloc/free and Python object allocation. It
> should be straightforward to
On 11/15/05, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> On 11/15/05, Niko Matsakis <[EMAIL PROTECTED]> wrote:
> > > As Neal pointed out, it's tricky to write code for the AST parser
> > > and compiler
> > > without accidentally letting memory leak when the parser or
> > > compiler runs into
> > > a
On 11/15/05, Niko Matsakis <[EMAIL PROTECTED]> wrote:
> > As Neal pointed out, it's tricky to write code for the AST parser
> > and compiler
> > without accidentally letting memory leak when the parser or
> > compiler runs into
> > a problem and has to bail out on whatever it was doing. Thomas's
>
> As Neal pointed out, it's tricky to write code for the AST parser
> and compiler
> without accidentally letting memory leak when the parser or
> compiler runs into
> a problem and has to bail out on whatever it was doing. Thomas's
> patch got to
> v5 (based on Neal's review comments) with m
Gothenburg PyPy Sprint II: 7th - 11th December 2005
==
(NOTE: internal EU-only sprint starts on the 5th!)
The next PyPy sprint is scheduled to be in December 2005 in Gothenborg,
Sweden. Its main focus is heading towards phase 2, which means JIT
Interesting trick!
The PEP 341 patch is now using Marek's 'do ... while' resource cleanup
trick instead of the nasty goto voodoo.
I've also fixed the last remaining bug that Neal pointed out. I'm
running the unit tests right now, shall have the updated (and hopefully
final) PEP 341 patch up on
Marek Baczek Baczyński wrote:
> 2005/11/15, Nick Coghlan <[EMAIL PROTECTED]>:
>> It avoids the potential for labelling problems that arises when goto's are
>> used for resource cleanup. It's a far cry from real exception handling, but
>> it's the best solution I've seen within the limits of C.
>
>
2005/11/15, Nick Coghlan <[EMAIL PROTECTED]>:
> Specifically, the body of the entire function is written inside a switch
> statement, with 'break' then used as the equivalent of "raise Exception". For
> example:
>
>PyObject* switchAsTry()
>{
> switch(0) {
>default:
> /
Greg Ewing <[EMAIL PROTECTED]> writes:
> James Y Knight wrote:
>
>> ITYM you mean "If only python were lisp". (macros, or even reader macros)
>
> No, I mean it would be more satisfying if there
> were a syntax for expressing multiline string
> literals that didn't force it to be at the left
> mar
Transferring part of the discussion of Thomas Lee's PEP 341 patch to
python-dev. . .
Neal Norwitz wrote in the SF patch tracker:
> Thomas, I hope you will write up this experience in coding
> this patch. IMO it clearly demonstrates a problem with the
> new AST code that needs to be addressed. i
On Mon, 2005-11-14 at 15:46 -0700, Bruce Eckel wrote:
[...]
> What is not clear to me, and is not discussed in the PEP, is whether
> coroutines can be distributed among multiple processors. If that is or
> isn't possible I think it should be explained in the PEP, and I'd be
> interested in know abo
19 matches
Mail list logo
