Showing content from http://mail.python.org/pipermail/python-dev/attachments/20171128/9369e9d1/attachment.html below:
<div dir="ltr"><div class="gmail_default" style="font-size:small">I was going to suggest the final DeprecationWarning should be raised unconditionally (subject to whatever silencing rules are agreed) by the final 2.7 release to recommend migration to Python 3.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">"This is an ex-language ... it has ceased to be ... it is no more ... it has returned to the great heap whence it came ..."</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Steve Holden<br></div></div></div>
<br><div class="gmail_quote">On Tue, Nov 28, 2017 at 5:13 PM, Brett Cannon <span dir="ltr"><<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div><div class="h5"><div dir="ltr">On Tue, 28 Nov 2017 at 03:33 Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 28 November 2017 at 15:42, Larry Hastings <<a href="mailto:larry@hastings.org" target="_blank">larry@hastings.org</a>> wrote:<br>
> On 11/27/2017 03:58 PM, Yury Selivanov wrote:<br>
>> We can't say anything about the order if someone passes a partial<br>
>> object<br>
><br>
> Sure we could. We could ensure that functools.partial behaves in a sane<br>
> way, then document and guarantee that behavior.<br>
<br>
Right, I think the main implication here would be that we need to<br>
ensure that any signature manipulation operations *we* provide are<br>
order preserving.<br>
<br>
Fortunately for Larry, we kinda cheat on that front: all the logic for<br>
dealing with this problem is in the inspect module itself, which knows<br>
about all the different ways we manipulate signatures in the standard<br>
library. That means that if we want to declare that the inspect module<br>
will be order preserving, we can, and it shouldn't require changes to<br>
anything else.<br>
<br>
Cheers,<br>
Nick.<br>
<br>
P.S. Note that inspect.getfullargspec() was actually undeprecated a<br>
while back - enough folks that didn't need access to the function<br>
annotations were reimplementing it for themselves "because the<br>
standard library API is deprecated" that the most logical course of<br>
action was to just declare it as being supported again. I don't think<br>
that changes the argument here though - it just means guaranteed order<br>
preservation in that API will only happen if we declare dicts to be<br>
insertion ordered in general.<br></blockquote><div><br></div></div></div><div>OT for this thread, but is there an issue number tracking the un-deprecating? Basically I want to make sure there is an issue tracking deprecating it again when we stop worrying about any Python 2/3 support. <br></div></div></div>
<br>______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/steve%40holdenweb.com" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>steve%40holdenweb.com</a><br>
<br></blockquote></div><br></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4