<div dir="ltr">Nick and Victor,<br><br>I'm still hoping to accept this PEP, but I don't have time to wrap my head around -Xdev ("devmode"?) which appears to be Victor's latest pet project. Should PEP 565 be changed to copy with devmode's behavior, or the other way around, or should they just ignore each other? It is not clear of me what the status of the mention in PEP 565 of -Xdev is -- normative or informational? I really don't want to have to learn how devmode works in order to be able to accept PEP 565 (or send it back for revision), so I am asking you two to let me know.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 6, 2017 at 1:42 AM, Victor Stinner <span dir="ltr"><<a href="mailto:victor.stinner@gmail.com" target="_blank">victor.stinner@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 dir="auto"><div class="gmail_extra" dir="auto">Let's discuss -Xdev implementation issue at <a href="https://bugs.python.org/issue32230" target="_blank">https://bugs.python.org/<wbr>issue32230</a></div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto">In short, -Xdev must add its warning at the end to respect BytesWarning, whereas it's not possible with -W option :-(</div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto">Victor</div></font></span><div><div class="h5"><div class="gmail_extra" dir="auto"><br><div class="gmail_quote" dir="auto">Le 6 déc. 2017 09:15, "Nick Coghlan" <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> a Ã©crit :<br type="attribution"><blockquote class="m_-1547562771879160598quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-1547562771879160598quoted-text">On 6 December 2017 at 14:50, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>
> On 6 December 2017 at 14:34, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>
>> That said, I go agree we could offer easier to use APIs to app<br>
>> developers that just want to hide warnings from their users, so I've<br>
>> filed <a href="https://bugs.python.org/issue32229" rel="noreferrer" target="_blank">https://bugs.python.org/issue3<wbr>2229</a> to propose a straightforward<br>
>> "warnings.hide_warnings()" API that encapsulates things like checking<br>
>> for a non-empty sys.warnoptions list.<br>
><br>
> I've updated the "Limitations" section of the PEP to mention that<br>
> separate proposal:<br>
> <a href="https://github.com/python/peps/commit/6e93c8d2e6ad698834578d4077b92a8fc84a70f5" rel="noreferrer" target="_blank">https://github.com/python/peps<wbr>/commit/6e93c8d2e6ad698834578d<wbr>4077b92a8fc84a70f5</a><br>
<br>
</div>Having rebased the PEP 565 patch atop the "-X dev" changes, I think<br>
that if we don't change some of the details of how `-X dev` is<br>
implemented, `warnings.hide_warnings` (or a comparable convenience<br>
API) is going to be a requirement to help app developers effectively<br>
manage their default warnings settings in 3.7+.<br>
<br>
The problem is that devmode doesn't currently behave the same way<br>
`-Wd` does when it comes to sys.warnoptions:<br>
<br>
  Â  $ ./python -Wd -c "import sys; print(sys.warnoptions);<br>
print(sys.flags.dev_mode)"<br>
  Â  ['d']<br>
  Â  False<br>
  Â  $ ./python -X dev -c "import sys; print(sys.warnoptions);<br>
print(sys.flags.dev_mode)"<br>
  Â  []<br>
  Â  True<br>
<br>
As currently implemented, the warnings module actually checks<br>
`sys.flags.dev_mode` directly during startup (or `sys._xoptions` in<br>
the case of the pure Python fallback), and populates the warnings<br>
filter differently depending on what it finds:<br>
<br>
  Â  $ ./python -c "import warnings; print('\n'.join(map(str,<br>
warnings.filters)))"<br>
  Â  ('default', None, <class 'DeprecationWarning'>, '__main__', 0)<br>
<div class="m_-1547562771879160598quoted-text">  Â  ('ignore', None, <class 'DeprecationWarning'>, None, 0)<br>
</div><div class="m_-1547562771879160598quoted-text">  Â  ('ignore', None, <class 'PendingDeprecationWarning'>, None, 0)<br>
</div><div class="m_-1547562771879160598quoted-text">  Â  ('ignore', None, <class 'ImportWarning'>, None, 0)<br>
</div><div class="m_-1547562771879160598quoted-text">  Â  ('ignore', None, <class 'BytesWarning'>, None, 0)<br>
</div><div class="m_-1547562771879160598quoted-text">  Â  ('ignore', None, <class 'ResourceWarning'>, None, 0)<br>
<br>
</div>  Â  $ ./python -X dev -c "import warnings; print('\n'.join(map(str,<br>
warnings.filters)))"<br>
<div class="m_-1547562771879160598quoted-text">  Â  ('ignore', None, <class 'BytesWarning'>, None, 0)<br>
</div><div class="m_-1547562771879160598quoted-text">  Â  ('default', None, <class 'ResourceWarning'>, None, 0)<br>
</div><div class="m_-1547562771879160598quoted-text">  Â  ('default', None, <class 'Warning'>, None, 0)<br>
<br>
</div>  Â  $ ./python -Wd -c "import warnings; print('\n'.join(map(str,<br>
warnings.filters)))"<br>
<div class="m_-1547562771879160598quoted-text">  Â  ('default', None, <class 'Warning'>, None, 0)<br>
</div>  Â  ('default', None, <class 'DeprecationWarning'>, '__main__', 0)<br>
<div class="m_-1547562771879160598quoted-text">  Â  ('ignore', None, <class 'DeprecationWarning'>, None, 0)<br>
</div><div class="m_-1547562771879160598quoted-text">  Â  ('ignore', None, <class 'PendingDeprecationWarning'>, None, 0)<br>
</div><div class="m_-1547562771879160598quoted-text">  Â  ('ignore', None, <class 'ImportWarning'>, None, 0)<br>
</div><div class="m_-1547562771879160598quoted-text">  Â  ('ignore', None, <class 'BytesWarning'>, None, 0)<br>
</div><div class="m_-1547562771879160598quoted-text">  Â  ('ignore', None, <class 'ResourceWarning'>, None, 0)<br>
<br>
</div>This means the app development snippet proposed in the PEP will no<br>
longer do the right thing, since it will ignore the dev mode flag:<br>
<br>
  Â  if not sys.warnoptions:<br>
  Â  Â  Â  # This still runs for `-X dev`<br>
  Â  Â  Â  warnings.simplefilter("ignore"<wbr>)<br>
<br>
My main suggested fix would be to adjust the way `-X dev` is<br>
implemented to include `sys.warnoptions.append('defau<wbr>lt')` (and remove<br>
the direct dev_mode query from the warnings module code).<br>
<br>
However, another possible way to go would be to make the correct<br>
Python 3.7+-only snippet look like this:<br>
<br>
  Â  import warnings<br>
  Â  warnings.hide_warnings()<br>
<br>
And have the forward-compatible snippet look like this:<br>
<br>
  Â  import warnings:<br>
  Â  if hasattr(warnings, "hide_warnings"):<br>
  Â  Â  Â  # Accounts for `-W`, `-X dev`, and any other implementation<br>
specific settings<br>
  Â  Â  Â  warnings.hide_warnings()<br>
  Â  else:<br>
  Â  Â  Â  # Only accounts for `-W`<br>
  Â  Â  Â  import sys<br>
<div class="m_-1547562771879160598quoted-text">  Â  Â  Â  if not sys.warnoptions:<br>
  Â  Â  Â  Â  Â  warnings.simplefilter("ignore"<wbr>)<br>
<br>
</div>(We can also do both, of course)<br>
<div class="m_-1547562771879160598elided-text"><br>
Cheers,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan  Â |  Â <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>  Â |  Â Brisbane, Australia<br>
</div></blockquote></div><br><br></div></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/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>guido%40python.org</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>