MAL wrote:
> Bill Tutt wrote:
> >
> > Is there any particular reason that dynload_aix.c doesn't use AIX's
dlopen?
> > >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX
> > 4.xxx.
>
> > I was all set to integrate the \N{...} support into the Unicode-escape
> > encoding, and dynamically load the hash table data in on demand, but
> > dynload_aix only cares about module entry points and won't let you
specify
> > an explicit function name.
> Uhm, why do you need to go that deep into the internals
> of the import mechanism ?
> Wouldn't is suffice to put the hash table into a _ucnhash module
> which get imported on demand (the import mechanism would then
> take care of the rest) ?
It would suffice, but it'd be less efficient (and more work) since I'd then
have to access the data/hash functions through the normal PyObject
mechanisms instead of directly as C functions. That is, I'm trying to avoid
creating a PyString of whatever is inside the braces. (\N{SMILEY}). Then
again, maybe I'm just being too performance sensitive.
The import mechanism got redone weirdly, all of the ways of doing dynamic
loading except AIX encode the idea that the function name must be preceeded
by "init".
Dynload_xxx.c is the wrong place to put that requirement. Whomever calls
_PyImport_GetDynLoadFunc() should handle that issue.
Just as an FYI, the only problem I've found so far with my last patch was
wrt handling Unicode characters with values in the UCS-4 code space. (Not
that there are any yet, but the code must handle that case anyway, sine I
don't want to have to go change it later.)
Bill
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4