This is probably orthogonal to the problem, however, you may want to
look into trying to speed up Python/errors.c. This link will probably
not work due to sessions, but click on the latest run for python and
Python/errors.c
Hi,
I'm trying to port ctypes to darwin/x86 (aka the new intel macs),
which went pretty smooth. I am running into some odd behaviour of
distutils now that I'm trying to port those changes to the trunk.
ctypes uses libffi, which contains source files in various platform-
specific
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 tight
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
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 would
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.
I'm
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:y])
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
large string
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 when
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
While working on a patch involving sys.path_importer_cache, I discovered
that if a path_hooks import hook has been found for a given sys.path entry,
but isn't able to import a specific module, find_module() tries to import
the module from this sys.path entry as a regular file.
This results in
Good catch. I think this would save a certain number of unnecessary
stat() calls.
But it does change semantics, so we can't fix this in 2.4. In 2.5, we
should warn hook authors that this might affect them.
The PEP ought to be updated to clarify this.
--Guido
On 5/25/06, Georg Brandl [EMAIL
-1 * (1, 2, 3)
()
-(1, 2, 3)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: bad operand type for unary -
We Really Need To Fix This!
[\F]
___
Python-Dev mailing list
Python-Dev@python.org
Fredrik Lundh wrote:
-1 * (1, 2, 3)
()
-(1, 2, 3)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: bad operand type for unary -
We Really Need To Fix This!
I can't find this inconsistency horrible.
py +Hello
Traceback (most recent call last):
File
Martin v. Löwis wrote:
Fredrik Lundh wrote:
-1 * (1, 2, 3)
()
-(1, 2, 3)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: bad operand type for unary -
We Really Need To Fix This!
I can't find this inconsistency horrible.
py +Hello
Traceback (most
You're joking right?
On 5/25/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
-1 * (1, 2, 3)
()
-(1, 2, 3)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: bad operand type for unary -
We Really Need To Fix This!
[\F]
Doesn't the real effbot have /F as sig?
On 25-mei-2006, at 23:04, Martin v. Löwis wrote:
Fredrik Lundh wrote:
-1 * (1, 2, 3)
()
-(1, 2, 3)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: bad operand type for unary -
We Really Need To Fix This!
I can't find this inconsistency horrible.
py
Ronald Oussoren wrote:
I don't know which one Fredrik thinks is wrong, but I think the result
of -1*(1,2,3) is very surprising. I'd expect an exception here.
I agree, but this has nothing to do with whether or not the unary -
is supported.
Regards,
Martin
On Thu, May 25, 2006 at 09:06:49PM +, Georg Brandl wrote:
Don't tell me that! I was actually working on a patch right now...
While undoubtedly a performance patch, it wasn't on the list of tasks to do
today. You risk Steve's wrath!
Thanks,
Sean
--
In the end, we will remember not the
Fredrik Lundh wrote:
-1 * (1, 2, 3)
()
-(1, 2, 3)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: bad operand type for unary -
We Really Need To Fix This!
The second one doesn't bug me. Unary minus on a sequence is meaningless.
The first is a bit odd.
[Fredrik]
-1 * (1, 2, 3)
()
-(1, 2, 3)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: bad operand type for unary -
We Really Need To Fix This!
What's broken? It's generally true that
n*s == s*n == empty_container_of_type_type(s)
whenever s is a
On 5/25/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
Fredrik Lundh wrote:
-1 * (1, 2, 3)
()
-(1, 2, 3)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: bad operand type for unary -
We Really Need To Fix This!
The second one doesn't bug me.
[Raymond Hettinger]
...
Also, I'm not clear on the rationale for transforming negative
repetition counts to zero instead of raising an exception.
There are natural use cases. Here's one: you have a string and want
to right-justify it to 80 columns with blanks if it's shorter than 80.
s =
Guido van Rossum wrote:
We Really Need To Fix This!
[\F]
Doesn't the real effbot have /F as sig?
yeah, we've had some trouble with fake bots lately. I mean, there's a
timbot posting to this thread, but I know for sure that the real Tim got
tired of hacking on Python earlier tonight, and
Fredrik Lundh wrote:
Guido van Rossum wrote:
We Really Need To Fix This!
[\F]
Doesn't the real effbot have /F as sig?
yeah, we've had some trouble with fake bots lately. I mean, there's a
timbot posting to this thread, but I know for sure that the real Tim got
tired of hacking on
Georg Brandl wrote:
Martin v. Löwis wrote:
Fredrik Lundh wrote:
-1 * (1, 2, 3)
()
-(1, 2, 3)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: bad operand type for unary -
We Really Need To Fix This!
I can't find this inconsistency horrible.
py
Raymond Hettinger wrote:
Fredrik Lundh wrote:
does anyone remember? given what we're currently working on,
implementing it would take roughly no time at all. do people still
think it's a good idea ?
/F !-- note: angle brackets, forward slash --
Yes. It went to my todo list and
Brett provided the following direction:
Right, I meant change how it (BaseException) is written. Right now
it uses PyMethodDef for magic methods and just uses PyType_New()
as a constructor. I was wondering if, for some reason, it would be
faster if you used a PyType_Type definition
Fredrik Lundh wrote:
no need to wait for any raymond-cycles here; just point me to the latest
version of the proposal, and it'll be in the trunk within 30 minutes.
are these still valid?
http://mail.python.org/pipermail/python-dev/2005-August/055764.html
Fredrik Lundh wrote:
Yes. It went to my todo list and is awaiting some free raymond-cycles
to finish it up. I've been task saturated of late but would like to get
this a number of other patches complete for Py2.5.
no need to wait for any raymond-cycles here; just point
Steve Holden wrote:
This reminds me I am tasked with trying to find out what the interface
to timeit.py is supposed to look like. Raymond, your name has been
mentioned as someone who took part int he discussions. Google hasn't
given me a lot to go on. Anyone?
IIRC, Guido's words were
Giovanni Bajo wrote:
Fredrik Lundh wrote:
does anyone remember? given what we're currently working on,
implementing it would take roughly no time at all. do people still
think it's a good idea ?
/F !-- note: angle brackets, forward slash --
I had enquired this
[Bob Ippolito]
...
Unfortunately, this change to the struct module slightly alters the
documented API for the following format codes: I, L, q, Q. Currently
it is documented that those format codes will always return longs,
regardless of their value.
I view that more as having documented the
I will certainly look forward to using it.
On May 25, 2006, at 16:21, Fredrik Lundh wrote:
does anyone remember? given what we're currently working on,
implementing it would take roughly no time at all. do people still
think it's a good idea ?
/F !-- note: angle brackets, forward slash
Steve Holden wrote:
In actual fact the effbot has lately found itself so permeated with
Windows that it has become constituionally incapable of using a forward
slash. Don't know what's with the square brackets though ...
I was thinking maybe that message had resulted from
a Windows and a
On 5/25/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Raymond Hettinger wrote:
IIRC, Skip had developed a smart version that returned lazy string
objects that kept a reference and pointers to the original string
(instead of making its own copy of the string components). The string
36 matches
Mail list logo
