date:20190323



Raymond Hettinger  added the comment:

Thank you for the suggestion, but the point of having the input() is that the 
end user can select their own rename style with arbitrary text and either 
including or excluding possible data substitutions of their own choice.

The photo processing software I was using at the time I wrote the example works 
just like this.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36413] Brief Tour of the Standard Library — Part II example problem



Change by Raymond Hettinger :


--
assignee: docs@python -> rhettinger
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10716] Modernize pydoc to use better HTML and separate CSS



Karthikeyan Singaravelan  added the comment:

Thanks @aroberge for the patch and your efforts on improving it 
https://aroberge.blogspot.com/2015/01/scratching-itch-improving-pydoc.html

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10716] Modernize pydoc to use better HTML and separate CSS



Change by Karthikeyan Singaravelan :


Added file: https://bugs.python.org/file48231/Screen Shot 2019-03-24 at 
10.58.33 am.png

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10716] Modernize pydoc to use better HTML and separate CSS



Karthikeyan Singaravelan  added the comment:

I stumbled upon this issue because I think this is a potential improvement. One 
of the reasons I don't use it is due to the outdated UI but since it also 
generates HTML doc for installed packages in a virtual environment I find this 
to be a useful feature like rdoc (ruby), rustdoc (rust) and are actively 
maintained helping documentation of third party packages too for local 
reference.

I have less knowledge about CSS but I tried updating css_v3.diff with master 
and added boostrap.css from CDN to pydoc which adds spacing along with 
improving layout and font. Attached is a screenshot that is looks better with 
the CSS patch and bootstrap. Including bootstrap is not lightweight option in 
the Python distribution but can be seen as a proof of improvement.

--
keywords: +patch
nosy: +mdk
Added file: https://bugs.python.org/file48230/css_master.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8677] Modules needing PY_SSIZE_T_CLEAN

2019-03-23 Thread Serhiy Storchaka



Serhiy Storchaka  added the comment:

Thank you for doing this Inada-san!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36413] Brief Tour of the Standard Library — Part II example problem

2019-03-23 Thread YasirA


New submission from YasirA :

In the Template example, there's no placeholder to be substituted with date. I 
think it should be rewritten along the following lines:

>>> import time, os.path
>>> photofiles = ['img_1074.jpg', 'img_1076.jpg', 'img_1077.jpg']
>>> class BatchRename(Template):
... delimiter = '%'
>>> fmt = input('Enter rename style (%d-date %n-seqnum %f-format):  ')
Enter rename style (%d-date %n-seqnum %f-format):  Ashley_%d%n%f

>>> t = BatchRename(fmt)
>>> date = time.strftime('%d%b%y')
>>> for i, filename in enumerate(photofiles):
... base, ext = os.path.splitext(filename)
... newname = t.substitute(d=date+'_', n=i, f=ext)
... print('{0} --> {1}'.format(filename, newname))

img_1074.jpg --> Ashley_0.jpg
img_1076.jpg --> Ashley_1.jpg
img_1077.jpg --> Ashley_2.jpg

Yasir.

--
assignee: docs@python
components: Documentation
messages: 338714
nosy: YasirA, docs@python
priority: normal
severity: normal
status: open
title: Brief Tour of the Standard Library — Part II example problem
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36412] A possible crash in dictobject.c's new_dict()



Inada Naoki  added the comment:

Thank you, nice catch!
How did you find it?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36412] A possible crash in dictobject.c's new_dict()



Inada Naoki  added the comment:


New changeset 3d07c1ee1d2d475b74816117981d6ec752c26c23 by Inada Naoki (Zackery 
Spytz) in branch 'master':
bpo-36412: fix a possible crash in dictobject.c's new_dict() (GH-12519)
https://github.com/python/cpython/commit/3d07c1ee1d2d475b74816117981d6ec752c26c23


--
nosy: +inada.naoki

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36412] A possible crash in dictobject.c's new_dict()



Change by Inada Naoki :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36412] A possible crash in dictobject.c's new_dict()

2019-03-23 Thread Zackery Spytz



Change by Zackery Spytz :


--
keywords: +patch
pull_requests: +12470
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36412] A possible crash in dictobject.c's new_dict()

2019-03-23 Thread Zackery Spytz



New submission from Zackery Spytz :

PyDict_New() calls new_dict() with the "empty_values" array. If the 
PyObject_GC_New() call in new_dict() fails, new_dict() will call PyMem_FREE() 
on this array, causing a crash.

--
components: Interpreter Core
messages: 338711
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: A possible crash in dictobject.c's new_dict()
type: crash
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25614] Lib/code.py: InteractiveConsole.raw_input writes prompt to stdout



Cheryl Sabella  added the comment:

Since there was no additional information provided by the original poster, I'm 
going to close this.  Feel free to reopen if there is a use case.

--
nosy: +cheryl.sabella
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36411] Python 3 f.tell() gets out of sync with file pointer in binary append+read mode

2019-03-23 Thread PEW's Corner



New submission from PEW's Corner :

When a file is opened in binary append+read mode, i.e. open('file', 'a+b'), and 
a write (i.e. append) operation is performed while the file pointer is not at 
the end of the file (e.g. after a seek(0)), tell() will subsequently return the 
wrong value in Python 3 (but not in Python 2).

See this SO question:
https://stackoverflow.com/questions/51010322/python-3-tell-gets-out-of-sync-with-file-pointer-in-appendread-mode

--
components: IO
messages: 338709
nosy: pewscorner
priority: normal
severity: normal
status: open
title: Python 3 f.tell() gets out of sync with file pointer in binary 
append+read mode
type: behavior
versions: Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

2019-03-23 Thread Eryk Sun



Eryk Sun  added the comment:

Paul, I agree that joining Path(".") and Path("c:a") should yield Path("c:a"). 
However, I disagree that we should always be able to construct Path("a/b") from 
components Path("a") and Path("b"). It doesn't apply to Path("./c:a"). There's 
no way to split it up as the joining of two pathlib paths because there is no 
way to represent "c:a" by itself as anything other than a drive-relative path. 
The name "./c:a" has to be taken as a unit, which is fundamentally different 
from "c:a". pathlib agrees:

>>> p1 = Path('./c:a')
>>> p1
WindowsPath('c:a')
>>> [p1.drive, p1.root, p1.parts]
['', '', ('c:a',)]

>>> p2 = Path('.') / Path('c:a')
>>> p2
WindowsPath('c:a')
>>> [p2.drive, p2.root, p2.parts]
['c:', '', ('c:', 'a')]

Path('./c:a') is correctly parsed as a relative filename (no root and no 
drive). So, if it helps any, on the PR I wasn't requesting to change how it's 
parsed. The ambiguity is due to the way pathlib always collapses all "." 
components. I would like it to retain an initial "." component. That way the 
string representation will come out correctly as ".\\c:a" as opposed to the 
drive-relative path "c:a". 

Some Windows API and runtime library functions behave differently depending 
whether a relative path has a leading "." or ".." component. We're at a 
disadvantage if we throw this information away. For example, "./spam/eggs.ext" 
and "spam/eggs.ext" can yield different results when searching for the file via 
SearchPathW, CreateProcessW (if using lpCommandLine, not lpApplicationName), or 
LoadLibraryExW (data/image DLL loading, not normal module loading). 
"./spam/eggs.ext" will be resolved relative to the process working directory, 
but "spam/eggs.ext" will be tried against every directory in the default file, 
executable, or library search path, which may not even include the working 
directory. (The latter behavior is unique to Windows. POSIX never searches for 
a name with a slash in it.)

The CreateProcessW case is a generalization of the case that we're used to 
across various platforms, in which, for the sake of security, the "." entry is 
excluded from PATH. In this case, the only way to run an executable in the 
working directory is to reference it explicitly. For example (in Linux):

>>> p = Path('./test.sh')
>>> open(p, 'w').write('#!/bin/sh\necho spam\n')
20
>>> os.chmod(p, 0o700)
>>> subprocess.call(['./test.sh'])
spam
0
>>> try: subprocess.call([str(p)])
... except FileNotFoundError: print('eggs')
... 
eggs
>>> str(p)
'test.sh'

This would work if pathlib kept the initial "." component.

An example where we currently retain information that's not obviously needed is 
with ".." components. Even Path.absolute() retains ".." components. It's 
important in POSIX. For example, "spam/../eggs" shouldn't be reduced to "eggs" 
because "spam" might be a symlink. This doesn't generally matter in Windows, 
since it normalizes paths in user mode as strings before they're passed to the 
kernel, but we still don't throw the information away because it could be 
useful to code that implements POSIX-like behavior.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32823] Regression in test -j behavior and time in 3.7.0b1



Terry J. Reedy  added the comment:

Thanks for checking on this.  3.7.2 and 3.8.0a2 64 bit installed, as well as 
respository debug 32 bit 3.8.0a2+, are back to normal, with the quickest tests 
reporting within a few seconds.  I will assume fixed for Zach also, hence 
closing.

--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32823] Regression in test -j behavior and time in 3.7.0b1



Cheryl Sabella  added the comment:

Terry,

Do you still see this happening?  When I run the tests on Windows 10 with 12 
CPUs (using -j0), the tests run quickly with just the last one taking more time.

0:01:42 [418/420] test_socket passed (40 sec 239 ms) -- running: 
test_multiprocessing_spawn (58 sec 500 ms)
0:01:53 [419/420] test_venv passed (32 sec 267 ms) -- running: 
test_multiprocessing_spawn (1 min 9 sec)
running: test_multiprocessing_spawn (1 min 39 sec)
0:02:28 [420/420] test_multiprocessing_spawn passed (1 min 44 sec)

--
nosy: +cheryl.sabella

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36397] re.split() incorrectly splitting on zero-width pattern

2019-03-23 Thread Matthew Barnett



Matthew Barnett  added the comment:

The list alternates between substrings (s, between the splits) and captures (c):

['1', '1', '2', '2', '11']
 -s-  -c-  -s-  -c-  -s--

You can use slicing to extract the substrings:

>>> re.split(r'(?<=(\d))(?!\1)(?=\d)', '12111')[ : : 2]
['1', '2', '111']

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36397] re.split() incorrectly splitting on zero-width pattern

2019-03-23 Thread Elias Tarhini



Elias Tarhini  added the comment:

Thank you. Was too zeroed-in on the idea that it was from the zero-width 
pattern, and I forgot to consider the group. Looks like `re.sub(pattern, 
'some-delim', s).split('some-delim')` is a way to do this if it's not possible 
to use a non-capturing group

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10716] Modernize pydoc to use better HTML and separate CSS

2019-03-23 Thread Andre Roberge

Andre Roberge  added the comment:

On Sat, Mar 23, 2019 at 6:27 PM Raymond Hettinger 
wrote:

>
> Raymond Hettinger  added the comment:
>
> I've found the HTML to be useful (-w mode, not running a server) for
> generating quick documentation (much lighter weight commitment than using
> sphinx).  I show this in my intro classes and the engineers are usually
> impressed with it.
>
> This is really easy and requires neither configuration files or reST
> markup:
>
> $ python -m pydoc -w statistics
> wrote statistics.html
>
> So, my vote it to keep it.
>
> I would still like modern HTML 5 with CSS however.
>

I submitted code to do this in January 2015 on the bug tracker but, except
for some interest by a single person, my submission was essentially
ignored.  I do not claim it is perfect, but I thought it was a significant
improvement as it did use HTML 5 with CSS.

André Roberge

>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36405] Use dict unpacking in idlelib



Terry J. Reedy  added the comment:

Also, __builtins__ is only a module, with a __dict__, in __main__.

--
stage: patch review -> commit review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36405] Use dict unpacking in idlelib



Change by Terry J. Reedy :


--
pull_requests: +12469
stage: commit review -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36407] xml.dom.minidom wrong indentation writing for CDATA section

2019-03-23 Thread Stefan Behnel



Stefan Behnel  added the comment:

Yes, this case is incorrect. Pretty printing should not change character 
content inside of a simple tag.

The PR looks good to me.

--
versions: +Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10716] Modernize pydoc to use better HTML and separate CSS



Raymond Hettinger  added the comment:

I've found the HTML to be useful (-w mode, not running a server) for generating 
quick documentation (much lighter weight commitment than using sphinx).  I show 
this in my intro classes and the engineers are usually impressed with it.

This is really easy and requires neither configuration files or reST markup:

$ python -m pydoc -w statistics
wrote statistics.html

So, my vote it to keep it.

I would still like modern HTML 5 with CSS however.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36410] Proposal to make strip/lstrip/rstrip more explicit



Raymond Hettinger  added the comment:

Generally, we don't make changes that would break existing code relying on the 
documented and tested behavior.

If you would like to propose a new method, the python-ideas mailing list would 
be a good place to start.

>>> s[len('mailto:'):] if s.startswith('mailto:') else s
'ma...@gmail.com'

--
nosy: +rhettinger
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: behavior -> enhancement
versions:  -Python 2.7, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36410] Proposal to make strip/lstrip/rstrip more explicit

2019-03-23 Thread Alex Grigoryev


Alex Grigoryev  added the comment:

https://docs.python.org/2/library/string.html#string.lstrip 
(https://link.getmailspring.com/link/4c83e422-2f29-440a-8ce3-0ae8b13f5...@getmailspring.com/0?redirect=https%3A%2F%2Fdocs.python.org%2F2%2Flibrary%2Fstring.html%23string.lstrip=cmVwb3J0QGJ1Z3MucHl0aG9uLm9yZw%3D%3D)
Here should be clarified better. Yes I think API for explicit behavior should 
be discussed, because the other way is this
In [1]: "ma...@gmail.com".split("mailto:;)[-1]
Out[1]: 'ma...@gmail.com'
In [2]: "maria@gmail.commailto:".split("mailto:;)[-1]
Out[2]: ''
On март 23 2019, at 10:39 вечера, Karthikeyan Singaravelan 
 wrote:
>
> Karthikeyan Singaravelan  added the comment:
> https://docs.python.org/3.8/library/stdtypes.html?highlight=lstrip#str.lstrip
> > Return a copy of the string with leading characters removed. The chars 
> > argument is a string specifying the set of characters to be removed. If 
> > omitted or None, the chars argument defaults to removing whitespace. The 
> > chars argument is not a prefix; rather, all combinations of its values are 
> > stripped:
> The last sentence talks about the report. In the given examples it strips all 
> the given characters in chars from left until it finds a character that is 
> not found as part of the given chars argument.
> In [2]: 'mailto:ma...@gmail.com'.lstrip('mailto:') # Stops at 'r' that 
> doesn't need to be stripped
> Out[2]: 'r...@gmail.com'
>
> In [3]: 'mailto:ma...@gmail.com'.lstrip('ailto:') # 'm' is the first 
> character and is not found in chars 'ailto:'
> Out[3]: 'mailto:ma...@gmail.com'
>
> Changing this would break a lot of old code and adding an API for two 
> different behaviors would require a larger discussion. Perhaps did you find 
> any part of docs that you would like to improve to clarify this better?
> --
> nosy: +xtreak
> versions: -Python 3.5, Python 3.6, Python 3.9
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36410] Proposal to make strip/lstrip/rstrip more explicit



Karthikeyan Singaravelan  added the comment:

https://docs.python.org/3.8/library/stdtypes.html?highlight=lstrip#str.lstrip

> Return a copy of the string with leading characters removed. The chars 
> argument is a string specifying the set of characters to be removed. If 
> omitted or None, the chars argument defaults to removing whitespace. The 
> chars argument is not a prefix; rather, all combinations of its values are 
> stripped:

The last sentence talks about the report. In the given examples it strips all 
the given characters in chars from left until it finds a character that is not 
found as part of the given chars argument.

In [2]: 'mailto:ma...@gmail.com'.lstrip('mailto:') # Stops at 'r' that doesn't 
need to be stripped
Out[2]: 'r...@gmail.com'

In [3]: 'mailto:ma...@gmail.com'.lstrip('ailto:') # 'm' is the first character 
and is not found in chars 'ailto:'
Out[3]: 'mailto:ma...@gmail.com'

Changing this would break a lot of old code and adding an API for two different 
behaviors would require a larger discussion. Perhaps did you find any part of 
docs that you would like to improve to clarify this better?

--
nosy: +xtreak
versions:  -Python 3.5, Python 3.6, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11644] Cross-link 2to3 documentation, what’s new and pyporting howto



Cheryl Sabella  added the comment:

Thanks, Eric!

--
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21450] [Issue 13630] IDLE: Find(ed) text is not highlighted while dialog box is open



Change by Terry J. Reedy :


--
assignee:  -> terry.reedy
components: +IDLE
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21477] Idle: improve idle_test.htest



Change by Terry J. Reedy :


--
components: +IDLE

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21695] Idle 3.4.1-: closing Find in Files while in progress closes Idle



Change by Terry J. Reedy :


--
components: +IDLE

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36410] Proposal to make strip/lstrip/rstrip more explicit

2019-03-23 Thread Alex Grigoryev



New submission from Alex Grigoryev :

These methods have confusing implicit behavior. I propose to make it explicit, 
either strip the exact sequence or chars or leave the string as is.

In [1]: 'mailto:ma...@gmail.com'.lstrip('mailto')
Out[1]: ':ma...@gmail.com'

In [2]: 'mailto:ma...@gmail.com'.lstrip('mailto:')
Out[2]: 'r...@gmail.com'

In [3]: 'mailto:ma...@gmail.com'.lstrip('ailto:')
Out[3]: 'mailto:ma...@gmail.com'

--
messages: 338695
nosy: Alex Grigoryev
priority: normal
severity: normal
status: open
title: Proposal to make strip/lstrip/rstrip more explicit
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16177] Typing left parenthesis in IDLE causes intermittent Cocoa Tk crash on OS X



Change by Terry J. Reedy :


--
assignee:  -> terry.reedy
components: +IDLE, macOS
nosy: +ronaldoussoren, terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21982] Idle configDialog: fix regression and add minimal unittest



Change by Terry J. Reedy :


--
assignee:  -> terry.reedy
components: +IDLE

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27262] IDLE: move Aqua context menu code to maxosx



Change by Terry J. Reedy :


--
components: +IDLE

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24951] Idle test_configdialog fails on Fedora 23, 3.6



Change by Terry J. Reedy :


--
assignee:  -> terry.reedy
components: +IDLE

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

2019-03-23 Thread Eric V. Smith



Eric V. Smith  added the comment:

I agree that this is not a useful check.

--
nosy: +eric.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11644] Cross-link 2to3 documentation, what’s new and pyporting howto

2019-03-23 Thread Eric V. Smith



Eric V. Smith  added the comment:

I agree we should close this.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11644] Cross-link 2to3 documentation, what’s new and pyporting howto



Cheryl Sabella  added the comment:

Since the HOWTO for Porting from 2 to 3 was created in February 2011, there 
have been many updates over time to improve that document.  It seems to me that 
it is thorough in its explanation, including the suggestion of upgrading to 2.7 
before converting to Python 3.  As such, I believe this issue can be closed, 
but wanted to make sure others agreed before I changed the status.  Thanks!

https://docs.python.org/3.7/howto/pyporting.html

--
nosy: +cheryl.sabella

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35449] documenting objects



Change by Karthikeyan Singaravelan :


--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10716] Modernize pydoc to use better HTML and separate CSS



Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23205] Unit test needed for IDLE's GrepDialog.py's findfiles()



Cheryl Sabella  added the comment:

On linux, grep does depth first, so searching for 'idle' from Lib.idlelib 
returns:

--- cut ---
help.py
history.py
idle.py
all of idle_test/
__init__.py
iomenu.py
--- cut ---

Although, within idle_test, the files aren't in alphabetical order.  Also, as 
you can see __init__ is before iomenu, so underscores seem to be ignored.  On 
SO, it looks like they suggest piping it to sort if one wants a given ordering.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36401] Readonly properties should be marked as such in help()



Change by Raymond Hettinger :


--
keywords: +patch
pull_requests: +12468
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36129] io documentation unclear about flush() and close() semantics for wrapped streams

2019-03-23 Thread Gregory Szorc



Gregory Szorc  added the comment:

It's also worth noting that if the wrapped stream close() cascading behavior 
should be configurable, then many additional types in the standard library need 
a constructor argument to control this behavior. e.g. io.TextIOWrapper, 
io.BufferedReader, io.BufferedWriter, codecs.StreamReader, codecs.StreamWriter, 
etc.

In my influenced-by-Rust mind, the problem is similar to "ownership." The 
question we seem to be dancing around is whether the stream wrapper "owns" the 
inner stream or just "borrows" it. If it "owns," then close() cascading 
absolutely makes sense. But if it just "borrows" the inner stream, then close() 
cascading should not occur. There are viable use cases for both scenarios on 
pretty much any stream wrapper. Since existing stream wrappers automatically 
perform close() cascading and __del__ will call close(), I'd be a bit surprised 
if others weren't complaining about the inability to disable close() cascade on 
stream wrappers! e.g. it is perfectly viable to want to temporarily wrap a 
binary stream with an io.TextIOWrapper but the forced close() cascading makes 
this difficult to do since destruction of the outer stream will close() the 
inner stream. So you end up needing to keep references to outer streams alive 
to prevent this. Eww.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13828] Further improve casefold documentation



Cheryl Sabella  added the comment:

Assigning to @Mariatta for the sprints.

--
assignee: docs@python -> Mariatta
nosy: +Mariatta, cheryl.sabella
stage:  -> needs patch
versions: +Python 3.7, Python 3.8 -Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32217] freeze.py fails to work.



Cheryl Sabella  added the comment:

Thank you @Decorater for the report and PR.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32217] freeze.py fails to work.



Change by Cheryl Sabella :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32217] freeze.py fails to work.



miss-islington  added the comment:


New changeset d93de028e84c762d7e30b0b93d149b66c85d421f by Miss Islington (bot) 
in branch '3.7':
bpo-32217: Correct usage of ABI tags in freeze. (GH-4719)
https://github.com/python/cpython/commit/d93de028e84c762d7e30b0b93d149b66c85d421f


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36129] io documentation unclear about flush() and close() semantics for wrapped streams

2019-03-23 Thread Gregory Szorc

Gregory Szorc added the comment:

Thank you for the detailed reply, Josh.

I generally agree with what you are saying. However, I have some follow-ups.

In your answer to #2, you seem to distinguish between an "fd" (implying POSIX
file descriptor) and "Python layers" (implying a file object). Is this correct?
Should a "closefd" argument only apply when receiving an integer file
descriptor? Or should a "closefd" argument also apply when receiving any
io.RawIOBase object? If it doesn't apply for any generic file object, is there
any recommended way to control whether close() cascades? (My opinion is that
"closefd" should apply to any object with a close(), not just integer file
descriptors.)

lzma.LZMAFile and gzip.GZIPFile do *not* cascade close() when a file object (as
opposed to a named file) is passed into the constructor. (Presumably
bz2.BZ2File behaves the same way but the documentation doesn't state this.)
This is inconsistent with your answer that close() should always cascade. It's
worth noting that the docs for GZIPFile explicitly call out reasons why close()
does not cascade.

None of these compression *File constructors accept a "closefd" argument to
control the behavior. If the goal is for close() to cascade by default, then it
seems useful for these *File types to support automatic close() cascade.
Although changing the default would be a backwards compatibility break and I'm
not sure that's feasible. But at least you'd have the ability to opt in to the
behavior.

It's also worth calling out the behavior of io.BytesIO and io.StringIO. When
you close() these streams, you cannot call .getvalue() to get the buffer
content. This is consistent with the io.RawIOBase behavior of not allowing I/O
after a close(). However, the implication is that if you wrap a
BytesIO/StringIO and then a close() on the outer stream cascades into the
BytesIO/StringIO, you won't be able to access the written data! In fact, I
encountered this problem when writing python-zstandard's unit tests! I had to
implement a custom type that allowed access to getvalue() post close()
(https://github.com/indygreg/python-zstandard/blob/735771961bc04f8f7de9372297921826a814fd12/tests/common.py#L82)
to work around it.

Assuming a "closefd" argument applies to all file objects (not just file
descriptors) and that all stream wrappers should accept a "closefd" argument to
control close() cascade, I think I have a path forward for python-zstandard: I
simply add a "closefd" argument to the stream wrapper constructors. But if
"closefd" doesn't apply to generic file objects, then I'm still not sure how to
proceed, as I don't want to implement behavior that conflicts with the standard
library's.

___
Python tracker

___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths



Maor Kleinberger  added the comment:

Alright, documentation is always good :)
I'll be glad to add some, but could you please point me to the place in the 
code where you think it should go? (or just comment on the PR)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32217] freeze.py fails to work.



Change by miss-islington :


--
pull_requests: +12467

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32217] freeze.py fails to work.



Cheryl Sabella  added the comment:


New changeset a7987e71939fa631296f83861fb376361ddd59ee by Cheryl Sabella 
(AraHaan) in branch 'master':
bpo-32217: Correct usage of ABI tags in freeze. (GH-4719)
https://github.com/python/cpython/commit/a7987e71939fa631296f83861fb376361ddd59ee


--
nosy: +cheryl.sabella

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36409] plistlib old API should be removed



Change by Karthikeyan Singaravelan :


--
components: +macOS
nosy: +ned.deily, ronaldoussoren, serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36409] plistlib old API should be removed

2019-03-23 Thread Jon Janzen



Change by Jon Janzen :


--
keywords: +patch
pull_requests: +12466
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36409] plistlib old API should be removed

2019-03-23 Thread Jon Janzen



New submission from Jon Janzen :

Per the documentation and in-line code warnings, the old API for plistlib was 
deprecated in version 3.4. My understanding is that deprecated functionality is 
to be removed in the next major version, so this code is long overdue for 
removal.

--
components: Library (Lib)
messages: 338683
nosy: bigfootjon
priority: normal
severity: normal
status: open
title: plistlib old API should be removed
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36407] xml.dom.minidom wrong indentation writing for CDATA section

2019-03-23 Thread Vladimir Surjaninov



Change by Vladimir Surjaninov :


--
keywords: +patch
pull_requests: +12465
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36408] Tkinter multi-processing performance, Linux 10-25 times faster than Windows 10

2019-03-23 Thread J.E.McCormack



New submission from J.E.McCormack :

I am measuring multi-process GUI performance (Tkinter 8.6, Python 3.7) for 
drawing lines, circles, text boxes, etc. In a fairly typical experiment on a 
i7-6700HQ, 4-core (8 thread), on Windows 10 I measure 25.5k objects/sec for one 
process running alone, and 19.9k objects/sec total for eight processes. For 
Linux Kubuntu KDE desktop the figures are 61k objects/sec and 230k objects/sec 
(a multi-core boost of times 3.8). For running eight processes, the performance 
difference, KDE vs Win10, is therefore times 11.6. The difference over a range 
of tests is 10-25 times.

Clearly Win10 is not doing multi-core. Perhaps Tkinter is calling a Windows SDK 
function which is not thread-safe within the Windows GDI, imposing a 
single-thread barrier system-wide?

I am just wondering, firstly, if I have simply missed mention of this 
limitation anywhere. I can supply more info if needed.

--
components: Tkinter
messages: 338682
nosy: james.mccormack
priority: normal
severity: normal
status: open
title: Tkinter multi-processing performance, Linux 10-25 times faster than 
Windows 10
type: performance
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36407] xml.dom.minidom wrong indentation writing for CDATA section



Change by Karthikeyan Singaravelan :


--
nosy: +eli.bendersky, scoder, serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36407] xml.dom.minidom wrong indentation writing for CDATA section

2019-03-23 Thread Vladimir Surjaninov


New submission from Vladimir Surjaninov :

If we are writing xml with CDATA section and leaving non-empty indentation and 
new-line parameters, a parent node of the section will contain useless 
indentation, that will be parsed as a text.

Example:
>>>doc = minidom.Document()
>>>root = doc.createElement('root')
>>>doc.appendChild(root)
>>>node = doc.createElement('node')
>>>root.appendChild(node)
>>>data = doc.createCDATASection('')
>>>node.appendChild(data)
>>>print(doc.toprettyxml(indent=‘  ‘ * 4)






If we try to parse this output doc, we won’t get CDATA value correctly.

Following code returns a string that contains only indentation characters:
>>>doc = minidom.parseString(xml_text)
>>>doc.getElementsByTagName('node')[0].firstChild.nodeValue

Returns a string with CDATA value and indentation characters:
>>>doc.getElementsByTagName('node')[0].firstChild.wholeText


But we have a workaround:
>>>data.nodeType = data.TEXT_NODE
…
>>>print(doc.toprettyxml(indent=‘  ‘ * 4)





It will be parsed correctly:
>>>doc.getElementsByTagName('node')[0].firstChild.nodeValue


But I think it will be better if we fix the writing function, which would set 
this as default behavior.

--
components: XML
messages: 338681
nosy: vsurjaninov
priority: normal
severity: normal
status: open
title: xml.dom.minidom wrong indentation writing for CDATA section
type: enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

2019-03-23 Thread Paul Moore



Paul Moore  added the comment:

> does that require me to make any changes in order to make progress with my PR?

I'm not going to block this PR. I'd prefer it if we at least
documented the agreed behaviour, so that in future people don't come
along and say the new behaviour is wrong, but again I'm not going to
insist. I doubt I'll ever hit this edge case myself (either in code of
my own, or when working with others) so my only real interest is in
flagging up the concern. I'd like to hear what Eryk has to say on the
matter, though.

Ultimately the only person whose views matter are yours (as the person
writing the code) whoever commits the change.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36406] doctest.testmod(empty_package) raises TypeError in 3.7 (and no errors in 3.6)



Karthikeyan Singaravelan  added the comment:

So this was backported to 3.6 too with but caused similar issues reported in 
issue32872 to be reverted back.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12790] doctest.testmod does not run tests in functools.partial functions



Karthikeyan Singaravelan  added the comment:

functools.partial returns a partial object and detecting partials is not 
handled inside the finder when given a module. Perhaps partials could be 
handled as a special case to detect tests in them?

diff --git a/Lib/doctest.py b/Lib/doctest.py
index 79d91a040c..aeff913c9a 100644
--- a/Lib/doctest.py
+++ b/Lib/doctest.py
@@ -95,6 +95,7 @@ __all__ = [
 import __future__
 import difflib
 import inspect
+import functools
 import linecache
 import os
 import pdb
@@ -962,6 +963,8 @@ class DocTestFinder:
 return module.__name__ == object.__module__
 elif isinstance(object, property):
 return True # [XX] no way not be sure.
+elif isinstance(object, functools.partial):
+return True
 else:
 raise ValueError("object must be a class or function")
 
@@ -989,7 +992,8 @@ class DocTestFinder:
 valname = '%s.%s' % (name, valname)
 # Recurse to functions & classes.
 if ((inspect.isroutine(inspect.unwrap(val))
- or inspect.isclass(val)) and
+ or inspect.isclass(val)
+ or isinstance(val, functools.partial)) and
 self._from_module(module, val)):
 self._find(tests, val, valname, module, source_lines,
globs, seen)

--
nosy: +xtreak
versions: +Python 3.8 -Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths



Maor Kleinberger  added the comment:

> OK, sure. My point is that "relative path to the current directory on
the drive with the specified letter" isn't a concept that matches how
"relative paths" are typically interpreted (most code interprets
"relative" as "relative to the CWD", and doesn't deal with the
possibility of per-drive CWDs).

In pathlib, each path object has a drive, a root and path parts. Seeing 
pathlib's logic and tests (many tests are specifically testing the behavior of 
drive-relative paths), I think pathlib completely supports drive relative 
paths, with the exception of a few small bugs.


> > > I'm comfortable with WindowsPath("./b:a") returning WindowsPath("b:a")
> > I disagree with that as well. "./b:a" is explicitly a path relative to the 
> > CWD (to a file named b:a). On the other hand, "b:a" should be (an is, in 
> > most windows programs) interpreted as a drive relative path.
> Windows is inconsistent here - it can *also* be interpreted as a path
to a stream within a file. But it (virtually) never is.

I think that when parsing windows paths, pathlib should behave exactly like the 
windows API does. This is crucial for interaction with the windows API itself 
or with other applications that might use it. I don't see any other way to 
parse windows paths other than according to the normal windows behavior.
Having said that, pathlib does a pretty good keeping the compatibility with the 
windows API, except for the small cases I found and brought forward in this 
issue report. From the information I gathered, when a path starts with one 
letter followed by a colon, windows treats it as a drive and continues parsing 
the rest of the path separately. That means that if you want to specify a path 
to a file in the CWD, with a single-character name and a file stream, you must 
precede the path with a "./" (See eryksun's comment on my PR before I fixed it 
https://github.com/python/cpython/pull/12361#discussion_r266193727).
Here is an example for the behavior of the windows API in this case:
win32api.GetFullPathName('b:a') -> 'B:\\a'
win32api.GetFullPathName('./b:a') -> 'C:\\Users\\maor\\b:a'


> Also, in effect it means that Path(".") / some_path can return a
completely different location than some_path.

This behavior is completely normal. Should WindowsPath('C:\\f') / 
WindowsPath('D:\\f2') return anything other than WindowsPath('D:/f2')?


> And I think the problem is that "drive-relative paths" are somewhat odd 
> things that don't fit well in the POSIX-derived model that Python's path APIs 
> follow.

As I wrote earlier, I think this is incorrect as the pathlib.Path class holds 
the attributes _drv, _root and _parts, which allows it to fully support 
drive-relative paths, by having a _drv and not having a _root.


> I'm happy to agree to differ on this point, though. If the new
behaviour is just a side-effect of fixing absolute() to match the
cases Eryk commented on, then that's fine - I just wouldn't describe
the particular ./b:c cases as "bug fixes", rather as "changes in the
behaviour of cases no-one should actually care about" :-)

I'm still that my case is convincing enough, but if not - does that require me 
to make any changes in order to make progress with my PR?


> BTW, was there an actual use case for this issue, or was it simply a
theoretical concern?

I've had an annoying bug using pathlib, traced it to the first bug I've 
presented in this issue, and discovered a few similar unhandled edge cases. 
Again, the "bugginess" I set upon to fix (call it a bug or  an undefined 
behavior) is an incompatibility issue with the way paths are normally treated 
in windows.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36342] test_venv failure when executed by test_multiprocessing and the platform lacks a functional sem_open()

2019-03-23 Thread Xavier de Gaye



Change by Xavier de Gaye :


--
keywords: +patch
pull_requests: +12464
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36406] doctest.testmod(empty_package) raises TypeError in 3.7 (and no errors in 3.6)


Karthikeyan Singaravelan  added the comment:

This might be due to changes introduced in 
a23d30f64bd9c5655cfae7f359d4279c47f6cab3 where __file__ is set to None. Hence 
the below returns None but before the commit this used to return an 
AttributeError and print "missing" . This was not handled in doctest causing 
error. Adding Barry for confirmation.

# foo.py

import empty_package
print(getattr(empty_package, '__file__', 'missing'))

➜  cpython git:(2b5937ec0a) ✗ git checkout 
a23d30f64bd9c5655cfae7f359d4279c47f6cab3 && make -s -j4 > /dev/null
Previous HEAD position was 2b5937ec0a bpo-32734: Fix asyncio.Lock multiple 
acquire safety issue (GH-5466) (#5501)
HEAD is now at a23d30f64b bpo-32303 - Consistency fixes for namespace loaders 
(GH-5481) (#5503)
➜  cpython git:(a23d30f64b) ✗ ./python.exe foo.py
None
➜  cpython git:(a23d30f64b) ✗ git checkout 
a23d30f64bd9c5655cfae7f359d4279c47f6cab3~1 && make -s -j4 > /dev/null
Previous HEAD position was a23d30f64b bpo-32303 - Consistency fixes for 
namespace loaders (GH-5481) (#5503)
HEAD is now at 2b5937ec0a bpo-32734: Fix asyncio.Lock multiple acquire safety 
issue (GH-5466) (#5501)
➜  cpython git:(2b5937ec0a) ✗ ./python.exe foo.py
missing

There is a unittest with empty package and it's just that doctest.testmod(mod) 
was not called on the empty package causing this not to be found. A simple 
patch would be to check for None where None is a valid value for DocTest. 
Another possible fix would be to have module.__name__ for None but since this 
is for empty packages I assume there won't be any doctest to parse in DocTest 
constructor.

diff --git a/Lib/doctest.py b/Lib/doctest.py
index 79d91a040c..e97555ed2f 100644
--- a/Lib/doctest.py
+++ b/Lib/doctest.py
@@ -1060,7 +1060,7 @@ class DocTestFinder:
 filename = None
 else:
 filename = getattr(module, '__file__', module.__name__)
-if filename[-4:] == ".pyc":
+if filename and filename[-4:] == ".pyc":
 filename = filename[:-1]
 return self._parser.get_doctest(docstring, globs, name,
 filename, lineno)
diff --git a/Lib/test/test_doctest.py b/Lib/test/test_doctest.py
index f1013f2572..b99f2aea2f 100644
--- a/Lib/test/test_doctest.py
+++ b/Lib/test/test_doctest.py
@@ -699,6 +699,7 @@ class TestDocTestFinder(unittest.TestCase):
 support.forget(pkg_name)
 sys.path.pop()
 assert doctest.DocTestFinder().find(mod) == []
+doctest.testmod(mod)


 def test_DocTestParser(): r"""

Without patch the line doctest.testmod(mod) in unittest fails as below with 
TypeError and with patch the tests pass

$ ./python.exe Lib/test/test_doctest.py
doctest (doctest) ... 66 tests with zero failures
doctest (test.test_doctest) ... 516 tests with zero failures
test_empty_namespace_package (__main__.TestDocTestFinder) ... ERROR

==
ERROR: test_empty_namespace_package (__main__.TestDocTestFinder)
--
Traceback (most recent call last):
  File "Lib/test/test_doctest.py", line 702, in test_empty_namespace_package
doctest.testmod(mod)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/doctest.py", 
line 1947, in testmod
for test in finder.find(m, name, globs=globs, extraglobs=extraglobs):
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/doctest.py", 
line 932, in find
self._find(tests, obj, name, module, source_lines, globs, {})
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/doctest.py", 
line 982, in _find
test = self._get_test(obj, name, module, globs, source_lines)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/doctest.py", 
line 1063, in _get_test
if filename[-4:] == ".pyc":
TypeError: 'NoneType' object is not subscriptable

--

Ran 1 test in 0.027s

FAILED (errors=1)
Traceback (most recent call last):
  File "Lib/test/test_doctest.py", line 3032, in 
test_main()
  File "Lib/test/test_doctest.py", line 3015, in test_main
support.run_unittest(__name__)
  File 
"/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/test/support/__init__.py",
 line 2064, in run_unittest
_run_suite(suite)
  File 
"/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/test/support/__init__.py",
 line 1983, in _run_suite
raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_doctest.py", line 702, in test_empty_namespace_package
doctest.testmod(mod)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/doctest.py", 
line 1947, in testmod
for test in finder.find(m, name, globs=globs, extraglobs=extraglobs):
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/doctest.py", 
line 932, in find
self._find(tests, obj,

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

2019-03-23 Thread Paul Moore



Paul Moore  added the comment:

> > [Note there is no absolute() method - I assume you mean resolve()]
> Of course there is an absolute() method, I'm not sure what you are saying...

Huh, weird. It's not in
https://docs.python.org/3.7/library/pathlib.html But you're right, it
does exist...

> > it seems to me that 'b:a' is "absolute-ish" (drive-relative)
> I think that is incorrect. As written here: 
> https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file#fully-qualified-vs-relative-paths,
>  "If a file name begins with only a disk designator but not the backslash 
> after the colon, it is interpreted as a relative path to the current 
> directory on the drive with the specified letter."
> In that case, WindowsPath('C:a').is_absolute() should return False, (as it 
> does today) and WindowsPath('C:a').absolute() should return a path on drive 
> C:, with 'a' joined with the working directory in drive C:.

OK, sure. My point is that "relative path to the current directory on
the drive with the specified letter" isn't a concept that matches how
"relative paths" are typically interpreted (most code interprets
"relative" as "relative to the CWD", and doesn't deal with the
possibility of per-drive CWDs).

> > I'm comfortable with WindowsPath("./b:a") returning WindowsPath("b:a")
> I disagree with that as well. "./b:a" is explicitly a path relative to the 
> CWD (to a file named b:a). On the other hand, "b:a" should be (an is, in most 
> windows programs) interpreted as a drive relative path.

Windows is inconsistent here - it can *also* be interpreted as a path
to a stream within a file. But it (virtually) never is.

> For example, the ntpath module handles these cases correctly. When located in 
> the directory C:\\d, this is the ntpath behavior:
> ntpath.abspath('b:a') -> 'B:\\a'
> ntpath.abspath('.\\b:a') -> 'C:\\d\\b:a'

That second case only results in a valid filename if b:a is viewed as
a file-with-stream, but the first only makes sense if b:a is viewed as
a directory-relative file.

Also, in effect it means that Path(".") / some_path can return a
completely different location than some_path. Following documented
behaviour or not, that violates a pretty fundamental assumption that
users would expect to hold. And I think the problem is that
"drive-relative paths" are somewhat odd things that don't fit well in
the POSIX-derived model that Python's path APIs follow.

> In conclusion, I stand by my original fix offers. They are correct according 
> to windows' documentation and behavior.

I remain of the view that the Windows documentation introduces a
concept ("relative path to the current directory on a specific drive")
that isn't well modelled by the current APIs, and the only "proper"
solution is to extend the API (like with the ideas of "drive" and
"reserved filenames", which are Windows-specific, but supported
everywhere). In the absence of that, I believe that any "fix" within
the existing model will have odd edge cases, and I don't think these
ones (specifically the "./b:a" cases) have *any* "obvious" answer.

I'm happy to agree to differ on this point, though. If the new
behaviour is just a side-effect of fixing absolute() to match the
cases Eryk commented on, then that's fine - I just wouldn't describe
the particular ./b:c cases as "bug fixes", rather as "changes in the
behaviour of cases no-one should actually care about" :-)

BTW, was there an actual use case for this issue, or was it simply a
theoretical concern? I'm actually much happier considering these cases
as "undefined" in practice (and just "not mentioned" in the docs),
rather than trying to pin it down precisely. I don't know of a case
where it actually benefits us to document this level of arguable
behaviour.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23205] Unit test needed for IDLE's GrepDialog.py's findfiles()



Change by Cheryl Sabella :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23205] Unit test needed for IDLE's GrepDialog.py's findfiles()



miss-islington  added the comment:


New changeset 5ab665005b7f8a21c133208f140389e3bb1a3294 by Miss Islington (bot) 
in branch '3.7':
bpo-23205: IDLE: Add tests and refactor grep's findfiles (GH-12203)
https://github.com/python/cpython/commit/5ab665005b7f8a21c133208f140389e3bb1a3294


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36322] Argument typo in dbm.ndbm.open

2019-03-23 Thread Marco Rougeth


Marco Rougeth  added the comment:

Hi Terry, thanks for reviewing this and sorry for not being clear enough.

About dbm.gnu.open:

The docs indeed uses “flag”, in singular form, but it’s wrong because 1) the 
argument accepts, for some cases, 2 flags and, 2) the source code uses “flags” 
in plural form.

In [1]: import dbm.gnu
In [2]: help(dbm.gnu.open)  

Help on built-in function open in module _gdbm:

open(filename, flags='r', mode=438, /)
[...]

If you continue to read the docstring, there's an explanation about the cases 
where you can use two flags.

About dbm.ndbm.open:

For this one, the docs is also different from source code:

In [3]: import dbm.ndbm
In [4]: help(dbm.ndbm.open) 

Help on built-in function open in module _dbm:

open(filename, flags='r', mode=438, /)
[...]

The scope of the patch on Github ends here. It only makes the documentation 
consistent to the source code.

What I wanted to point out is that, in the case of ndbm.open, it accepts a 
flags option (in plural form) when it actually accepts only one. And since 
changing it would not make any difference from an user perspective, I believe 
we should go for it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36381] Deprecate "#" argument format without PY_SSIZE_T_CLEAN



Change by Inada Naoki :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23205] Unit test needed for IDLE's GrepDialog.py's findfiles()



Change by miss-islington :


--
pull_requests: +12463
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36381] Deprecate "#" argument format without PY_SSIZE_T_CLEAN



Inada Naoki  added the comment:


New changeset d3c72a223a5f771f964fc34557c55eb5bfa0f5a0 by Inada Naoki in branch 
'master':
bpo-36381: warn when no PY_SSIZE_T_CLEAN defined (GH-12473)
https://github.com/python/cpython/commit/d3c72a223a5f771f964fc34557c55eb5bfa0f5a0


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36342] test_venv failure when executed by test_multiprocessing and the platform lacks a functional sem_open()

2019-03-23 Thread Xavier de Gaye



Xavier de Gaye  added the comment:

Removing the bpo-35978 dependency as changeset 
8bba81fd55873148c65b7d0e6a6effbd63048c76 that fixes bpo-35978 only skips 
test_multiprocessing when test_venv is run from a venv.

--
dependencies:  -test_venv fails in Travis with GCC

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36406] doctest.testmod(empty_package) raises TypeError in 3.7 (and no errors in 3.6)

2019-03-23 Thread Dutcho



New submission from Dutcho :

In recent Python, a directory without __init__.py is also a package, and hence 
can be imported. When this directory/package is empty, and a doctest.testmod() 
is executed, the behaviour changed from 3.6 to 3.7, which I didn't find in the 
"what's new" documentation.

Minimal example:
>>> import doctest, os
>>> os.mkdir('empty_package')
>>> import empty_package
>>> doctest.testmod(empty_package)

Python 3.6.8 on Windows 7 prints
TestResults(failed=0, attempted=0)

Python 3.7.2 on Windows 7 raises below TypeError in doctest
Traceback (most recent call last):
  File "bug_empty_package.py", line 4, in 
print(doctest.testmod(empty_package))
  File "...\Python37\lib\doctest.py", line 1949, in testmod
for test in finder.find(m, name, globs=globs, extraglobs=extraglobs):
  File "...\Python37\lib\doctest.py", line 932, in find
self._find(tests, obj, name, module, source_lines, globs, {})
  File "...\Python37\lib\doctest.py", line 982, in _find
test = self._get_test(obj, name, module, globs, source_lines)
  File "...\Python37\lib\doctest.py", line 1063, in _get_test
if filename[-4:] == ".pyc":
TypeError: 'NoneType' object is not subscriptable

--
components: Library (Lib)
messages: 338670
nosy: Dutcho
priority: normal
severity: normal
status: open
title: doctest.testmod(empty_package) raises TypeError in 3.7 (and no errors in 
3.6)
type: behavior
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths



Maor Kleinberger  added the comment:

> (Note: I consider all of these to be *extremely* obscure corner cases)
One bug was enough for me :)

> [Note there is no absolute() method - I assume you mean resolve()]
Of course there is an absolute() method, I'm not sure what you are saying...

> it seems to me that 'b:a' is "absolute-ish" (drive-relative)
I think that is incorrect. As written here: 
https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file#fully-qualified-vs-relative-paths,
 "If a file name begins with only a disk designator but not the backslash after 
the colon, it is interpreted as a relative path to the current directory on the 
drive with the specified letter."
In that case, WindowsPath('C:a').is_absolute() should return False, (as it does 
today) and WindowsPath('C:a').absolute() should return a path on drive C:, with 
'a' joined with the working directory in drive C:.

> I'm comfortable with WindowsPath("./b:a") returning WindowsPath("b:a")
I disagree with that as well. "./b:a" is explicitly a path relative to the CWD 
(to a file named b:a). On the other hand, "b:a" should be (an is, in most 
windows programs) interpreted as a drive relative path.
For example, the ntpath module handles these cases correctly. When located in 
the directory C:\\d, this is the ntpath behavior:
ntpath.abspath('b:a') -> 'B:\\a'
ntpath.abspath('.\\b:a') -> 'C:\\d\\b:a'

In conclusion, I stand by my original fix offers. They are correct according to 
windows' documentation and behavior.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23205] Unit test needed for IDLE's GrepDialog.py's findfiles()



Cheryl Sabella  added the comment:


New changeset d60f658fc0278f3fcdadec8ddcab35b8ae03e1d1 by Cheryl Sabella in 
branch 'master':
bpo-23205: IDLE: Add tests and refactor grep's findfiles (GH-12203)
https://github.com/python/cpython/commit/d60f658fc0278f3fcdadec8ddcab35b8ae03e1d1


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

2019-03-23 Thread Paul Moore



Paul Moore  added the comment:

(Note: I consider all of these to be *extremely* obscure corner cases)

> 1. WindowsPath('C:a').absolute() should return WindowsPath('C:\\d\\a') but 
> returns WindowsPath('C:a').
> This is caused by flawed logic in the parse_parts method of the _Flavour 
> class.
>
> 2. WindowsPath('./b:a').absolute() should return WindowsPath('C:\\d\\b:a') 
> but returns WindowsPath('b:a').
> This is caused by the limited interface of parse_parts, and affects the 
> Path.absolute, Path.expanduser and Path.__rtruediv__ methods.

[Note there is no absolute() method - I assume you mean resolve()]

Why? If './b:a' resulted from joining '.' and 'b:a', then it seems to
me that 'b:a' is "absolute-ish" (drive-relative) and so any preceding
path should be ignored (just like joining '.' and '/a/b/c' on POSIX).
The problem here is more to do with the fact that the simple POSIX
"absolute or relative" dichotomy isn't complete for Windows -
drive-relative paths like C:foo have some of the characteristics of
absolute paths and some of the characteristics of relative paths.

To put it another way, I'm comfortable with WindowsPath("./b:a")
returning "WindowsPath("b:a"). Of course, that's because I read b:a as
a drive plus a filename. If you read it as a filename with a stream,
then your interpretation is correct. But unless you check for all of
the valid drives currently available, it's not possible to make that
choice - both interpretations are equally valid. In fact, if you have
a file "C", and add a stream "file1" to it, is "C:file1" a file on the
C drive, or a stream in the file C? The problem is genuinely ambiguous
in that case, and cannot be solved without making an arbitrary choice.
Worse, WindowsPath("w:fred").resolve(strict=False) technically can't
even take account of whether drive w exists or file w exists or has a
stream fred. In that case, the question is fundamentally unanswerable.

I'd be reluctant to "solve" this issue with a fix that doesn't address
that problem - it would simply be replacing one weird behaviour with
another in an obscure corner case. (It may be that the "fix" is simply
to document the choices that the code currently makes).

> 3. WindowsPath('./b:a').resolve() should return WindowsPath('C:\\d\\b:a') but 
> returns WindowsPath('b:a').
> This is caused by missing logic in the resolve method and in Path.__str__

Same as (2)

> It'd be great if someone could review the PR so we can make progress with 
> fixing the bugs.

I don't think we should worry about the PR until it's clearly
established what the correct resolution actually is (or even whether
we consider all of these cases as bugs).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36345] Deprecate Tools/scripts/serve.py in favour of python -m http.server -d

2019-03-23 Thread STINNER Victor



STINNER Victor  added the comment:

Maybe others prefer to do both changes at once. I don't know.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36345] Deprecate Tools/scripts/serve.py in favour of python -m http.server -d

2019-03-23 Thread STINNER Victor



STINNER Victor  added the comment:

I would remove to move the script into the doc in 1 PR and just modify
Makefile in the other one. So the Makefile can be updated first.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36301] Add _Py_PreInitialize() function

2019-03-23 Thread STINNER Victor



STINNER Victor  added the comment:


New changeset 6d5ee973f0600a3a9444f569dcf0dd346bfa2a11 by Victor Stinner in 
branch 'master':
bpo-36301: Add _PyRuntimeState.preconfig (GH-12506)
https://github.com/python/cpython/commit/6d5ee973f0600a3a9444f569dcf0dd346bfa2a11


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35528] [DOC] [LaTeX] Sphinx 2.0 uses GNU FreeFont as default for xelatex

2019-03-23 Thread Julien Palard



Change by Julien Palard :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths



Maor Kleinberger  added the comment:

Update after editing my PR - the bugs are:

1. WindowsPath('C:a').absolute() should return WindowsPath('C:\\d\\a') but 
returns WindowsPath('C:a').
This is caused by flawed logic in the parse_parts method of the _Flavour class.

2. WindowsPath('./b:a').absolute() should return WindowsPath('C:\\d\\b:a') but 
returns WindowsPath('b:a').
This is caused by the limited interface of parse_parts, and affects the 
Path.absolute, Path.expanduser and Path.__rtruediv__ methods.

3. WindowsPath('./b:a').resolve() should return WindowsPath('C:\\d\\b:a') but 
returns WindowsPath('b:a').
This is caused by missing logic in the resolve method and in Path.__str__

It'd be great if someone could review the PR so we can make progress with 
fixing the bugs.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36345] Deprecate Tools/scripts/serve.py in favour of python -m http.server -d

2019-03-23 Thread Stéphane Wirtel


Stéphane Wirtel  added the comment:

@vstinner

I propose two PRs.

The first one will remove the Tools/scripts/serve.py file and update the 
Makefile.

The second and independent PR just add a new example in the documentation of 
wsgiref, the example is based on Tools/scripts/serve.py

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36405] Use dict unpacking in idlelib



Terry J. Reedy  added the comment:

You mean that the patch will execute the code in imported module where the two 
are not even equal.  So I will revert the '__main__' changes.

I found two differences in completion behavior with the patch.  One is a 
failure that should work, another is a success that should fail.  I will try to 
turn at least one of them into a new test that fails before the reversion and 
passes after.

--
stage: patch review -> commit review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36345] Deprecate Tools/scripts/serve.py in favour of python -m http.server -d

2019-03-23 Thread Stéphane Wirtel


Change by Stéphane Wirtel :


--
pull_requests: +12462

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36318] Adding support for setting the "disabled" attribute of loggers from logging.config.dictConfig

2019-03-23 Thread Géry


Change by Géry :


--
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36318] Adding support for setting the "disabled" attribute of loggers from logging.config.dictConfig

2019-03-23 Thread Géry


Géry  added the comment:

> A bit late for that now

Okay, so disabled is a private attribute so it should never be used anyway. And 
as it not documented anywhere in the official Python documentation, I think the 
current situation is fine. Thank you for the explanation, I am closing this 
issue and the pull request.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36286] Random failure in test_idle

2019-03-23 Thread Serhiy Storchaka



Change by Serhiy Storchaka :


--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36405] Use dict unpacking in idlelib



miss-islington  added the comment:


New changeset 00986ec5530f004fca2c2675a822c73f06283bdf by Miss Islington (bot) 
in branch '3.7':
bpo-36405: Use dict unpacking in idlelib (GH-12507)
https://github.com/python/cpython/commit/00986ec5530f004fca2c2675a822c73f06283bdf


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36286] Random failure in test_idle



Terry J. Reedy  added the comment:

I found that clicking on the font sample was usually enough to cause a failure 
and restart.  Should we close this?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36405] Use dict unpacking in idlelib

2019-03-23 Thread Serhiy Storchaka



Serhiy Storchaka  added the comment:

It is true only in the main script or REPL. But you executed that code in 
imported modules.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36405] Use dict unpacking in idlelib



Terry J. Reedy  added the comment:

I hit merge before seeing your post here.  I based the globals change on

>>> import __main__
>>> __main__.__dict__ is globals()
True

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33319] `subprocess.run` documentation doesn't tell is using `stdout=PIPE` safe

2019-03-23 Thread Gregory P. Smith



Change by Gregory P. Smith :


--
nosy:  -miss-islington
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36405] Use dict unpacking in idlelib



Change by miss-islington :


--
pull_requests: +12461

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36405] Use dict unpacking in idlelib



Terry J. Reedy  added the comment:


New changeset 2b75155590eb42d25e474b776ee9fdcc4b3dc840 by Terry Jan Reedy in 
branch 'master':
bpo-36405: Use dict unpacking in idlelib (#12507)
https://github.com/python/cpython/commit/2b75155590eb42d25e474b776ee9fdcc4b3dc840


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33319] `subprocess.run` documentation doesn't tell is using `stdout=PIPE` safe



miss-islington  added the comment:


New changeset 9cdac5ced68f1d6ef5e1eee7552bb200b46adc23 by Miss Islington (bot) 
in branch '3.7':
bpo-33319: Clarify subprocess call docs. (GH-12508)
https://github.com/python/cpython/commit/9cdac5ced68f1d6ef5e1eee7552bb200b46adc23


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23205] Unit test needed for IDLE's GrepDialog.py's findfiles()



Terry J. Reedy  added the comment:

Commit as-is.  I will consider the Path.glob findfiles while working on #36323. 
 Like walk, it yields in breadth first order.  Unlike walk, it requires 
relative paths (which #37323 may need anyway) and needs code to deal with that.

I like the breadth first listing from glob.  Would it make any sense to give 
users a choice?  What does unix grep do?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33319] `subprocess.run` documentation doesn't tell is using `stdout=PIPE` safe