Re: [Python-Dev] Timeline for Pull request reviews in 3.8

[Eric V. Smith]

Hi, Anthony.

On 4/5/2018 10:57 PM, Anthony Flury via Python-Dev wrote:
Can anyone enlighten me on what the expected time-line is for reviewing 
pull requests made on 3.8.


I can give you the timeline for releases. Unfortunately, volunteer time 
is short for reviews.


I made a few simple fixes in Early March - and I understand everyone is 
busy.


If you mention the issues, someone might take a look at them.


What is the time line and cut off dates for backports to 3.7 and 3.6.


Both are closed to new features and open for bug fixes. PEP 494 has the 
3.6 schedule and PEP 537 has the 3.7 schedule. For 3.6 the last binary 
release is currently scheduled for 2018-12-03.


I also made a documentation change (based on a open bug report) into 
2.7, and I am keen to understand the planned time-line for those too.


PEP 373 has the 2.7 release schedule.

Eric.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Can't open standard streams with "a"

[Skip Montanaro]

In Python 2 you can open the standard output and error streams in
append mode, despite the fact that they aren't technically seekable.
This changed somewhere along the way in (I think) io.open. There's an
open bug report about this:

https://bugs.python.org/issue27805

I just stumbled on it porting an application from Py2 to Py3 where my
default logfile is /dev/stderr. I don't ever want to truncate a user's
logfile, so "a" is a nice default, but in case the user doesn't name a
logfile, I have to test, just in case /dev/stderr is the candidate.
This seems error-prone, and must be done in all applications. The Py2
behavior seems less error-prone. I know explicit is better than
implicit, but practicality also beats purity. Also, os.open is fine
with O_APPEND on these streams.

Any chance of this getting into 3.7 or will a fix have to wait for 3.8
at this point? (I'm guessing "no" as I don't see a patch.)

Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2018-03-30 - 2018-04-06)
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:
  open6568 (+25)
  closed 38420 (+27)
  total  44988 (+52)

Open issues with patches: 2558 


Issues opened (40)
==

#23403: Use pickle protocol 4 by default?
https://bugs.python.org/issue23403  reopened by lukasz.langa

#31455: ElementTree.XMLParser() mishandles exceptions
https://bugs.python.org/issue31455  reopened by zach.ware

#33187: Document ElementInclude (XInclude) support in ElementTree
https://bugs.python.org/issue33187  opened by scoder

#33188: dataclass MRO entry resolution for type variable metaclasses: 
https://bugs.python.org/issue33188  opened by Ricyteach

#33189: pygettext doesn't work with f-strings
https://bugs.python.org/issue33189  opened by Riccardo Polignieri

#33190: problem with ABCMeta.__prepare__ when called after types.new_c
https://bugs.python.org/issue33190  opened by Ricyteach

#33191: Refleak in posix_spawn
https://bugs.python.org/issue33191  opened by zach.ware

#33192: asyncio should use signal.set_wakeup_fd on Windows
https://bugs.python.org/issue33192  opened by njs

#33193: Cannot create a venv on Windows when directory path contains d
https://bugs.python.org/issue33193  opened by Stuart Cuthbertson

#33194: Path-file objects does not have method to delete itself if its
https://bugs.python.org/issue33194  opened by rougeth

#33196: SEGV in mp.synchronize.Lock.__repr__ in spawn'ed proc if ctx m
https://bugs.python.org/issue33196  opened by arcivanov

#33197: Confusing error message when constructing invalid inspect.Para
https://bugs.python.org/issue33197  opened by Antony.Lee

#33198: Build on Linux with --enable-optimizations fails
https://bugs.python.org/issue33198  opened by fschulze

#33200: Optimize the empty set "literal"
https://bugs.python.org/issue33200  opened by serhiy.storchaka

#33201: Modernize "Extension types" documentation
https://bugs.python.org/issue33201  opened by pitrou

#33204: IDLE: remove \b from colorizer string prefix
https://bugs.python.org/issue33204  opened by terry.reedy

#33205: GROWTH_RATE prevents dict shrinking
https://bugs.python.org/issue33205  opened by inada.naoki

#33210: pkgutil.walk_packages "prefix" option docs are misleading
https://bugs.python.org/issue33210  opened by cykerway

#33211: lineno and col_offset are wrong on function definitions with d
https://bugs.python.org/issue33211  opened by gforcada

#33212: add several options to msgfmt.py
https://bugs.python.org/issue33212  opened by umedoblock

#33213: crypt function not hashing properly on Mac (uses a specific sa
https://bugs.python.org/issue33213  opened by Ron Reiter

#33214: join method for list and tuple
https://bugs.python.org/issue33214  opened by Javier Dehesa

#33216: Wrong order of stack for CALL_FUNCTION_VAR and CALL_FUNCTION_V
https://bugs.python.org/issue33216  opened by mvaled

#33217: x in enum.Flag member is True when x is not a Flag
https://bugs.python.org/issue33217  opened by Dutcho

#33219: x in IntFlag should test raise TypeError if x is not an IntFla
https://bugs.python.org/issue33219  opened by Dutcho

#33220: Antivirus hits on python-2.7.14.amd64.msi file
https://bugs.python.org/issue33220  opened by brett.rasmus...@inl.gov

#33221: Add stats for asyncio task usage.
https://bugs.python.org/issue33221  opened by asvetlov

#33222: Various test failures if PYTHONUSERBASE is not canonicalized
https://bugs.python.org/issue33222  opened by jdemeyer

#33223: test_posix fails ERRNO 0
https://bugs.python.org/issue33223  opened by wizofe

#33225: imaplib module IMAP4.append() unexpected response BAD Command 
https://bugs.python.org/issue33225  opened by yuy

#33227: Cmd do_something only accepts one argument
https://bugs.python.org/issue33227  opened by Oz.Tiram

#33228: Use Random.choices in tempfile
https://bugs.python.org/issue33228  opened by wolma

#33229: Documentation -  io — Core tools for working with streams - 
https://bugs.python.org/issue33229  opened by Mikhail Zakharov

#33230: _decimal build failure (unsupported platform for that module) 
https://bugs.python.org/issue33230  opened by Hubert Holin

#33232: Segmentation fault in operator.attrgetter
https://bugs.python.org/issue33232  opened by asturm

#33233: Suggest third-party cmd2 module as alternative to cmd
https://bugs.python.org/issue33233  opened by ned.deily

#33234: Improve list() pre-sizing for inputs with known lengths
https://bugs.python.org/issue33234  opened by rhettinger

#33235: Better help text for dict.setdefault
https://bugs.python.org/issue33235  opened by Paddy McCarthy

#33236: MagicMock().__iter__.return_value is different from MagicMock(
https://bugs.python.org/issue33236  opened by mrh1997

#33237: Improve AttributeError message for partially initialized modul
https://bugs.python.org/issue33237  opened by serhiy.storchaka



Mo

Re: [Python-Dev] Timeline for Pull request reviews in 3.8

[Anthony Flury via Python-Dev]

All,

The three pull requests are :

Python 2.7 - doc string fix : https://github.com/python/cpython/pull/6015

Python 3.8 - documentation fix : https://github.com/python/cpython/pull/5982

Python 3.8 - Small bug fix on unittest.mock.mock_open : 
https://github.com/python/cpython/pull/5974


The Py2.7 change does not need to be rolled forward to Python3 documentation

The two Py3.8 fixes could/should/can ? be backported to earlier versions

These are all trivial with no conflicts with their target branch (or at 
least there wasn't when I made the requests).



--
Anthony Flury
email : *anthony.fl...@btinternet.com*
Twitter : *@TonyFlury *
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Timeline for Pull request reviews in 3.8

[Serhiy Storchaka]

06.04.18 19:32, Anthony Flury via Python-Dev пише:

The three pull requests are :

Python 2.7 - doc string fix : https://github.com/python/cpython/pull/6015


There are several open issues for "sequence" vs "iterable" in docstrings 
and documentation for different functions. It would be worth to merge 
all these issues and and make a general decision.


Python 3.8 - documentation fix : 
https://github.com/python/cpython/pull/5982


It needs a review from one of our floating point experts.

Python 3.8 - Small bug fix on unittest.mock.mock_open : 
https://github.com/python/cpython/pull/5974


It needs a review from one of our unittest.mock experts.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Timeline for Pull request reviews in 3.8

[Berker Peksağ]

On Fri, Apr 6, 2018 at 7:32 PM, Anthony Flury via Python-Dev
 wrote:
> All,
>
> The three pull requests are :
>
> Python 2.7 - doc string fix : https://github.com/python/cpython/pull/6015
>
> Python 3.8 - documentation fix : https://github.com/python/cpython/pull/5982

Hi Anthony,

I've just reviewed this.

> Python 3.8 - Small bug fix on unittest.mock.mock_open :
> https://github.com/python/cpython/pull/5974
>
> The Py2.7 change does not need to be rolled forward to Python3 documentation
>
> The two Py3.8 fixes could/should/can ? be backported to earlier versions

Yes, PR 5982 will be backported to 3.6 and 3.7. I'm not sure about PR
5974 though (I may be wrong because I don't have the time to triage
the issue at the moment)

--Berker
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Error embedding python

[Chris Bryan]

Hello list,

I am embedding a python 3.6 environment in another executable, which is 
compiling and executing ok. However I get an error on Windows when I try 
to import any module except sys:


Traceback (most recent call last):
  File "args", line 1, in 
  File "", line 971, in _find_and_load
  File "", line 951, in 
_find_and_load_unlocked

  File "", line 894, in _find_spec
  File "", line 1157, in find_spec
  File "", line 1129, in _get_spec
  File "", line 1245, in find_spec
  File "", line 1302, in _fill_cache
TypeError: a bytes-like object is required, not 'str'

Looking on line 1302, it would appear that the call to _os.listdir() 
(line 1285) is returning a list of byte objects. I can confirm that I 
get the same error doing the following from a normal python interactive 
session:


>>> x = b'a.b.c'
>>> x.partition('.')
Traceback (most recent call last):
  File "", line 1, in 
TypeError: a bytes-like object is required, not 'str'

Is this a bug in the bootstrap module, or am I doing something wrong 
which is causing listdir() to return bytes?


Chris

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Can't open standard streams with "a"

[Ned Deily]

On Apr 6, 2018, at 12:06, Skip Montanaro  wrote:
> [...]
> https://bugs.python.org/issue27805
> [...]
> Any chance of this getting into 3.7 or will a fix have to wait for 3.8
> at this point? (I'm guessing "no" as I don't see a patch.)

It seems like most commenters on the issue consider the behavior to be a bug so 
a case could be made for a fix to go into a maintenance release, not just a 
feature release.  But, obviously, someone needs to produce a PR for review 
first.

--
  Ned Deily
  n...@python.org -- []

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Can't open standard streams with "a"

[Antoine Pitrou]

On Fri, 6 Apr 2018 17:17:58 -0400
Ned Deily  wrote:
> On Apr 6, 2018, at 12:06, Skip Montanaro  wrote:
> > [...]
> > https://bugs.python.org/issue27805
> > [...]
> > Any chance of this getting into 3.7 or will a fix have to wait for 3.8
> > at this point? (I'm guessing "no" as I don't see a patch.)  
> 
> It seems like most commenters on the issue consider the behavior to be a bug 
> so a case could be made for a fix to go into a maintenance release, not just 
> a feature release.  But, obviously, someone needs to produce a PR for review 
> first.

OTOH this has never worked on Python 3, so it's hardly an important fix.
If it's delicate enough, we may prefer to only ship it in 3.8.

PS : it's the first time I encounter "/dev/stderr".  Apparently it's a
Linux-only symlink to "/proc/self/fd/2", i.e. the current process' file
descriptor number 2 (which is conventionally the current process'
stderr stream)!

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Soliciting comments on the future of the cmd module (bpo-33233)

[Ned Deily]

In https://bugs.python.org/issue33233, I have proposed considering deprecation 
for the cmd module:

"The cmd module in the standard library has languished for many years.  In the 
mean time, third-party replacements for it have arisen.  Perhaps the most 
popular is cmd2 which seems to be actively maintained, provides upward 
compatibility from cmd along with many desirable new features, and is 
permissively licensed.

I suggest we consider at a minimum adding a "See also:" note referencing cmd2 
to the cmd documentation in the Standard Library document, similar to what we 
do for the third-party "requests" module in the "urllib.request" documentation.

We could be even bolder and officially deprecate "cmd" and consider closing 
open enhancement issues for it on b.p.o."

What triggered this suggestion is that Oz Tiram opened an enhancement request 
for cmd with suggested code (https://bugs.python.org/issue33227) that 
implements a feature already in cmd2.  As I replied there, it seems to me to be 
almost a disservice to our users to add piecemeal enhancements to cmd at this 
point when it is essentially unmaintained and a superior alternative exists - 
that's assuming a core developer stepped up to shepherd the proposed change.

I don't have a strong feeling one way or another about the change but I think 
this might be one instance where we can and should make a decision to 
prioritize our limited volunteer resources and acknowledge the current state of 
affairs re cmd.  We've done similar things with other standard library modules 
in the past.

If you have an opinion about either recommending cmd2 in the cmd docs and/or 
deprecating cmd in 3.8, please comment on https://bugs.python.org/issue33233.

Thanks!
--Ned

https://docs.python.org/3.8/library/cmd.html
https://pypi.org/project/cmd2/
https://cmd2.readthedocs.io/

=-
  Ned Deily
  n...@python.org -- []

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Soliciting comments on the future of the cmd module (bpo-33233)

[Steven D'Aprano]

On Fri, Apr 06, 2018 at 06:02:18PM -0400, Ned Deily wrote:

> I suggest we consider at a minimum adding a "See also:" note 
> referencing cmd2 to the cmd documentation in the Standard Library 
> document, similar to what we do for the third-party "requests" module 
> in the "urllib.request" documentation.

I think the documentation note is a good idea.

But I disagree with deprecating "cmd" unless it is actively falling 
apart and no longer working, not just languishing with no feature 
improvements. Just in the last week, I've been reminded twice that many 
people using Python do so where they cannot just arbitarily pip install 
, and if a library isn't in the std lib, they can't use it 
without a lot of pain:

https://mail.python.org/pipermail/tutor/2018-April/112817.html

https://mail.python.org/pipermail/tutor/2018-April/112818.html


[...]
> What triggered this suggestion is that Oz Tiram opened an enhancement 
> request for cmd with suggested code 
> (https://bugs.python.org/issue33227) that implements a feature already 
> in cmd2.  As I replied there, it seems to me to be almost a disservice 
> to our users to add piecemeal enhancements to cmd at this point when 
> it is essentially unmaintained and a superior alternative exists - 
> that's assuming a core developer stepped up to shepherd the proposed 
> change.

It seems especially perverse to complain that the module is not being 
maintained, and then when the first person steps up with a feature 
request that might encourage giving the module some attention, to 
deprecate it instead!

*wink*

> If you have an opinion about either recommending cmd2 in the cmd docs 
> and/or deprecating cmd in 3.8, please comment on 
> https://bugs.python.org/issue33233.

I will follow up there as well.



-- 
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Soliciting comments on the future of the cmd module (bpo-33233)

[Raymond Hettinger]

> On Apr 6, 2018, at 3:02 PM, Ned Deily  wrote:
> 
> We could be even bolder and officially deprecate "cmd" and consider closing 
> open enhancement issues for it on b.p.o."

FWIW, the pdb module depends on the cmd module.

Also, I still teach people how to use cmd and I think it still serves a useful 
purpose.  So, unless it is considered broken, I don't think it should be 
deprecated.


Raymond




___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Soliciting comments on the future of the cmdmodule (bpo-33233)

[Steve Dower]

Better to deprecate it before it becomes broken, in my opinion.

Having someone willing and able to review and merge changes is the best 
criteria for whether a module is still supported or not.

Top-posted from my Windows phone

From: Raymond Hettinger
Sent: Friday, April 6, 2018 18:55
To: Ned Deily
Cc: Python-Dev@Python. Org
Subject: Re: [Python-Dev] Soliciting comments on the future of the cmdmodule 
(bpo-33233)



> On Apr 6, 2018, at 3:02 PM, Ned Deily  wrote:
> 
> We could be even bolder and officially deprecate "cmd" and consider closing 
> open enhancement issues for it on b.p.o."

FWIW, the pdb module depends on the cmd module.

Also, I still teach people how to use cmd and I think it still serves a useful 
purpose.  So, unless it is considered broken, I don't think it should be 
deprecated.


Raymond




___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/steve.dower%40python.org

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com