[Python-Dev] Choosing a best practice solution for Python/extensionmodules

Raymond Hettinger python at rcn.com
Fri Feb 20 22:09:27 CET 2009


I don't have a particular solution mind.  Just wanted to reframe the question
to be a more general one about the controlling the selection between near
equivalent modules and extensions.  Some variant of the problem seems to
come-up in many different contexts.  No one best practice has emerged as
dominant. 
  ----- Original Message ----- 
  From: Brett Cannon 
  To: Raymond Hettinger 
  Cc: Python Dev 
  Sent: Friday, February 20, 2009 12:41 PM
  Subject: Re: [Python-Dev] Choosing a best practice solution for Python/extensionmodules





  On Fri, Feb 20, 2009 at 12:33, Raymond Hettinger <python at rcn.com> wrote:

    [Brett]


      With io getting rewritten as an extension module, I think it's time to try to come up with a good best practice scenario for how to be able to control when  a module uses a pure Python implementation and when it uses extension module optimizations. This is really only important for testing as if the extension is missing then the pure Python version is just flat-out used.



    There is also need in some modules where the two are not exactly equivalent
    or where there are multiple C extensions to choose from.  In PyYAML, there needs to be an easier way to switch parsers and emitters (i.e. LibYAML).
    There are similar issues with xmlrpclib with the choice of parsers, marshallers,
    and unmarshallers.  Possibly, the same mechanism can offer the user more
    control over which dbm is used when there are several choices.

  So are you saying you want something that takes multiple arguments like ``use_extension(py_name, *ext_names)``? Or are you wanting to go down the road of modules needing to define their own functions to use or unwind changes?

  -Brett


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20090220/db89814e/attachment.htm>


More information about the Python-Dev mailing list