[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: ANSI Terminal Colors Module
- From: Alexander Gladysh <agladysh@...>
- Date: Mon, 28 Dec 2009 21:38:27 +0300
>>> Also, I'd like to have color constants visible from outside the
>>> module, in case I'd ever want to implement my own makecolor.
>> What kind of makecolor adaptation did you have in mind?
> Well, nothing in particular right now. But I think that those
> constants do have value for themselves.
I'd like to add to my answer. :-)
The makecolor() as it is now is fine and clever, but I see several
small performance problems there. This is unnoticeable in most
use-cases, but sometimes people need every drop of performance.
For example, in functional form, it concatenates string:
return self .. s .. _M.reset
This would create extra garbage. Also I see here an extra __concat()
Also, __concat unnecessarily calls __tostring on self (it could just
use self.value). Also, self.value could be self. :-)
For the use-cases when performance is critical (like log parsing and
highlighting), I'd like to have less convenient, but faster interface.
It is not necessary at all that such interface should be a part of
your module. But, by exporting constants (and that "magic"
concatentation from makecolor()) you'd increase reuse. It is probably
better to split ansicolor to two modules then, one high-level, one