On 10.02.2005, at 05:36, Guido van Rossum wrote:
And why would a Matrix need to inherit from a C-array? Wouldn't it
make more sense from an OO POV for the Matrix to *have* a C-array
without *being* one?
Definitely. Most array operations make no sense on matrices. And
matrices are limited to two d
On 10.02.2005, at 05:09, Travis Oliphant wrote:
I'm not sure I agree. The ufuncobject is the only place where this
concern existed (should we trip OverFlow, ZeroDivision, etc. errors
durring array math). Numarray introduced and implemented the concept
of error modes that can be pushed and
On Feb 10, 2005, at 10:30 AM, Travis Oliphant wrote:
One question we are pursuing is could the arrayobject get into the
core without a particular ufunc object. Most see this as
sub-optimal, but maybe it is the only way.
Since all the artithmetic operations are in ufunc that would be
subop
Paul Dubois wrote:
>
> Aside: While I am at it, let me reiterate what I have said to the other
> developers privately: there is NO value to inheriting from the array
> class. Don't try to achieve that capability if it costs anything, even
> just effort, because it buys you nothing. Those of you wh
iis it "pydos" ? your net add?/
Yahoo! Messenger - Communicate instantly..."Ping" your friends
today! Download Messenger Now___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail
Dear all,
I'm running a large Zope application on a 1x1GHz CPU 1GB mem
Window XP Prof machine using Zope 2.7.3 and Py 2.3.4
The application typically builds large lists by appending
and extending them.
We regularly observed that using a given functionality a
second time using the same proces
> Maybe it's just a wart we have to live with now; OTOH,
> the docs explicitly warn that id() may return a long, so any code
> relying on "short int"-ness has always been relying on an
> implementation quirk.
Well, the docs say that %x does unsigned conversion, so they've
been relying on an implem
Nick Rasmussen <[EMAIL PROTECTED]> writes:
[five days ago]
> Should boost::python functions be modified in some way to show
> up as builtin function types or is the right fix really to patch
> pydoc?
My heart leans towards the latter.
> Is PyCFunction_Type intended to be subclassable?
Doesn't
tommy said that this would be the best place to ask
this question
I'm trying to get functions wrapped via boost to show
up as builtin types so that pydoc includes them when
documenting the module containing them. Right now
boost python functions are created using a PyTypeObject
such that when
At 02:32 PM 2/11/05 -0800, Nick Rasmussen wrote:
tommy said that this would be the best place to ask
this question
I'm trying to get functions wrapped via boost to show
up as builtin types so that pydoc includes them when
documenting the module containing them. Right now
boost python functions
On Feb 16, 2005, at 11:02, Phillip J. Eby wrote:
At 02:32 PM 2/11/05 -0800, Nick Rasmussen wrote:
tommy said that this would be the best place to ask
this question
I'm trying to get functions wrapped via boost to show
up as builtin types so that pydoc includes them when
documenting the module c
At 11:26 AM 2/16/05 -0500, Bob Ippolito wrote:
>>> help(FakeBuiltin("name", "name(foo, bar, baz) -> rval"))
Help on built-in function name:
name(...)
name(foo, bar, baz) -> rval
If you wanted to be even more ambitious, you could return FunctionType and
have a fake func_code so pydoc will be ab
On Feb 16, 2005, at 11:43, Phillip J. Eby wrote:
At 11:26 AM 2/16/05 -0500, Bob Ippolito wrote:
>>> help(FakeBuiltin("name", "name(foo, bar, baz) -> rval"))
Help on built-in function name:
name(...)
name(foo, bar, baz) -> rval
If you wanted to be even more ambitious, you could return FunctionTy
any special reason why "in" is faster if the substring is found, but
a lot slower if it's not in there?
timeit -s "s = 'not there'*100" "s.find('not there') != -1"
100 loops, best of 3: 0.749 usec per loop
timeit -s "s = 'not there'*100" "'not there' in s"
1000 loops, best of 3: 0.122 use
Title: RE: [Python-Dev] string find(substring) vs. substring in string
[Fredrik Lundh]
#- any special reason why "in" is faster if the substring is found, but
#- a lot slower if it's not in there?
Maybe because it stops searching when it finds it?
The time seems to be very dependant of t
Fredrik Lundh wrote:
> any special reason why "in" is faster if the substring is found, but
> a lot slower if it's not in there?
Just guessing here, but in general I would think that it would stop searching
as soon as it found it, whereas until then, it keeps looking, which takes more
time. But
On Wed, Feb 16, 2005 at 01:34:16PM -0700, Mike Brown wrote:
> time. But I would also hope that it would be smart enough to know that it
> doesn't need to look past the 2nd character in 'not the xyz' when it is
> searching for 'not there' (due to the lengths of the sequences).
Assuming stringobje
> Assuming stringobject.c:string_contains is the right function, the
> code looks like this:
>
> size = PyString_GET_SIZE(el);
> rhs = PyString_AS_STRING(el);
> lhs = PyString_AS_STRING(a);
>
> /* optimize for a single character */
> if (size == 1)
>
Mike Brown wrote:
Fredrik Lundh wrote:
any special reason why "in" is faster if the substring is found, but
a lot slower if it's not in there?
Just guessing here, but in general I would think that it would stop searching
as soon as it found it, whereas until then, it keeps looking, which takes mo
A.M. Kuchling wrote:
>> time. But I would also hope that it would be smart enough to know that it
>> doesn't need to look past the 2nd character in 'not the xyz' when it is
>> searching for 'not there' (due to the lengths of the sequences).
>
> Assuming stringobject.c:string_contains is the right
Mike Brown wrote:
>> any special reason why "in" is faster if the substring is found, but
>> a lot slower if it's not in there?
>
> Just guessing here, but in general I would think that it would stop searching
> as soon as it found it, whereas until then, it keeps looking, which takes more
> time.
Guido van Rossum wrote:
> Which is exactly how s.find() wins this race. (I guess it loses when
> it's found by having to do the "find" lookup.) Maybe string_contains
> should just call string_find_internal()?
I somehow suspected that "in" did some extra work in case the "find"
failed; guess I sho
Rev 2.66 of funcobject.c made func.__name__ writable for the first
time. That's great, but the patch also introduced what I'm pretty
sure was an unintended incompatibility: after 2.66, func.__name__ was
no longer *readable* in restricted execution mode. I can't think of a
good reason to restrict
> but refactoring the contains code to use find_internal sounds like a
good
> first step. any takers?
>
>
I'm up for it.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsu
> memcmp still compiles to REP CMPB on many x86 compilers, and the setup
> overhead for memcmp sucks on modern x86 hardware
make that "compiles to REPE CMPSB" and "the setup overhead for
REPE CMPSB"
___
Python-Dev mailing list
Python-Dev@python.or
Irmen de Jong wrote:
There's the Boyer-Moore string search algorithm which is
allegedly much faster than a simplistic scanning approach,
and I also found this: http://portal.acm.org/citation.cfm?id=79184
So perhaps there's room for improvement :)
The problem is setup vs. run. If the question is 'a
> The longer the thing you are searching in, the more one-time-only
> overhead you can afford to reduce the per-search-character cost.
Only if you don't find it close to the start.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Py
Fredrik Lundh wrote:
(btw, the benchmark was taken from jim hugunin's ironpython talk, and
seems to be carefully designed to kill performance also for more advanced
algorithms -- including boyer-moore)
Looking for "not there" in "not the xyz"*100 using Boyer-Moore should do
about 300 probes once th
Scott David Daniels wrote:
> Looking for "not there" in "not the xyz"*100 using Boyer-Moore should do
> about 300 probes once the table is set (the underscores below):
>
> not the xyznot the xyznot the xyz...
> not ther_
> not the__
>not ther_
>
Gfeller Martin wrote:
Nevertheless, I tried to convert the heap used by Python
to a Windows Low Fragmentation Heap (available on XP
and 2003 Server). This improved the overall run time
of a typical CPU-intensive report by about 15%
(overall run time is in the 5 minutes range), with the
same mem
Boyer-Moore and variants need a bit of preprocessing on the pattern which
makes them great for long patterns but more costly for short ones.
On Wed, 16 Feb 2005, Irmen de Jong wrote:
> Mike Brown wrote:
> > Fredrik Lundh wrote:
> >
> >>any special reason why "in" is faster if the substring is fo
On Feb 16, 2005, at 18:42, Martin v. Löwis wrote:
I must admit that I'm surprised. I would have expected
that most allocations in Python go through obmalloc, so
the heap would only see "large" allocations.
It would be interesting to find out, in your application,
why it is still an improvement to u
Richard Brodie wrote:
Otherwise, unless I misunderstand integer unification, one would
just have to strike the distinction between, say, %d and %u.
Couldn't that be done anyway? The distinction really only
makes sense in C, where there's no way of knowing whether
the value is signed or unsigned oth
> > Otherwise, unless I misunderstand integer unification, one would
> > just have to strike the distinction between, say, %d and %u.
>
> Couldn't that be done anyway? The distinction really only
> makes sense in C, where there's no way of knowing whether
> the value is signed or unsigned otherwis
fyi - i've updated the python sha1/md5 openssl patch. it now replaces
the entire sha and md5 modules with a generic hashes module that gives
access to all of the hash algorithms supported by OpenSSL (including
appropriate legacy interface wrappers and falling back to the old code
when compiled wit
35 matches
Mail list logo
