This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients christian.heimes, eli.bendersky, loewis, ncoghlan, pitrou, vstinner
Date 2013-08-12.14:00:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1376316018.51.0.588335277736.issue18710@psf.upfronthosting.co.za>
In-reply-to
Content
> Previously, the only way to add a dialect was through register_dialect that does
> type checking to make sure it gets a legit dialect object. Now, the _dialects dict is 
> directly accessible to Python code and it can add arbitrary objects to it (both as
> keys and as values). Does this mean that the C code now has to do type checking in all 
> internal code that accesses _dialects?

You are right, I forgot about that part. That will make the patch significantly more complicated.

> However, it's a step in the right direction in case we do have multiple instances of
> the extension module alive at the same time in the future. Although then it would be
> interesting to consider how to find the actually correct module instance from internal 
> functions.

This sounds basically impossible (which is why we *can't* have multiple instances of an extension module alive in a single interpreter :-)).
History
Date User Action Args
2013-08-12 14:00:18pitrousetrecipients: + pitrou, loewis, ncoghlan, vstinner, christian.heimes, eli.bendersky
2013-08-12 14:00:18pitrousetmessageid: <1376316018.51.0.588335277736.issue18710@psf.upfronthosting.co.za>
2013-08-12 14:00:18pitroulinkissue18710 messages
2013-08-12 14:00:18pitroucreate