Regular expression code implementation review between Tcl vs Python

K_Lee Google_Post at slink-software.com
Wed Nov 12 00:07:31 EST 2003


hgiese at ratiosoft.com (Helmut Giese) wrote in message news:<3fb10cc1.7910169 at News.CIS.DFN.DE>...
> On 11 Nov 2003 07:58:14 -0800, Google_Post at slink-software.com (K_Lee)
> wrote:
> 
> >I documented the regex internal implementation code for both Tcl and Python.
> >
> >As much as I like Tcl, I like Python's code much more.  
> >Tcl's Stub interface to the external commands is confusing to 
> >outsider.   I still don't get why the stub interface is needed.
> Simple. Let's create an example.
>  If you don't use it, than you have to link your extension against the
> current version of Tcl, say, tcl84.lib. Easy, no problem.
> 
> But tomorrow Tcl 8.5 comes out and you have the problem, that
> tcl85.dll is running (used by tclsh or wish) and your extension needs
> tcl84.dll, since (during its linking) you created an un-breakable
> connection between the two. 
> Solutions:
> - Stick with the older version of Tcl.
> - Re-compile the extension now linking against Tcl85.lib (and repeat
> for Tcl 8.6, 8.7, etc.)
> - Don't link against Tcl8.x lib but use the 'stub interface'. This
> avoids creating this fixed connection between your extension and a
> particular version of Tcl, and you can use the extension with any
> future version of Tcl and be happy ever after (unless the stub
> interface itself changes, but this will be in a completely different
> time frame- if it should ever happen at all).
> 
> >One aspect I don't understanding about python is that the Python
> >language itself is object oriented and all the internal is implement
> >as C object.   Why not C++ object?  
> Just my 0.02: I suppose that C++ compilers still differ a lot more on
> different platforms (concerning their conformance to the standard)
> than C compilers do. So, if portability is high on your check list, C
> still is the language of choice - but in the future C++ will catch up
> (IMHO).
> Best regards
> Helmut Giese

Helmut, Thanks for the 0.02.  :-) 

The "normal" os's dll, .so system use dlsym() call to resolve the 
function "string_name" to function pointers.   They seems to work for 
upward compatibilities for most of the cases.  

But I kind understand the argument from the statics link library 
point of view, just think the price is too high for 
such "features".   I guess the TCL original goal was also to support
Win16, DOS, etc.

For example, here's the python's code for regexp methods functions
pointers.
They are cleaner more modular than the TCL's stub table. (My 0.005)

http://www.slink-software.com/W/SL_TopGetSL/Python-2.3/Python-2.3.slk/ID_regex_global_methods/FILE_Modules/regexmodule.c/L_635/LN_635#L_632


static struct PyMethodDef regex_global_methods[] = {
	{"compile",	regex_compile, METH_VARARGS},
	{"symcomp",	regex_symcomp, METH_VARARGS},
	{"match",	regex_match, METH_VARARGS},
	{"search",	regex_search, METH_VARARGS},
	{"set_syntax",	regex_set_syntax, METH_VARARGS},
	{"get_syntax",  (PyCFunction)regex_get_syntax, METH_NOARGS},
	{NULL,		NULL}		     /* sentinel */
};


Here's the code for TCL Stub:
http://www.slink-software.com/W/SL_TopGetSL/tcl8.4.4/tcl8.4.4.slk/ID_Tcl_RegExpCompile/FILE_generic/tclStubInit.c/L_650/LN_647#L_644

...
    Tcl_RegExpCompile, /* 212 */
    Tcl_RegExpExec, /* 213 */
    Tcl_RegExpMatch, /* 214 */
    Tcl_RegExpRange, /* 215 */
...




More information about the Python-list mailing list