Message 109062 - Python tracker

➜

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	belopolsky
Recipients	alexandre.vassalotti, belopolsky, benjamin.peterson, mark.dickinson, pitrou, r.david.murray
Date	2010-07-01.17:52:56
SpamBayes Score	0.00048050808
Marked as misclassified	No
Message-id	<1278006779.13.0.393666567821.issue9104@psf.upfronthosting.co.za>
In-reply-to

Content
On Thu, Jul 1, 2010 at 12:18 PM, Antoine Pitrou <report@bugs.python.org> wrote: .. >> I don't understand how having multiple modules in the blocked list >> will help in io case. io.py will simply not work if _io is blocked. > > Which you avoid by giving an empty list of blocked modules, using > Alexandre's suggestion. > Yes, you can make import_module_implementations('io') return [io] this way, but what the user is likely to expect would be [io, _pyio]. I understand that there are reasons to keep io the way it is, but most of the other modules should probably follow pickle approach. In any case, testing alternative io implementations is easy. No import block trickery is needed - just import io and _pyio separately. I just don't like the idea of having test.support know details about other modules and would like to have a clear use case before doing anything more sophisticated than blocking '_' + name. If we end up with a central registry of native optimizations, it should probably not be in test.support.

On Thu, Jul 1, 2010 at 12:18 PM, Antoine Pitrou <report@bugs.python.org> wrote:
..
>> I don't understand how having multiple modules in the blocked list
>> will help in io case.  io.py will simply not work if _io is blocked.
>
> Which you avoid by giving an empty list of blocked modules, using
> Alexandre's suggestion.
>

Yes, you can make import_module_implementations('io') return [io] this way, but what the user is likely to expect would be [io, _pyio].

I understand that there are reasons to keep io the way it is, but most of the other modules should probably follow pickle approach.  In any case, testing alternative io implementations is easy.  No import block trickery is needed - just import io and _pyio separately.

I just don't like the idea of having test.support know details about other modules and would like to have a clear use case before doing anything more sophisticated than blocking '_' + name.

If we end up with a central registry of native optimizations, it should probably not be in test.support.

History
Date	User	Action	Args
2010-07-01 17:52:59	belopolsky	set	recipients: + belopolsky, mark.dickinson, pitrou, alexandre.vassalotti, benjamin.peterson, r.david.murray
2010-07-01 17:52:59	belopolsky	set	messageid: <1278006779.13.0.393666567821.issue9104@psf.upfronthosting.co.za>
2010-07-01 17:52:57	belopolsky	link	issue9104 messages
2010-07-01 17:52:56	belopolsky	create