[Python-Dev] Summary of Python tracker Issues

2019-11-29 Thread Python tracker


ACTIVITY SUMMARY (2019-11-22 - 2019-11-29)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7170 ( -1)
  closed 43522 (+47)
  total  50692 (+46)

Open issues with patches: 2823 


Issues opened (23)
==

#38270: Tests: Avoid MD5 or check for MD5 availablity
https://bugs.python.org/issue38270  reopened by petr.viktorin

#38901: Add a CLI flag to venv to use the pwd basename as the prompt
https://bugs.python.org/issue38901  opened by brett.cannon

#38902: image/webp support in mimetypes
https://bugs.python.org/issue38902  opened by leecatball

#38903: #if 0 block on parsetok.c
https://bugs.python.org/issue38903  opened by eamanu

#38904: "signal only works in main thread" in main thread
https://bugs.python.org/issue38904  opened by Richard Warfield

#38905: venv python reports wrong sys.executable in a subprocess on Wi
https://bugs.python.org/issue38905  opened by uranusjr

#38906: copy2 doesn't copy metadata on Windows and MacOS
https://bugs.python.org/issue38906  opened by greggman

#38907: Add IPv6 Dual-Stack control for http.server
https://bugs.python.org/issue38907  opened by zkonge

#38908: Troubles with @runtime_checkable protocols
https://bugs.python.org/issue38908  opened by levkivskyi

#38912: test_asyncio altered the execution environment
https://bugs.python.org/issue38912  opened by pablogsal

#38913: Py_BuildValue("(s#O)", ...) segfaults if entered with exceptio
https://bugs.python.org/issue38913  opened by danielen

#38914: Clarify wording for warning message when checking a package
https://bugs.python.org/issue38914  opened by jugmac00

#38916: Remove array.fromstring
https://bugs.python.org/issue38916  opened by corona10

#38918: Add __module__ entry for function type in inspect docs table.
https://bugs.python.org/issue38918  opened by eric.snow

#38920: Audit events for unhandled exceptions
https://bugs.python.org/issue38920  opened by steve.dower

#38921: Max Recursion Depth Reached in Logging Library
https://bugs.python.org/issue38921  opened by joy

#38924: pathlib paths .normalize()
https://bugs.python.org/issue38924  opened by iciocirlan

#38926: MacOS: 'Install certificates.command' has no effect
https://bugs.python.org/issue38926  opened by Jeff Berkowitz

#38932: unittest.mock.Mock.reset_mocks does not pass all arguments to 
https://bugs.python.org/issue38932  opened by vegarsti

#38936: fatal error during installation 0x80070643 during python insta
https://bugs.python.org/issue38936  opened by kiranmai velishala

#38937: NameError in list comprehension within .pth file
https://bugs.python.org/issue38937  opened by Chris Billington

#38938: Iterable merge performance and inclusion in itertools
https://bugs.python.org/issue38938  opened by Dennis Sweeney

#38941: xml.etree.ElementTree.Element inconsistent warning for bool
https://bugs.python.org/issue38941  opened by philiprowlands



Most recent 15 issues with no replies (15)
==

#38926: MacOS: 'Install certificates.command' has no effect
https://bugs.python.org/issue38926

#38918: Add __module__ entry for function type in inspect docs table.
https://bugs.python.org/issue38918

#38912: test_asyncio altered the execution environment
https://bugs.python.org/issue38912

#38903: #if 0 block on parsetok.c
https://bugs.python.org/issue38903

#38902: image/webp support in mimetypes
https://bugs.python.org/issue38902

#38887: test_asyncio: test_pipe_handle() failed on AMD64 Windows7 SP1 
https://bugs.python.org/issue38887

#38886: permissions too restrictive in zipfile.writestr
https://bugs.python.org/issue38886

#38883: Path.home() should ignore HOME env var like os.path.expanduser
https://bugs.python.org/issue38883

#38880: Subinterpreters: List interpreters associated with a channel e
https://bugs.python.org/issue38880

#38879: Reordered error checking in PyArena_New().
https://bugs.python.org/issue38879

#38872: Document exec symbol for codeop.compile_command
https://bugs.python.org/issue38872

#38867: Enable Tkinter on Windows ARM
https://bugs.python.org/issue38867

#38860: GenericPyCData_new does not invoke new or init
https://bugs.python.org/issue38860

#38856: wait_closed() can raise ConnectionResetError
https://bugs.python.org/issue38856

#38851: UDPLITE tests fail on android
https://bugs.python.org/issue38851



Most recent 15 issues waiting for review (15)
=

#38937: NameError in list comprehension within .pth file
https://bugs.python.org/issue38937

#38932: unittest.mock.Mock.reset_mocks does not pass all arguments to 
https://bugs.python.org/issue38932

#38920: Audit events for unhandled exceptions
https://bugs.python.org/issue38920

#38918: Add __module__ entry for function type in inspect docs table.
https://bugs.python.org/issue38918

#38914: Clarify wording for warning message when checking

[Python-Dev] Re: Should we require all deprecations to have a removal version that we follow through on?

2019-11-29 Thread Brett Cannon
Nick Coghlan wrote:
> On Thu., 28 Nov. 2019, 4:43 am Brett Cannon, [email protected] wrote:
> > What do people think of the idea of requiring all
> > deprecations specifying
> > a version that the feature will be removed in (which under our annual
> > release cadence would be at least the third release from the start of the
> > deprecation, hence the deprecation being public for 2 years)? And that we
> > also follow through with that removal?
> > Now I'm not suggesting it must be in three feature releases. A
> > deprecation could be set to Python 4 if people truly feel keeping the code
> > is as easy it gets in terms of maintenance and there's enough usage to
> > warrant such a potential indefinite deprecation/maintenance while keeping
> > the code and docs alive (basically "there are better ways to do this, but
> > this works fine, too, if you were already using it").
> > As long as it's optional, a new deprecation helper that automatically
> escalated to FutureWarning in X.Y.0a0, and an outright error in X.Y.0b0
> seems like a good idea to me.

The helper wouldn't be required, but I would say the message of when the 
removal will occur would be. And good idea about flipping in the beta stage.

> (Escalating to errors as soon as the version number changes would be a
> problem from a development process point of view)
> If we don't add a helper API, then this sounds like a restatement of the
> status quo to me, rather than a change in policy.

Well, it's an unspoken policy that I would like to write down. :) I would also 
then advocate to go into the code and docs and update it all to provide removal 
version targets.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/B6IVFF6MXSLIQYPJWMA33QQ4C6427ZJP/
Code of Conduct: http://python.org/psf/codeofconduct/