Re: Trouble with new tracker designator?

On Tue, Jul 21, 2020 at 11:50:05PM -0400, John P. Rouillard wrote:
> I am not quite sure what you mean by only an anchor on the first
> character. designator_re has both ends anchored. I think to support
> "zip2py" as a class name you have to have both anchors or the re will
> end at the first 2.
> 
> I did a little performance testing with the various possible re's
> and a subset of the cases you tested.
> 
> Compiling the better re is .9% slower and your best re is 3.6% worse
> than current.
> 
> Matching is 35% worse for the better re and 45% worse for your best
> re. I don't have good stats on how often splitDesignator is called and
> how much of an impact a 45% slowdown would cause. Trying to use
> cProfile and pstats isn't exactly clear.

I don't think that parsing a string of typically max. len 20 or so will
significantly impact performance.
So 

> Technically _ is not a letter. I wonder if we should keep classes
> starting with _ in reserve for future use (hidden/internal class for
> whatever that means).

Yes, especially since roundup re-maps table names to start with an
underscore, no idea what a double underscore would do but I'd not permit
names with a starting underscore.

> 
> However if we properly limit class names in Class::__init__ I wonder
> if we can simplify the re in splitDesignator assuming that the
> designator has a classname of initial alpha, alphanumerics (plus _)
> and no trailing digits. That still leaves us with a 35% slowdown over
> the current re which doesn't support embedded numbers in classnames
> 8-(.

Fine with me.

Thanks to Tom for finding this and reporting it!
And thanks John for so deeply looking into it.

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: [email protected]