Mailing List Archive

ucnhash module
I'm a bit worried about the ucnhash module and its huge size. I didn't
follow the discussion closely at the time, because I thought I could
always exclude it from the Pythons without dynamic linking, but now it
seems that if i don't include it test_unicode doesn't run anymore.

Is this a problem with test_unicode, or should I consider ucnhash a
mandatory module?

(BTW: there were also a couple of bugs in the module, include <> in
stead of include "", and static in stead of staticforward
declarations, I'll submit patches for those shortly).
--
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++
Re: ucnhash module [ In reply to ]
Jack Jansen wrote:
>
> I'm a bit worried about the ucnhash module and its huge size. I didn't
> follow the discussion closely at the time, because I thought I could
> always exclude it from the Pythons without dynamic linking, but now it
> seems that if i don't include it test_unicode doesn't run anymore.
>
> Is this a problem with test_unicode, or should I consider ucnhash a
> mandatory module?

The ucnhash module is loaded on demand to avoid memory bloat.
In practice the difference is not really noticeable since
loading a shared module or swapping in a few pages of static
C data result in pretty much the same overall memory usage.

If no-one complains, I'll fix the test suite though to make
the tests of the named Unicode characters optional.

Is this ok with you, Bill ?

> (BTW: there were also a couple of bugs in the module, include <> in
> stead of include "", and static in stead of staticforward
> declarations, I'll submit patches for those shortly).

I didn't have any problem compiling the module (don't even get
warnings when compiling with -Wall) ... but you're right:
these ought to get fixed.

BTW, since ucnhash.h|c are generated using the scripts
in Tools/perfecthash/ your patch should probably also fix the
instances of the problems found in there.

--
Marc-Andre Lemburg
______________________________________________________________________
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/
Re: ucnhash module [ In reply to ]
On 29 June 2000, M.-A. Lemburg said:
> The ucnhash module is loaded on demand to avoid memory bloat.
> In practice the difference is not really noticeable since
> loading a shared module or swapping in a few pages of static
> C data result in pretty much the same overall memory usage.
>
> If no-one complains, I'll fix the test suite though to make
> the tests of the named Unicode characters optional.

How 'bout a separate "test_ucn" to test this feature?

...of course, this is yet another case of language syntax features
becoming optional and selectable at compile-time, which I still think is
a bad idea. Hmmm.

Greg
Re: ucnhash module [ In reply to ]
Greg Ward wrote:
>
> On 29 June 2000, M.-A. Lemburg said:
> > The ucnhash module is loaded on demand to avoid memory bloat.
> > In practice the difference is not really noticeable since
> > loading a shared module or swapping in a few pages of static
> > C data result in pretty much the same overall memory usage.
> >
> > If no-one complains, I'll fix the test suite though to make
> > the tests of the named Unicode characters optional.
>
> How 'bout a separate "test_ucn" to test this feature?

Good idea.

> ...of course, this is yet another case of language syntax features
> becoming optional and selectable at compile-time, which I still think is
> a bad idea. Hmmm.

It's not selectable at run-time: either you have compiled the
module or not. It is enabled per default.

--
Marc-Andre Lemburg
______________________________________________________________________
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/