[Tim]
>> PyLong_FromString() only sees the starting
>> address, and-- as it always does --parses until it hits a character
>> that doesn't make sense for the input base.
[Greg Ewing]
> This is the bug, then. long() shouldn't be using
> PyLong_FromString() to convert its argument, but
> something t
Tim Peters wrote:
> PyLong_FromString() only sees the starting
> address, and-- as it always does --parses until it hits a character
> that doesn't make sense for the input base.
This is the bug, then. long() shouldn't be using
PyLong_FromString() to convert its argument, but
something that takes
[Jean-Paul Calderone]
>> ...
>> Hmm, one reason could be that the general solution doesn't work:
>>
>> [EMAIL PROTECTED]:~$ python
>> Python 2.4.3 (#2, Apr 27 2006, 14:43:58)
>> [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
>> Type "help", "copyright", "credits" or "license" for more inform
On 5/25/06, Runar Petursson <[EMAIL PROTECTED]> wrote:
>
> On 5/25/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > If you really need this for speed, I recommend you make it a custom
> extension.
> >
> >
> The custom extension is a good idea, and what we do now. But now that the
> long al
On 5/25/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
If you really need this for speed, I recommend you make it a custom extension.
The custom extension is a good idea, and what we do now. But now
that the long algorithm is so fast, it would be nice to expose
it at least at the C level to use a
Bob Ippolito <[EMAIL PROTECTED]> wrote:
> One problem with buffer() is that it does a memcpy of the buffer. A
> zero-copy version of buffer (a view on some object that implements
> the buffer API) would be nice.
Did buffers change? I seem to remember that there were segfaulting
conditions wh
On May 25, 2006, at 3:28 PM, Jean-Paul Calderone wrote:
> On Thu, 25 May 2006 15:01:36 +, Runar Petursson
> <[EMAIL PROTECTED]> wrote:
>> We've been talking this week about ideas for speeding up the
>> parsing of
>> Longs coming out of files or network. The use case is having a
>> larg
Runar Petursson wrote:
> We've been talking this week about ideas for speeding up the parsing
> of Longs coming out of files or network. The use case is having a
> large string with embeded Long's and parsing them to real longs. One
> approach would be to use a simple slice:
> long(mystring[x
On 5/25/06, Sean Reifschneider <[EMAIL PROTECTED]> wrote:
> Conversion functions taking a start and end are the low-hanging fruit, but
> I think in the long term something that does that described I would prefer.
> I believe that Martin is expecting expecting to have something this week
> to try.
On Thu, 25 May 2006 15:01:36 +, Runar Petursson <[EMAIL PROTECTED]> wrote:
>We've been talking this week about ideas for speeding up the parsing of
>Longs coming out of files or network. The use case is having a large string
>with embeded Long's and parsing them to real longs. One approach wo
On Thu, May 25, 2006 at 03:01:36PM +, Runar Petursson wrote:
>simply limit the scope of the parsing. There are other solutions, using
>buffer-like objects and such, but this seems like a simple win for anyone
>parsing a lot of text. I implemented it in a branch
I'll expand on that a little
We've been talking this week about ideas for speeding up the parsing of Longs coming out of files or network. The use case is having a large string with embeded Long's and parsing them to real longs. One approach would be to use a simple slice:
long(mystring[x:y]) an expensive operation in a tigh
12 matches
Mail list logo
