[Patches] [ python-Patches-1349274 ] [PATCH] 100x optimization for ngettext

[SourceForge.net]

Patches item #1349274, was opened at 2005-11-06 01:18
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349274&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Joe Wreschnig (piman)
>Assigned to: Georg Brandl (birkenfeld)
Summary: [PATCH] 100x optimization for ngettext

Initial Comment:
Currently gettext.ngettext scans the filesystem
whenever you call it. This makes it ridiculously slow.
But if one uses gettext.install to initialize gettext,
gettext.ngettext is the cleanest way to do plural
translation.

This patch makes gettext.install install both "_" and
"ngettext" into the builtin namespace, which means
using "ngettext" won't have to do the filesystem
lookup. My benchmarks show this is about 100 times faster.

----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-19 14:27

Message:
Logged In: YES 
user_id=1188172

I now changed the install() method to accept an optional
"names" parameter which can be used to install ngettext() too.

Revision 42492.

----------------------------------------------------------------------

Comment By: Michael Urman (michaelurman)
Date: 2006-01-25 16:12

Message:
Logged In: YES 
user_id=1404983

To be overly blunt I think it's ludicrous. I doubt the
extraction tools would scan for _.ngettext() like they do
for ngettext() (I haven't tested). Also while the builtin
namespace is somewhat precious, those using gettext.install
need the performance and visual compatibility much more than
to avoid setting a builtin that's a fast version of the
global/local they would otherwise use.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-24 20:09

Message:
Logged In: YES 
user_id=1188172

Are there opinions about my suggestion?

----------------------------------------------------------------------

Comment By: Joe Wreschnig (piman)
Date: 2005-11-07 22:41

Message:
Logged In: YES 
user_id=796

Well, I did write my own install function; that's the patch
you see below. I figured I'd submit it in the interest of
other users (that's the point of a standard library, right?)
but if the Pythonic thing to do is choose between ugly or
slow, I guess I'll just keep using my own.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-11-07 21:30

Message:
Logged In: YES 
user_id=1188172

I didn't mean to overload the calling of "_", but I can
think of "_.gettext()", "_.ngettext()" etc. Of course with
"_()" staying  the same.

Other than that, if you need ngettext in builtins, why don't
you write your own install function?

----------------------------------------------------------------------

Comment By: Joe Wreschnig (piman)
Date: 2005-11-06 21:59

Message:
Logged In: YES 
user_id=796

It seems to me that the time to complain about namespace
clutter was when gettext.install was written. Besides, it's
only "clutter" if you're not using it, and if you're not
using it, just don't call install.

Making _ dispatch on the number of arguments would break all
the existing string extraction tools. It's also unintuitive
for anyone coming from gettext in other languages. It's also
messy semantic overloading.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-11-06 20:21

Message:
Logged In: YES 
user_id=1188172

The problem you diagnosed is valid, but I don't think the
patch is a proper way to salvage it (by cluttering the
builtin namespace).

I'd rather have the installed name "_" point to a wrapper
object that gives one access to the other translation functions.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349274&group_id=5470