Surely preview should only contain whats being previewed for the next release then when its released with the next version they carry deprecation warnings and are removed in the following version e.g.<div><br></div><div>v1</div>
<div>__preview__.magic </div><div>v2</div><div>deprecate(__preview__.magic)</div><div>v3</div><div>There is no longer __preview__.magic in __preview__<br><br><br><div class="gmail_quote">On Wed, Jan 4, 2012 at 11:49 AM, Devin Jeanpierre <span dir="ltr"><<a href="mailto:jeanpierreda@gmail.com">jeanpierreda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> A correct way IMO would be to introduce a versioned exp27, exp271 packages:<br>
<br>
</div>+2. Rather than silently introducing subtle semantics changes,<br>
wouldn't it be better for older imports to fail with an ImportError?<br>
Since this is just for toying around, this shouldn't break any play,<br>
but it _should_ discourage (very strongly) people using experimental<br>
stuff in their published code.<br>
<br>
Perhaps a dunder name like __preview32__ ? __preview__._32 ?<br>
<div class="im"><br>
> 1. It makes it explicitly clear when imported package version was considered<br>
> experimental<br>
<br>
</div>I agree with this too. It's a good benefit.<br>
<div class="im"><br>
> 2. It allows to switch between multiple experimental package versions<br>
> 3. It will provide future compatibility if a package released from `exp`<br>
> breaks API<br>
<br>
</div>Less sold on these. This isn't the purpose of __preview__ as I<br>
understand it, and including every revision of every __preview__<br>
package could increase Python's size very dramatically over time.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Devin<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Wed, Jan 4, 2012 at 5:45 AM, anatoly techtonik <<a href="mailto:techtonik@gmail.com">techtonik@gmail.com</a>> wrote:<br>
> On Wed, Jan 4, 2012 at 4:29 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
>><br>
>> On Wed, Jan 4, 2012 at 3:29 AM, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>><br>
>> wrote:<br>
>> > On Tue, 03 Jan 2012 16:27:35 +0000<br>
>> > Robert Kern <<a href="mailto:robert.kern@gmail.com">robert.kern@gmail.com</a>> wrote:<br>
>> >> The nice thing about the dunders is that no one will make a module with<br>
>> >> a<br>
>> >> conflicting name. That's really the common factor behind all uses of<br>
>> >> dunders:<br>
>> >> reserving a name for Python's use. Whether something is a protocol or<br>
>> >> bag of<br>
>> >> switches doesn't really enter into it.<br>
>> ><br>
>> > Plus, writing "from __preview__ import regex" looks cooler than<br>
>> > "from exp import regex".<br>
>><br>
>> Dunder names also alert people that something special is going on (in<br>
>> this case, it helps alert them to the fact that the modules in this<br>
>> namespace *will* be moved in the future).<br>
><br>
><br>
> I am afraid that dunders will become a standard thing in many Python<br>
> packages, because of everybody's natural desire to use latest features that<br>
> work right. That means that new people to Python will have to deal with<br>
> Python magic right from the start, which will make language more complicated<br>
> for them.<br>
><br>
> A correct way IMO would be to introduce a versioned exp27, exp271 packages:<br>
> 1. It makes it explicitly clear when imported package version was considered<br>
> experimental<br>
> 2. It allows to switch between multiple experimental package versions<br>
> 3. It will provide future compatibility if a package released from `exp`<br>
> breaks API<br>
> 5. as a sum of 2+3 above - it provides a development process and extends<br>
> time to stabilize API with public testing and feedback before freezing the<br>
> package to die in stdlib<br>
><br>
> --<br>
> anatoly t.<br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> Python-ideas mailing list<br>
> <a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
><br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
</div></div></blockquote></div><br></div>