<p><br>
On Feb 5, 2012 5:36 PM, "Steven D&apos;Aprano" <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br>
><br>
> Paul Moore wrote:<br>
>><br>
>> On 4 February 2012 11:25, Steven D'Aprano <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br>
>>><br>
>>> It strikes me that it would be helpful sometimes to programmatically<br>
>>> recognise "preview" modules in the std lib. Could we have a recommendation<br>
>>> in PEP 8 that such modules should have a global variable called PREVIEW, and<br>
>>> non-preview modules should not, so that the recommended way of telling them<br>
>>> apart is with hasattr(module, "PREVIEW")?<br>
>><br>
>><br>
>> In what situation would you want that when you weren't referring to a<br>
>> specific module? If you're referring to a specific module and you<br>
>> really care, just check sys.version. (That's annoying and ugly enough<br>
>> that it'd probably make you thing about why you are doing it - I<br>
>> cannot honestly think of a case where I'd actually want to check in<br>
>> code if a module is a preview - hence my question as to what your use<br>
>> case is).<br>
><br>
><br>
> What's the use-case for any sort of introspection functionality? I would say that the ability to perform introspection is valuable in and of itself, regardless of any other concrete benefits.<br>
><br>
> We expect that modules may change APIs between the preview and non-preview ("stable") releases. I can see value in (say) being forewarned of API changes from the interactive interpreter, without having to troll through documentation looking for changes, or waiting for an exception. Or having to remember exactly which version modules were added in, and when they left preview. (Will this *always* be one release later? I doubt it.)<br>
><br>
> If you don't believe that preview modules will change APIs, or that it would be useful to detect this programmatically when using such a module, then there's probably nothing I can say to convince you otherwise. But I think it will be useful. Python itself has a sys.version so you can detect feature sets and changes in semantics; this is just the same thing, only milder.<br>
><br>
> The one obvious way[1] is to explicitly tag modules as preview, and the simplest way to do this is with an attribute. (Non-preview modules shouldn't have the attribute at all -- non-preview is the default state, averaged over the entire lifetime of a module in the standard library.)<br>
><br>
> It would be just nice to sit down at the interactive interpreter and see whether a module you just imported was preview or not, without having to look it up in the docs. I do nearly everything at the interpreter: I read docs using help(), I check where modules are located using module.__file__. This is just more of the same.<br>
><br>
> Some alternatives:<br>
><br>
> 1) Don't try to detect whether it is a preview module, but use EAFP to detect features that have changed:<br>
><br>
> try:<br>
> result = spam.foo(x, y)<br>
> except AttributeError:<br>
> # Must be a preview release. Do something else.<br>
> result = spam.bar(y, x)<br>
><br>
> This is preferred so long as the differences between preview and stable releases are big, obvious changes like a function being renamed. But if there are subtle changes that you care about, things get dicey. spam.foo may not raise an exception, but just do something completely unexpected.<br>
><br>
><br>
><br>
> 2) As you suggest, write version-specific code:<br>
><br>
> if sys.version >= "3.4":<br>
> result = spam.foo(x, y)<br>
> else:<br>
> # Preview release.<br>
> result = spam.bar(y, x)<br>
><br>
><br>
> This starts to get messy fast, particularly if (worst case, and I *really* hope this doesn't happen!) modules get put into preview, then get withdrawn, then a few releases later get put back in. This sort of mess shouldn't ever happen with non-preview modules, but preview modules explicitly have weaker guarantees.<br>
><br>
> And I can never remember when modules were added to the std lib.<br>
><br>
><br>
><br>
><br>
>> Feels like YAGNI to me.<br>
><br>
><br>
> When people talk about YAGNI, they are referring to the principle that you shouldn't waste time and effort over-engineering a complex solution or providing significant additional functionality for no obvious gain. I don't think that<br>
><br>
> PREVIEW = True<br>
><br>
> in a module *quite* counts as over-engineered.</p>
<p>How about sys.preview_modules to list all the preview modules in the current release? This would be useful at the interactive prompt, at the least.</p>
<p>-eric</p>