Re: [gentoo-dev] Locale check in python_pkg_setup()

[Harald van Dijk]

On Mon, Aug 02, 2010 at 11:02:20PM +0200, Arfrever Frehtes Taifersar Arahesis wrote:
> It would have to be parsed using e.g. grep and sed. It's easier to call Python in this case.

It's even easier not to.

> The call to Python is sufficiently fast:
>
> $ time python -c 'import os; print(os.environ.get("LC_ALL", os.environ.get("LC_CTYPE", os.environ.get("LANG", "POSIX"))))' > /dev/null
>
> real    0m0.062s
> user    0m0.051s
> sys     0m0.011s

Let's compare. On my system:

time python -c 'import os; print(os.environ.get("LC_ALL", os.environ.get("LC_CTYPE", os.environ.get("LANG", "POSIX"))))'
en_GB.UTF-8

real	0m0.020s
user	0m0.016s
sys	0m0.004s

time sh -c 'echo "${LC_ALL:-${LC_CTYPE:-${LANG:-POSIX}}}"'
en_GB.UTF-8

real	0m0.001s
user	0m0.000s
sys	0m0.000s

And that's after several runs for both, so it's not caused by the
initial load of python, which wasn't in memory yet.

Yes, 0.019s is very little, but in this case I see absolutely no benefit
whatsoever in calling python. Plus sh has the advantage of actually
working when LC_ALL is exported as "" (which in LC_* means the same as
having it unset)...

But why exactly are you concerned about LC_* being defined but not
exported anyway? You're checking from an ebuild; locales are going to
get inherited from portage or profile.env anyway, so you can just
assume that if they _are_ set, they're exported. The only way they might
not be is if the user is messing with the locale from the bashrc, and if
the user's doing that, the user really needs to fix the bashrc and
export the vars anyway.

None of this changes the fact that locale checks warns about bugs in packages,
not bugs in the user's configuration.