While running regrtest with -R to find reference leaks I found a usage issue. When a codec is registered it is stored in the interpreter state and cannot be removed. Since it is stored as a list, if you repeated add the same search function, you will get duplicates in the list and they can't be removed. This shows up as a reference leak (which it really isn't) in test_unicode with this code modified from test_codecs_errors: import codecs def search_function(encoding): def encode1(input, errors="strict"): return 42 return (encode1, None, None, None) codecs.register(search_function) ### Should the search function be added to the search path if it is already in there? I don't understand a benefit of having duplicate search functions. Should users have access to the search path (through a codecs.unregister())? If so, should it search from the end of the list to the beginning to remove an item? That way the last entry would be removed rather than the first. n
Neal Norwitz wrote:
While running regrtest with -R to find reference leaks I found a usage issue. When a codec is registered it is stored in the interpreter state and cannot be removed. Since it is stored as a list, if you repeated add the same search function, you will get duplicates in the list and they can't be removed. This shows up as a reference leak (which it really isn't) in test_unicode with this code modified from test_codecs_errors:
import codecs def search_function(encoding): def encode1(input, errors="strict"): return 42 return (encode1, None, None, None)
codecs.register(search_function)
###
Should the search function be added to the search path if it is already in there? I don't understand a benefit of having duplicate search functions.
Me neither :-) I never expected someone to register a search function more than once, since there's no point in doing so.
Should users have access to the search path (through a codecs.unregister())?
Maybe, but why would you want to unregister a search function ?
If so, should it search from the end of the list to the beginning to remove an item? That way the last entry would be removed rather than the first.
I'd suggest to raise an exception in case a user tries to register a search function twice. Removal should be the same as doing list.remove(), ie. remove the first (and only) item in the list of search functions. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 24 2005)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
On 11/24/05, M.-A. Lemburg
Should users have access to the search path (through a codecs.unregister())?
Maybe, but why would you want to unregister a search function ?
If so, should it search from the end of the list to the beginning to remove an item? That way the last entry would be removed rather than the first.
I'd suggest to raise an exception in case a user tries to register a search function twice.
This should take care of the testing problem.
Removal should be the same as doing list.remove(), ie. remove the first (and only) item in the list of search functions.
Do you recommend adding an unregister()? It's not necessary for this case. n
Neal Norwitz wrote:
On 11/24/05, M.-A. Lemburg
wrote: Should users have access to the search path (through a codecs.unregister())?
Maybe, but why would you want to unregister a search function ?
If so, should it search from the end of the list to the beginning to remove an item? That way the last entry would be removed rather than the first.
I'd suggest to raise an exception in case a user tries to register a search function twice.
This should take care of the testing problem.
Removal should be the same as doing list.remove(), ie. remove the first (and only) item in the list of search functions.
Do you recommend adding an unregister()? It's not necessary for this case.
Not really - I don't see much of a need for this; except maybe if a codec package wants to replace another codec package. So far no-one has requested such a feature, so I'd say we don't add .unregister() until a request for it pops up. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 24 2005)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
participants (2)
-
M.-A. Lemburg
-
Neal Norwitz