[issue35609] Improve of abc.py docstring

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Double spaces between sentences increase readability. This is not a bug.

Since abstractclassmethod and like are deprecated and should not be used in new 
code, I do not see a value of extending their docstrings. Too verbose 
docstrings make using the module help less convenient. I would rather remove 
existing examples from docstrings. The module documentation contains more 
modern examples.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue35611] open doesn't call IncrementalEncoder with final=True

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
assignee:  -> lemburg
nosy: +doerwalter, lemburg

___
Python tracker 

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

[issue28134] socket.socket(fileno=fd) does not work as documented

[Nathaniel Smith]

Nathaniel Smith  added the comment:

Am I right that this is considered fixed (or at least as fixed as it can be), 
and the issue should be closed?

Also, small note in case anyone stumbles across this in the future and is 
confused: Python does *not* handle this correctly on Windows. I suspect 
Christian was confused because there's an undocumented features on Windows 
where if you pass fileno=, then that 
correctly reinstantiates the socket object. But fileno= 
doesn't seem to do any special autodetection of type/family/proto.

--
nosy: +njs

___
Python tracker 

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

[issue34055] IDLE: erroneous 'smart' indents in shell

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I 'moved' pr-11307 to #35610 by changing the title.

--

___
Python tracker 

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

[issue35611] open doesn't call IncrementalEncoder with final=True

[David Haney]

New submission from David Haney :

The implementation of open relies on a codecs' IncrementalEncoder, however it 
never calls `encode` with final=True. This appears to violate the documentation 
for IncrementalEncoder.encode which states that the last call to encode _must_ 
set final=True.

The attached test case demonstrates this behavior. A codec "delayed" is 
implemented that holds the last encoded string until the next call to `encode`, 
at which point it returns the encoded string. When final=True, both the 
previous and current string are returned.

When `codecs.iterencode` is used to encode a sequence of strings, the encode 
function is called for each element in the sequence, with final=False. encode 
is then called a final time with an empty string and final=True.

When `open` is used to open a file stream for the encoding, each call to 
`write` calls `encode` with final=False, however it never calls `encode` with 
final=True, and it doesn't appear there's an API for forcing it to occur (for 
instance `flush` and `close` do not).

--
components: IO
files: test.py
messages: 332701
nosy: haney
priority: normal
severity: normal
status: open
title: open doesn't call IncrementalEncoder with final=True
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48022/test.py

___
Python tracker 

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

[issue34055] IDLE: erroneous 'smart' indents in shell

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Even before this fix, in 3.7.2, I no longer see the extra blank lines I 
reported in msg321135 either on Windows or macOS.  I did still see the 
persistent and expanding indents reported in the opening post.  I believe that 
this is what Raymond also referred to.  The one I could reproduce are now gone. 
 Hence, I close this.

Remaining newline and indent issues should be handled in other issues.

* I intend to review the initial PR for #32989 soon.  I don't know what its 
effect might be on the user-visible result.

* Too short indents for open fences needs a new issue.

* Blank line before SyntaxError: interactive python does this.

>>> d={a:'a}
  File "", line 1
d={a:'a}
   ^
SyntaxError: EOL while scanning string literal
>>>

The ^ line is nearly blank.  IDLE omits the line echo and ^ and adds a red 
highlight instead ... + an invisible indent on the next line (now too short). 
(It also color-codes the error message.)

>>> d={a:'a}<---red highlight to end of line...
   
SyntaxError: EOL while scanning string literal
>>>

Checking syntax first and skipping indent on error would give the following.  I 
don't know how easy this would be.

>>> d={a:'a}<---red highlight to end of line...
SyntaxError: EOL while scanning string literal
>>>

--
dependencies:  -IDLE: Fix pyparse.find_good_parse_start and its bad editor call
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

[issue35610] IDLE: replace use of EditorWindow.context_use_ps1

[Cheryl Sabella]

Change by Cheryl Sabella :


--
pull_requests: +10658

___
Python tracker 

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

[issue35610] IDLE: replace use of EditorWindow.context_use_ps1

[Cheryl Sabella]

Change by Cheryl Sabella :


--
keywords: +patch, patch
pull_requests: +10656, 10657

___
Python tracker 

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

[issue35610] IDLE: replace use of EditorWindow.context_use_ps1

[Cheryl Sabella]

Change by Cheryl Sabella :


--
keywords: +patch
pull_requests: +10656

___
Python tracker 

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

[issue35610] IDLE: replace use of EditorWindow.context_use_ps1

[Terry J. Reedy]

New submission from Terry J. Reedy :

Attribute .context_use_ps1 is False in EditorWindow and Outwin, True in 
PyShell.  It is use to switch code paths in multiple classes.  It is equal to 
isinstance(self/editwin, PyShell) (which requires an import).  It has the same 
truth value as attribute .prompt_last_line, which is '' except in PyShell.  
This more informative attribute was added in #31858 to consolidate all PS1 
handling in PyShell.

A PR for #34055 proposed to remove the setting of .context_use_ps1 and the uses 
with .prompt_last_line.  I will change the title after I submit this.  I am not 
yet sure if this is the change I want to make.

--
assignee: terry.reedy
components: IDLE
messages: 332700
nosy: cheryl.sabella, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: IDLE: replace use of EditorWindow.context_use_ps1
type: enhancement
versions: Python 3.7, Python 3.8

___
Python tracker 

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

[issue31858] IDLE: cleanup use of sys.ps1 and never set it.

[Terry J. Reedy]

Terry J. Reedy  added the comment:

By mistake, I deleted the setting of context_use_ps1 in PyShell while still in 
use in several places.  Fixed in #34055.

--

___
Python tracker 

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

Passing back the ERRORLEVEL

[Gisle Vanem]

I have trouble understanding why a 'sys.exit(2)' is
*not* passed back to the CMD shell in this little example:

- c:\py_cmd_test.cmd --
@%WinDir%\py.exe -2 -x %~dp0py_cmd_test.cmd & exit /b %ERRORLEVEL%

# The '-x' is for Python to skip the 1st line of this file.
import sys
print ("Hello, I am %s; %s" % (sys.argv[0], sys.version_info))
sys.exit (2)



Executing this in a 4NT shell (from JPsoft), correctly reports:
c:\> py_cmd_test.cmd & echo %errorlevel
Hello, I am C:\py_cmd_test.cmd; sys.version_info(major=2, minor=7, micro=15, 
releaselevel='final', serial=0)
2

But the junk-ware cmd.exe does not:
C:\>py_cmd_test.cmd & echo %ERRORLEVEL%
Hello, I am C:\py_cmd_test.cmd; sys.version_info(major=2, minor=7, micro=15, 
releaselevel='final', serial=0)
0

Anybody here who can spot the problem?

Same issue with 'py -3'. I'm on Windows-10.

--
--gv
--
https://mail.python.org/mailman/listinfo/python-list

[issue35594] Python script generating Segmentation Fault

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The script has 14 imports from 10 external packages, perhaps half of which 
include C code.  In such cases, the crash is nearly always in the external 
package, and Daugeras has already identified a pandas routine.

Daugeras, you can re-open if you gain evidence that the problem is in the 
cpython code we are responsible for.  But you should start by stripping out as 
much as you can and if there are crashes in pandas, submit a report to its 
authors.

--
nosy: +terry.reedy
resolution:  -> third party
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

[issue35593] Register standard browser: Chrome

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests:  -10652

___
Python tracker 

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

[issue35593] Register standard browser: Chrome

[Terry J. Reedy]

Terry J. Reedy  added the comment:

As near as I can tell, this is *not* a duplicate of #8232.

--
nosy: +terry.reedy
stage: patch review -> 

___
Python tracker 

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

[issue35596] Fatal Python error: initfsencoding: unable to load the file system codec zipimport.ZipImportError: can't find module 'encodings'

[Steve Dower]

Steve Dower  added the comment:

I took a closer look at the diff since 3.7.1, and I'm not seeing anything 
either. I suspect we need to step through zipimport/importlib and figure out 
exactly where it rejects the .pyc files in the zip.

--

___
Python tracker 

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

[issue35609] Improve of abc.py docstring

[Emmanuel Arias]

Change by Emmanuel Arias :


--
pull_requests: +10653, 10654
stage:  -> patch review

___
Python tracker 

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

[issue35609] Improve of abc.py docstring

[Emmanuel Arias]

Change by Emmanuel Arias :


--
pull_requests: +10653, 10654, 10655
stage:  -> patch review

___
Python tracker 

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

[issue35609] Improve of abc.py docstring

[Emmanuel Arias]

Change by Emmanuel Arias :


--
pull_requests: +10653
stage:  -> patch review

___
Python tracker 

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

[issue35608] python3 multiprocessing queue deadlock when use thread and process at same time

[Emmanuel Arias]

Emmanuel Arias  added the comment:

> data = result_queue.get()

And this is blocked

--

___
Python tracker 

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

[issue35593] Register standard browser: Chrome

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch, patch
pull_requests: +10651, 10652
stage:  -> patch review

___
Python tracker 

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

[issue35608] python3 multiprocessing queue deadlock when use thread and process at same time

[Emmanuel Arias]

Emmanuel Arias  added the comment:

Hi

>def write_to_stdout(result_queue: Queue):

I think that you have to write here a sleep. IMO this is blocking all.

--
nosy: +eamanu

___
Python tracker 

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

[issue35593] Register standard browser: Chrome

[Roundup Robot]

Change by Roundup Robot :


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

___
Python tracker 

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

[issue35609] Improve of abc.py docstring

[Emmanuel Arias]

New submission from Emmanuel Arias :

Hi!

I prepare a little improve. I added some samples usage, some clarification and 
delete some whitespace unnecessary.

Attach patch. 

Regards

--
assignee: docs@python
components: Documentation
files: 0001-improve-abc.py-docstring.patch
keywords: patch
messages: 332693
nosy: docs@python, eamanu
priority: normal
severity: normal
status: open
title: Improve of abc.py docstring
type: enhancement
versions: Python 3.8
Added file: 
https://bugs.python.org/file48021/0001-improve-abc.py-docstring.patch

___
Python tracker 

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

[issue35570] 2to3 creates code using deprecated imp module

[Terry J. Reedy]

Terry J. Reedy  added the comment:

It was decided in #21446 to only backport the change, labelled an enhancement, 
to 3.7 and it is now too late to challenge that decision as 3.6 only gets 
security fixes.

--
nosy: +terry.reedy
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Update reload fixer to use importlib instead of imp

___
Python tracker 

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

[issue35608] python3 multiprocessing queue deadlock when use thread and process at same time

[白稳平]

Change by 白稳平 :


--
type:  -> behavior

___
Python tracker 

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

[issue35608] python3 multiprocessing queue deadlock when use thread and process at same time

[白稳平]

New submission from 白稳平 :

I used multi-processes to handle cpu intensive task,I have a thread reading 
data from stdin and put it to a input_queue,  a thread get data from 
output_queue and write it to stdout, multiple processes get data from input 
queue,then handled the data,and put it to output_queue.But It some times will 
block forever,I doubt that it was because inappropriate to use the 
multiprocessing Queue,But I don't know how to solved it,can anyone help me?
my code as follows:

import multiprocessing
import sys
import threading
import time
from multiprocessing import Queue


def write_to_stdout(result_queue: Queue):
"""write queue data to stdout"""
while True:
data = result_queue.get()
if data is StopIteration:
break
sys.stdout.write(data)
sys.stdout.flush()


def read_from_stdin(queue):
"""read data from stdin, put it in queue for process handling"""
try:
for line in sys.stdin:
queue.put(line)
finally:
queue.put(StopIteration)


def process_func(input_queue, result_queue):
"""get data from input_queue,handled,put result into result_queue"""
try:
while True:
data = input_queue.get()
if data is StopIteration:
break
# cpu intensive task,use time.sleep instead
# result = compute_something(data)
time.sleep(0.1)
result_queue.put(data)
finally:
# ensure every process end
input_queue.put(StopIteration)


if __name__ == '__main__':
# queue for reading to stdout
input_queue = Queue(1000)

# queue for writing to stdout
result_queue = Queue(1000)

# thread reading data from stdin
input_thread = threading.Thread(target=read_from_stdin, 
args=(input_queue,))
input_thread.start()

# thread reading data from stdin
output_thread = threading.Thread(target=write_to_stdout, 
args=(result_queue,))
output_thread.start()

processes = []
cpu_count = multiprocessing.cpu_count()
# start multi-process to handle some cpu intensive task
for i in range(cpu_count):
proc = multiprocessing.Process(target=process_func, 
args=(input_queue, result_queue))
proc.start()
processes.append(proc)

# joined input thread
input_thread.join()

# joined all task processes
for proc in processes:
proc.join()

# ensure output thread end
result_queue.put(StopIteration)

# joined output thread
output_thread.join()

test environment:  

python3.6.5
ubuntu16.04

--
components: Library (Lib)
messages: 332691
nosy: davin, pitrou, 白稳平
priority: normal
severity: normal
status: open
title: python3 multiprocessing queue deadlock when use thread and process at 
same time
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

[issue35607] python3 multiprocessing queue deadlock when use thread and process at same time

[白稳平]

Change by 白稳平 :


--
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

[issue35607] python3 multiprocessing queue deadlock when use thread and process at same time

[白稳平]

Change by 白稳平 :


Removed file: https://bugs.python.org/file48020/新建文本文档.txt

___
Python tracker 

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

[issue35607] python3 multiprocessing queue deadlock when use thread and process at same time

[白稳平]

New submission from 白稳平 :

I used multi-processes to handle cpu intensive task,I have a thread reading 
data from stdin and put it to a input_queue,  a thread get data from 
output_queue and write it to stdout, multiple processes get data from input 
queue,then handled the data,and put it to output_queue.But It some times will 
block forever,I doubt that it was because inappropriate to use the 
multiprocessing Queue,But I don't know how to solved it,can anyone help me?
my code as follows:

import multiprocessing
import sys
import threading
import time
from multiprocessing import Queue


def write_to_stdout(result_queue: Queue):
"""write queue data to stdout"""
while True:
data = result_queue.get()
if data is StopIteration:
break
sys.stdout.write(data)
sys.stdout.flush()


def read_from_stdin(queue):
"""read data from stdin, put it in queue for process handling"""
try:
for line in sys.stdin:
queue.put(line)
finally:
queue.put(StopIteration)


def process_func(input_queue, result_queue):
"""get data from input_queue,handled,put result into result_queue"""
try:
while True:
data = input_queue.get()
if data is StopIteration:
break
# cpu intensive task,use time.sleep instead
# result = compute_something(data)
time.sleep(0.1)
result_queue.put(data)
finally:
# ensure every process end
input_queue.put(StopIteration)


if __name__ == '__main__':
# queue for reading to stdout
input_queue = Queue(1000)

# queue for writing to stdout
result_queue = Queue(1000)

# thread reading data from stdin
input_thread = threading.Thread(target=read_from_stdin, 
args=(input_queue,))
input_thread.start()

# thread reading data from stdin
output_thread = threading.Thread(target=write_to_stdout, 
args=(result_queue,))
output_thread.start()

processes = []
cpu_count = multiprocessing.cpu_count()
# start multi-process to handle some cpu intensive task
for i in range(cpu_count):
proc = multiprocessing.Process(target=process_func, 
args=(input_queue, result_queue))
proc.start()
processes.append(proc)

# joined input thread
input_thread.join()

# joined all task processes
for proc in processes:
proc.join()

# ensure output thread end
result_queue.put(StopIteration)

# joined output thread
output_thread.join()

test environment:  

python3.6
ubuntu16.04 lts

--

___
Python tracker 

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

[issue35607] python3 multiprocessing queue deadlock when use thread and process at same time

[白稳平]

Change by 白稳平 :


--
components: Library (Lib)
files: 新建文本文档.txt
nosy: 白稳平
priority: normal
severity: normal
status: open
title: python3 multiprocessing queue deadlock when use thread and process at 
same time
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file48020/新建文本文档.txt

___
Python tracker 

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

Re: Ask for help about class variable scope (Re: Why doesn't a dictionary work in classes?)

[jfong]

jf...@ms4.hinet.net於 2018年12月28日星期五 UTC+8下午4時04分07秒寫道：
> eryk sun at 2018/12/27 UTC+8 PM 6:58:33 wrote:
> > On 12/27/18, jf...@ms4.hinet.net  wrote:
> > >
> > > I still don't get it. When I change it to using list comprehension, the
> > > problem is still there. (it now has no late-binding variable, right? :-)
> > >
> >  class Too:
> > > ... XS = [15, 15, 15, 15]
> > > ... Z4 = [val for val in XS]
> > > ... Z5 = [XS[0] for val in XS]
> > > ...
> > > Traceback (most recent call last):
> > >   File "", line 1, in 
> > >   File "", line 4, in Too
> > >   File "", line 4, in 
> > > NameError: name 'XS' is not defined
> > >
> > > The problem confuse me is that is XS a local variable of the list
> > > comprehension?
> > 
> > XS is not a local variable in the scope of either comprehension. XS is
> > local to the class statement's scope. For each comprehension, an
> > iterator for the current object referenced by XS gets instantiated
> > (early binding) and passed as an argument to the comprehension scope.
> > If we disassemble the comprehension code, we find that this iterator
> > argument has the creatively illegal name ".0". (The bytecode
> > references it by its fast-locals-array index, not its weird name.)
> > 
> > In the Z5 case, XS is a non-local variable (late binding) in the
> > loop-body expression (left-hand side) of the comprehension. That's
> > common for Python code. In every iteration of the loop, the
> > interpreter looks up the object referenced by the name "XS", which can
> > change at any time (e.g. by another thread).
> 
> In Python document 4.2.2. Resolution of names, the last paragraph:
> 
> "...A class definition is an executable statement that may use and define 
> names. These references follow the normal rules for name resolution with an 
> exception that unbound local variables are looked up in the global namespace. 
> ...The scope of names defined in a class block is limited to the class block; 
> it does not extend to the code blocks of methods – this includes 
> comprehensions and generator expressions since they are implemented using a 
> function scope". 
> 
> These statements reflect the following difference:
> 
> >>> xy = [1,2]
> >>> [dir() for i in xy]
> [['.0', 'i'], ['.0', 'i']]
> >>> [xy[0] for i in xy]
> [1, 1]
> 
> >>> class foo():
> ... xs = [1,2]
> ... z4 = [dir() for i in xs]
> ...
> >>> foo().z4
> [['.0', 'i'], ['.0', 'i']]
> >>> class foo():
> ... xs = [1,2]
> ... z4 = [xs[0] for i in xs]
> ...
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "", line 3, in foo
>   File "", line 3, in 
> NameError: name 'xs' is not defined
> >>>
> 
> and it goes further:
> 
> >>> [dir() for i in xy for j in xy]
> [['.0', 'i', 'j'], ['.0', 'i', 'j'], ['.0', 'i', 'j'], ['.0', 'i', 'j']]
> >>> class foo():
> ... xs = [1,2]
> ... z5 = [dir() for i in xs for j in xs]
> ...
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "", line 3, in foo
>   File "", line 3, in 
> NameError: name 'xs' is not defined
> >>>
> 
> That's all I had learn so far, although not understand the design decision 
> behind it yet:-(
> 
> --Jach

Anyway, it "looks" weird. Isn't it?

>>> xs = [5,6,7,8]
>>> class foo():
... xs = [1,2,3]
... z4 = [xs[i] for i in xs]
...
>>> foo.z4
[6,7,8]

xs in the "for" statement referenced to class variable xs and xs[i] in the body 
referenced to the global xs with i from locals.

PS. Don't bother to reply. This is just for my own documentary:-)
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue35601] Race condition in test_signal_handling_args x86-64 High Sierra 3.75

[miss-islington]

miss-islington  added the comment:


New changeset 8f9228dd3a37c98876c9c8ff7fb0042650303474 by Miss Islington (bot) 
in branch '3.7':
bpo-35601: Alleviate race condition when waiting for SIGALRM in test_asyncio 
(GH-11337)
https://github.com/python/cpython/commit/8f9228dd3a37c98876c9c8ff7fb0042650303474


--
nosy: +miss-islington

___
Python tracker 

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

[issue35601] Race condition in test_signal_handling_args x86-64 High Sierra 3.75

[miss-islington]

Change by miss-islington :


--
pull_requests: +10646, 10647, 10648, 10649, 10650

___
Python tracker 

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

[issue35601] Race condition in test_signal_handling_args x86-64 High Sierra 3.75

[miss-islington]

Change by miss-islington :


--
pull_requests: +10645, 10646

___
Python tracker 

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

[issue35601] Race condition in test_signal_handling_args x86-64 High Sierra 3.75

[miss-islington]

Change by miss-islington :


--
pull_requests: +10647, 10650

___
Python tracker 

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

[issue35601] Race condition in test_signal_handling_args x86-64 High Sierra 3.75

[miss-islington]

Change by miss-islington :


--
pull_requests: +10646, 10647, 10649, 10650

___
Python tracker 

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

[issue35601] Race condition in test_signal_handling_args x86-64 High Sierra 3.75

[miss-islington]

Change by miss-islington :


--
pull_requests: +10645, 10646, 10647

___
Python tracker 

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

[issue35601] Race condition in test_signal_handling_args x86-64 High Sierra 3.75

[miss-islington]

Change by miss-islington :


--
pull_requests: +10645

___
Python tracker 

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

[issue35601] Race condition in test_signal_handling_args x86-64 High Sierra 3.75

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset 5471420faa84519530f29b08f2b042b2288e3e96 by Pablo Galindo in 
branch 'master':
bpo-35601: Alleviate race condition when waiting for SIGALRM in test_asyncio 
(GH-11337)
https://github.com/python/cpython/commit/5471420faa84519530f29b08f2b042b2288e3e96


--

___
Python tracker 

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

[issue34055] IDLE: erroneous 'smart' indents in shell

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests:  -10643

___
Python tracker 

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

[issue34055] IDLE: erroneous 'smart' indents in shell

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests:  -10644

___
Python tracker 

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

[issue34055] IDLE: erroneous 'smart' indents in shell

[miss-islington]

miss-islington  added the comment:


New changeset 95dc4577c3a1bb12978de5234aaf07839f4d7844 by Miss Islington (bot) 
in branch '3.7':
bpo-34055: Revert deletion of line in IDLE's PyShell (GH-11346)
https://github.com/python/cpython/commit/95dc4577c3a1bb12978de5234aaf07839f4d7844


--
nosy: +miss-islington

___
Python tracker 

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

[issue34055] IDLE: erroneous 'smart' indents in shell

[miss-islington]

Change by miss-islington :


--
pull_requests: +10642, 10643
stage: test needed -> patch review

___
Python tracker 

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

[issue34055] IDLE: erroneous 'smart' indents in shell

[miss-islington]

Change by miss-islington :


--
pull_requests: +10642, 10643, 10644
stage: test needed -> patch review

___
Python tracker 

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

[issue34055] IDLE: erroneous 'smart' indents in shell

[miss-islington]

Change by miss-islington :


--
pull_requests: +10642
stage: test needed -> patch review

___
Python tracker 

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

[issue34055] IDLE: erroneous 'smart' indents in shell

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 4bc246786f003cdf1fffb3403b4cd92fc42ba9ef by Terry Jan Reedy in 
branch 'master':
bpo-34055: Revert deletion of line in IDLE's PyShell (#11346)
https://github.com/python/cpython/commit/4bc246786f003cdf1fffb3403b4cd92fc42ba9ef


--

___
Python tracker 

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

Re: Undocumented issue: Open system call blocks on named pipes (and a feature request)

[Cameron Simpson]

On 28Dec2018 20:21, Daniel Ojalvo  wrote:
I agree that previous behavior shouldn't be changed, but I would 
suggest updating the documentation to point it out as a footnote. The 
current behavior is correct just unclear. Most people just learning 
about the open command wouldn't have this expectation.


Maybe, maybe not. "Most" is a conjecture. IMO people will only find it 
surprising if they think any filesystem object can be instantly opened.  
However that is a misapprehension on their part.


My personal expectation is that open() will come back when the object is 
open. I don't have a timeframe in mind unless I have a strong 
expectation about _what_ I'm opening.


I came across the issue when I had a program that would open up all the 
files in a directory to read a few bytes from the beginning. My concern 
would be someone just making a named pipe over a file that a program 
would open.


What about a symlink to a magic /dev/tcp/host:port device, initiating a 
TCP connection? Particularly if "host" is down or inaccessible? Etc.


Arguably, anyone affected by that would be shooting themselves in the 
foot to begin with, but I think there are "security" concerns because 
someone could cause a bit of mischief that would be difficult to 
diagnose.


It isn't hard to diagnose at all. Point strace at the hung pogram, see 
it is opening some path, "ls -ld the-path", oooh, it isn't a regular 
file.


The point here is that if a programme opens every file in a directory, 
maybe it should constrain itself to regular files. Opening anything else 
may not just hang, it can have real world side effects. (Usually such 
effect happen at some point after open, for example opening a rewind 
take device will physicially rewind the tape on close, but you've 
committed to that happening by opening it in the first place.)


I think Chris offered the example of a subdirectory to suggest that such 
a programme already has an opnion about what to open and what to leave 
alone (unless is _does_ open() subdirectories, which might be useful but 
is usually misleading and on some OSes unsupported). So the programme 
should be pickier anyway.


That all being said, I think I would like to put in a feature request 
for a non-blocking option. How should I go about doing so?


I agree with the suggestion already made: devise a well thought out 
proposal which fits nicely with the existing open() call (eg an addition 
to the mode argument or something), and describe it clearly in 
python-ideas.


Certainly a number of things can be opened in a "nonblocking" mode, 
which means that reads return instantly if there's no available data, so 
having an open not block isn't unreasonable to want. But it may be 
unreasonable to implement in general: OSes may not support it directly.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

[issue35606] Add prod() function to the math module

[Karthikeyan Singaravelan]

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

RE: graded randomness

[Avi Gross]

Abdur-Rahman

I am sure various modules available have ready-made solutions and I see
others have replied to your question. The usual disclaimers apply. This is
an academic discussion and not a statement of the right or only way to do an
abstract task.

So just a thought. You seem interested in a GENERAL situation where you have
N situations with each having a specific probability and the probabilities
sum to 1.0. If that is right, you are creating a partition where you can
make a data structure listing N ordered items along with their individual
probability. Given such a list, you can create another item that is a
cumulative sum.

In your example, your individual probabilities for ['green', 'red', 'blue']
are [0.4, 0.4, 0.2] but the use of lists is just for illustration. You might
use a Numpy array as they have a cumulative sum function:

import numpy as np
np.cumsum([0.4, 0.4, 0.2])
Returns:
array([0.4, 0.8, 1. ])

or viewed vertically:

np.cumsum([0.4, 0.4, 0.2]).reshape(3,1)
array([[0.4],
   [0.8],
   [1. ]])

Again, we are talking about a GENERAL solution but using this example to
illustrate. To get a weighted probability now, you use the random module (or
anything else) to generate a random number between 0 and 1. You search in
the cumulative sum data structure to find the right range. A random value
less than 0.4 should direct you to using green. If above that but less than
0.8, use red. Else, use blue.

To do this properly, you can decide what data structures makes this easy to
do. Maintaining three independent lists or arrays may not be optimal. 

The main idea is to find a way to segment your choices. So consider a
different common example of rolling a pair of (six sided) standard dice. You
know there are 6**2 possible outcomes. There is only one way to get a sum of
2 by rolling a one and another one. So the probability is 1/36 or .0277...
and you can calculate the probabilities of all the other sums with a 7 being
the most common roll at .1667. In this example your choices are rolls of 2
through 12 or 11 choices. The same logic applies. Generate 11 data measures
and a cumulative sum. Just as illustration, I show code using a Pandas
DataFrame object.

import numpy as np
import pandas as pd
diceSumText = np.array(["two", "three", "four", "five", "six", "seven",
"eight", "nine", "ten", "eleven", "twelve"])
diceSumVal = np.array(range(2,13))
diceProbability = np.array([1, 2, 3, 4, 5, 6, 5, 4, 3, 2, 1]) / 36
diceProbCumSum = np.cumsum(diceProbability)

Now combine those:

mydata = pd.DataFrame({"Text": diceSumText, "Value": diceSumVal, "Prob":
diceProbability, "Cum": diceProbCumSum})
print(mydata)

  Text  Value  Prob   Cum
0  two  2  0.027778  0.027778
1three  3  0.06  0.08
2 four  4  0.08  0.17
3 five  5  0.11  0.28
4  six  6  0.138889  0.416667
5seven  7  0.17  0.58
6eight  8  0.138889  0.72
7 nine  9  0.11  0.83
8  ten 10  0.08  0.916667
9   eleven 11  0.06  0.97
10  twelve 12  0.027778  1.00

Again, you can do something any number of ways. This is just one. And in
this format the indentation is not great. 

But it lets you write an algorithm that finds the highest 'index" that still
is below the random number chosen and then select either the text or value
that fits in that partition. Not to repeat, there are many other ways so
feel free to innovate. 


-Original Message-
From: Python-list  On
Behalf Of Abdur-Rahmaan Janhangeer
Sent: Friday, December 28, 2018 2:45 PM
To: Python 
Subject: Re: graded randomness

well i wanted that to improve the following code:

https://www.pythonmembers.club/2018/12/28/reviving-bertrand-russell-through-
python/

that one i used the random list technique

Abdur-Rahmaan Janhangeer
http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius

>
--
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue35605] backported patch requires new sphinx, minimum sphinx version was not bumped

[Ned Deily]

Ned Deily  added the comment:

Julien (@mdk) is the doc builds expert.

--
assignee: docs@python -> mdk

___
Python tracker 

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

[issue5672] Implement a way to change the python process name

[Dan Stromberg]

Dan Stromberg  added the comment:

Isn't this "python script doesn't show up in top correctly" issue a matter of 
"#!/usr/bin/env python3"?

If you "#!/usr/bin/python3" (for example) instead, top seems happy.

--
nosy: +strombrg

___
Python tracker 

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

[issue34055] IDLE: erroneous 'smart' indents in shell

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests:  -10641

___
Python tracker 

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

[issue34055] IDLE: erroneous 'smart' indents in shell

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I changed the title back to the symptom description, rather than the wrong fix. 
 As Cheryl noted, the cause of the specific regression is the erroneous 
deletion of one line in pyshell.PyShell.  The simplest fix is to put is back.

Globally replacing context_use_ps1 is a different issue, and there is more than 
one possibility.  I will open a new issue and move PR 11307 there.

The reversion also reverts the 'fixes' that came with the error.  Fixing the 
shell branch, now that is is used, will be a different issue.
>>> d = {1:3,
 # correct indent, 3.7

>>> d = {1:3,
 # indent not accounting for prompt, after reversion

--
stage: patch review -> test needed
title: IDLE Shell: check syntax before smart indent -> IDLE: erroneous 'smart' 
indents in shell

___
Python tracker 

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

[issue34055] IDLE: erroneous 'smart' indents in shell

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests:  -10640

___
Python tracker 

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

[issue34055] IDLE Shell: check syntax before smart indent

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests: +10639
stage: test needed -> patch review

___
Python tracker 

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

[issue34055] IDLE Shell: check syntax before smart indent

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests: +10639, 10640
stage: test needed -> patch review

___
Python tracker 

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

[issue34055] IDLE Shell: check syntax before smart indent

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests: +10639, 10640, 10641
stage: test needed -> patch review

___
Python tracker 

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

[issue35605] backported patch requires new sphinx, minimum sphinx version was not bumped

[Anthony Sottile]

Anthony Sottile  added the comment:

I assume that means I should only target 3.6 -- does the patch look like the 
right approach? I can make a PR

--

___
Python tracker 

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

[issue35605] backported patch requires new sphinx, minimum sphinx version was not bumped

[Steve Dower]

Steve Dower  added the comment:

I think we're okay to increase the minimum version on the active branches.

--

___
Python tracker 

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

[issue35605] backported patch requires new sphinx, minimum sphinx version was not bumped

[Anthony Sottile]

Anthony Sottile  added the comment:

If I add a patch which is essentially:


try:  # sphinx>=1.6
from sphinx.util.logging import getLogger
except ImportError:  # sphinx<1.6
from logging import getLogger

will that be fine?

and should I open that against 3.7 to be backported or just against 3.6 (I also 
ran into the same issue when backporting 3.7.2 for xenial -- but there I 
adjusted the minimum sphinx version: 
https://github.com/deadsnakes/python3.7/commit/c27b89bc7032d0b072b46c7425e5b32788f1c0fd
 )

--

___
Python tracker 

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

Re: Undocumented issue: Open system call blocks on named pipes (and a feature request)

[Chris Angelico]

On Sat, Dec 29, 2018 at 7:21 AM Daniel Ojalvo  wrote:
>
> Thank you for the advice!
>
> I haven't used the opener argument before, but I'll keep it for future 
> reference. I think it's still a little kludge-y, but it works.

It has a very similar effect to what you were proposing, but still
works within the normal open() ecosystem. Its main benefit is that it
works on existing Pythons, whereas any idea proposed today can't get
into 3.7 and maybe not even 3.8.

> I agree that previous behavior shouldn't be changed, but I would suggest 
> updating the documentation to point it out as a footnote. The current 
> behavior is correct just unclear. Most people just learning about the open 
> command wouldn't have this expectation.
>

That's what I'm not sure about. Do people really have an expectation
of nonblocking behaviour?

> I came across the issue when I had a program that would open up all the files 
> in a directory to read a few bytes from the beginning. My concern would be 
> someone just making a named pipe over a file that a program would open. 
> Arguably, anyone affected by that would be shooting themselves in the foot to 
> begin with, but I think there are "security" concerns because someone could 
> cause a bit of mischief that would be difficult to diagnose.
>

What happens if someone has a subdirectory in there? To be resilient
against everything you might come across, you probably need to check
anyway.

> That all being said, I think I would like to put in a feature request for a 
> non-blocking option. How should I go about doing so?

Hmm, there are a few options. If you reckon it's pretty easy, you
could just go straight to a GitHub pull request, and discuss it there.
Or you could open a bugs.python.org tracker issue and hope someone
else does the coding. Alternatively, you could find out who else
supports the idea by posting to the python-id...@python.org mailing
list.

Of those, I think posting to python-ideas is possibly the best, as
there will likely be some bikeshedding about the name and such.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue28097] IDLE: document all key bindings, add menu items for more.

[miss-islington]

miss-islington  added the comment:


New changeset b716c716b5d5dc630d85dd16ca6526948745c020 by Miss Islington (bot) 
in branch '3.7':
bpo-28097: IDLE - Add Previous/Next History to Shell menu (GH-11325)
https://github.com/python/cpython/commit/b716c716b5d5dc630d85dd16ca6526948745c020


--
nosy: +miss-islington

___
Python tracker 

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

RE: Undocumented issue: Open system call blocks on named pipes (and a feature request)

[Daniel Ojalvo via Python-list]

Thank you for the advice!

I haven't used the opener argument before, but I'll keep it for future 
reference. I think it's still a little kludge-y, but it works.

I agree that previous behavior shouldn't be changed, but I would suggest 
updating the documentation to point it out as a footnote. The current behavior 
is correct just unclear. Most people just learning about the open command 
wouldn't have this expectation. I came across the issue when I had a program 
that would open up all the files in a directory to read a few bytes from the 
beginning. My concern would be someone just making a named pipe over a file 
that a program would open. Arguably, anyone affected by that would be shooting 
themselves in the foot to begin with, but I think there are "security" concerns 
because someone could cause a bit of mischief that would be difficult to 
diagnose.

That all being said, I think I would like to put in a feature request for a 
non-blocking option. How should I go about doing so?

Thanks again,
Dan

-Original Message-
From: Chris Angelico  
Sent: Thursday, December 27, 2018 7:10 PM
To: python-list@python.org
Subject: Re: Undocumented issue: Open system call blocks on named pipes (and a 
feature request)

On Fri, Dec 28, 2018 at 1:38 PM Daniel Ojalvo via Python-list 
 wrote:
>
> Hello,
>
> I've been working on a python3 project and I came across an issue with the 
> open system call that, at the very least, isn't documented. In my humble 
> opinion, the 
> documentation should 
> be updated because folks wouldn't expect open to be a blocking operation and 
> simply error out. Worse yet, open doesn't have an option to make itself 
> non-blocking. You have to use the os system calls to kludge a solution.
>

Hmm. I disagree that the docs are deceptive here; I would normally expect 
open() to block if it needs to. But looking at this as a feature request, it 
seems reasonable. Actually, it's not even that hard to do, since open() is 
already pluggable:

rosuav@sikorsky:~/tmp$ rm rene_magritte
rosuav@sikorsky:~/tmp$ mkfifo rene_magritte rosuav@sikorsky:~/tmp$ ls -l 
rene_magritte
prw-r--r-- 1 rosuav rosuav 0 Dec 28 14:05 rene_magritte rosuav@sikorsky:~/tmp$ 
python3 Python 3.8.0a0 (heads/master:8b9c33ea9c, Nov 20 2018, 02:18:50) [GCC 
6.3.0 20170516] on linux Type "help", "copyright", "credits" or "license" for 
more information.
>>> import os
>>> def nonblock(fn, mode): return os.open(fn, mode | os.O_NONBLOCK)
...
>>> open("rene_magritte", opener=nonblock)
<_io.TextIOWrapper name='rene_magritte' mode='r' encoding='UTF-8'>
>>> _.read(1)
''

> Here is how I reproduced the issue:
>
> root@beefy:~/sandbox# mkfifo this_is_a_pipe

(my example file name is a more subtle reference...)

> I'm doing this to get a fileobject and make it error out if we do have a 
> blocking special file:
> with os.fdopen(os.open(, os.O_RDONLY| os.O_NONBLOCK) , mode='rb') 
> as file_obj:
>
> I think this is mostly a documentation bug because this wouldn't be expected 
> behavior to someone reading the docs, but open is behaving as the fifo man 
> page is documented. The 
> feature request would be to add a non-blocking option to the default open 
> system call.
>

Honestly, I don't think there's a problem with it blocking by default.
Most of Python works that way. But it would be pretty straight-forward to add 
"nonblocking=False" as another keyword-only parameter, and for compatibility 
with existing versions (back as far as 3.3), the opener should work just fine.

ChrisA

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue28097] IDLE: document all key bindings, add menu items for more.

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests:  -10637

___
Python tracker 

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

[issue28097] IDLE: document all key bindings, add menu items for more.

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests:  -10638

___
Python tracker 

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

[issue28097] IDLE: document all key bindings, add menu items for more.

[miss-islington]

Change by miss-islington :


--
pull_requests: +10636, 10637
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

[issue28097] IDLE: document all key bindings, add menu items for more.

[miss-islington]

Change by miss-islington :


--
pull_requests: +10636, 10637, 10638
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

[issue28097] IDLE: document all key bindings, add menu items for more.

[miss-islington]

Change by miss-islington :


--
pull_requests: +10636
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

[issue28097] IDLE: document all key bindings, add menu items for more.

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset c0381aaea4ad3e866bde70393c4f7efe9bcf3568 by Terry Jan Reedy 
(Cheryl Sabella) in branch 'master':
 bpo-28097: IDLE - Add Previous/Next History to Shell menu (#11325)
https://github.com/python/cpython/commit/c0381aaea4ad3e866bde70393c4f7efe9bcf3568


--

___
Python tracker 

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

[issue35605] backported patch requires new sphinx, minimum sphinx version was not bumped

[Ned Deily]

Ned Deily  added the comment:

I would view this as a build regression in 3.6.8 so I would accept a fix for 
the 3.6 branch.

--

___
Python tracker 

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

Re: graded randomness

[Abdur-Rahmaan Janhangeer]

well i wanted that to improve the following code:

https://www.pythonmembers.club/2018/12/28/reviving-bertrand-russell-through-python/

that one i used the random list technique

Abdur-Rahmaan Janhangeer
http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ
Mauritius

>
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue35606] Add prod() function to the math module

[Raymond Hettinger]

New submission from Raymond Hettinger :

Back in 2007, a user suggested a built-in prod() function with an API similar 
to the built-in sum() function.  The proposal was rejected because it wasn't 
needed often enough to justify a builtin function.  See 
https://bugs.python.org/issue1093

Though prod() doesn't meet the threshold for a builtin, it would be reasonable 
to add this to the math module (or an imath module).

Personally, I've wanted and written this function on several occasions (for 
applications such as multiplying probabilities).  On stack overflow, it has 
been a popular question with recurring interest.  See 
https://stackoverflow.com/questions/7948291/ and 
https://stackoverflow.com/questions/595374

--
components: Library (Lib)
messages: 332676
nosy: aleax, mark.dickinson, rhettinger, tim.peters
priority: normal
severity: normal
status: open
title: Add prod() function to the math module
type: enhancement
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

[issue35605] backported patch requires new sphinx, minimum sphinx version was not bumped

[Steve Dower]

Steve Dower  added the comment:

We need Ned's approval to fix anything in 3.6 now. Typically we do consider 
build issues, and this one is fairly innocent (the affected code should only be 
used on Windows, but the import may trigger elsewhere).

I'd be happy to take a patch to use logging when the sphinx one is not found. 
We more or less enforce a newer version of Sphinx on the platforms where it 
matters, but for those restricted by their distros we can pretty easily help 
out.

--
keywords: +easy
nosy: +ned.deily
priority: normal -> low

___
Python tracker 

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

[issue35596] Fatal Python error: initfsencoding: unable to load the file system codec zipimport.ZipImportError: can't find module 'encodings'

[Steve Dower]

Steve Dower  added the comment:

None of the code you linked is defined on Windows at all, so it can't be that.

Are any stat checks done when there's only a .pyc to import? Could it be 
deciding that the .pyc is out of date and then failing to find source?

--

___
Python tracker 

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

[issue34055] IDLE Shell: check syntax before smart indent

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests:  -10544

___
Python tracker 

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

[issue34055] IDLE Shell: check syntax before smart indent

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests:  -10545

___
Python tracker 

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

[issue28097] IDLE: document all key bindings, add menu items for more.

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Cheryl, the addition looks nice.  But for anything else, lets discuss here 
first.

--

___
Python tracker 

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

[issue35555] IDLE: Gray out Code Context on non-editor windows

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests:  -10634

___
Python tracker 

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

[issue35555] IDLE: Gray out Code Context on non-editor windows

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests:  -10635

___
Python tracker 

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

[issue35555] IDLE: Gray out Code Context on non-editor windows

[miss-islington]

Change by miss-islington :


--
pull_requests: +10633, 10634, 10635

___
Python tracker 

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

[issue35555] IDLE: Gray out Code Context on non-editor windows

[miss-islington]

Change by miss-islington :


--
pull_requests: +10633, 10634

___
Python tracker 

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

[issue35555] IDLE: Gray out Code Context on non-editor windows

[miss-islington]

Change by miss-islington :


--
pull_requests: +10633

___
Python tracker 

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

[issue22703] Idle Code Context menu entrie(s)

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I understand.  Until tcl/tk can be patched to work with both Mohave and past 
macOS versions, it is a nasty situation.

--

___
Python tracker 

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

RE: dangerous class neighborhood

[Avi Gross]

[REAL SUBJECT: an assortment of nothings]

 

Python tricks?

 

Speaking from a tutorial forum, tricks can catch people trying to learn.

 

I am not sure of the history of the ellipsis object. 

 

>>> dir(...)

['__class__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__', 
'__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', 
'__init_subclass__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', 
'__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', 
'__subclasshook__']

 

Would you believe it is syntactically valid to use 4 periods in a row by asking 
for the contents like this:

 

>>> __class__



 

My impression is that the main initial use for the ellipsis was as a 
placeholder in a numpy multidimensional array so you can specify which axis you 
want to get all of:

 

https://python-reference.readthedocs.io/en/latest/docs/brackets/ellipsis.html

 

I don’t want to start yet another discussion but there seem to be a range of 
ways to say you want something without quite saying what you want. We have 
mentioned the “pass” argument. We also have the naked colon as in:

 

new = old[ : ]

 

The above will make a shallow copy of a list. It is not really a new symbol but 
what happens when you take from:to and remove the from and the to and allow the 
defaults to take over. It gets murky as often underneath it all there are 
hidden objects like the slice:

 

>>> alpha = list(range(10))

>>> alpha

[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

 

So you can explicitly index with a slice object or use the colon notation to 
get the same thing:

 

>>> alpha[1:5]

[1, 2, 3, 4]

>>> alpha[slice(1,5)]

[1, 2, 3, 4]

>>> alpha[1:10:2]

[1, 3, 5, 7, 9]

>>> alpha[slice(1,10,2)]

[1, 3, 5, 7, 9]

>>> alpha[5:]

[5, 6, 7, 8, 9]

>>> alpha[slice(5,)]

[0, 1, 2, 3, 4]

>>> alpha[slice(5,None)]

[5, 6, 7, 8, 9]

>>> alpha[:]

[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

>>> alpha[slice(,)]

SyntaxError: invalid syntax

>>> alpha[slice(None)]

[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

 

Note the placeholder is now the item called “None”

 

The ellipsis can be used here but causes errors.

 

And there are more subtle placeholders with meanings like DOES not exist. Numpy 
has a “nan” and Pandas has NaN and a missing date is NaT and beneath it all 
there are names for a missing int versus float versus who knows what.

 

These can be subtle ideas for a newcomer, even for people who come from 
languages that don’t have the distinctions. For that matter, there are ways to 
say something is infinite which is not the same as saying the maximum value you 
can store in N bits.

 

But I express some caution on calling some of these things tricks. Yes, of 
course they can be tricky. What they often are may well be considered 
additional functionality by way of abstractions. Clearly a key word like “pass” 
may be easier to understand than some of the others.

 

 

From: Abdur-Rahmaan Janhangeer  
Sent: Friday, December 28, 2018 3:46 AM
To: Avi Gross 
Cc: Python 
Subject: Re: dangerous class neighborhood

 

thanks, the 3 dots are more explicit, thought was another py trick

 

yours,

Abdur-Rahmaan Janhangeer
http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ
Mauritius

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue35555] IDLE: Gray out Code Context on non-editor windows

[Terry J. Reedy]

Terry J. Reedy  added the comment:

A function to change state will be needed in the future, as illustrated by a 
preliminary version of PR-11325. On that PR, I requested that this part of that 
PR should be attached to this issue instead, with no change in the blurb.

--

___
Python tracker 

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

[issue35555] IDLE: Gray out Code Context on non-editor windows

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests:  -10631

___
Python tracker 

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

[issue35555] IDLE: Gray out Code Context on non-editor windows

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests:  -10632

___
Python tracker 

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

[issue20849] add exist_ok to shutil.copytree

[Giampaolo Rodola']

Change by Giampaolo Rodola' :


--
assignee:  -> giampaolo.rodola
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

[issue20849] add exist_ok to shutil.copytree

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:


New changeset 9e00d9e88fbf943987e4771c753f5ca8f794103e by Giampaolo Rodola 
(jab) in branch 'master':
bpo-20849: add dirs_exist_ok arg to shutil.copytree (patch by Josh Bronson)
https://github.com/python/cpython/commit/9e00d9e88fbf943987e4771c753f5ca8f794103e


--

___
Python tracker 

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

[issue35588] Speed up mod/divmod/floordiv for Fraction type

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Using divmod() makes the case of small integers 2-3% slower, but makes the case 
of large integers more significantly faster. And since the code with divmod() 
is simpler, I think it is worth to use it.

The Fraction class also serves educational goals. The simpler code is better. 
The proposed patch makes the code slightly more complex, but not too much. I 
think it's an affordable price for such degree of speed up.

--

___
Python tracker 

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

[issue28009] core logic of uuid.getnode() is broken for netstat

[Michael Felt]

Michael Felt  added the comment:

p.s., removed 2.7 and 3.6 as too old for any interest.

--
versions:  -Python 2.7, Python 3.6

___
Python tracker 

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

[issue28009] core logic of uuid.getnode() is broken for netstat

[Michael Felt]

Michael Felt  added the comment:

As I am not clear on where to have a more general discussion (in a PR 
conversation) or here - going to start here because I cannot figure out which 
comment in the PR to reply to.

Generally, before modifying the test_uuid.py to based tests on 
uuid.__NODE_GETTERS - these need to be defined.

I have my AIX systems, I found a macos I could do some queries on, and 
downloaded cygwin and came up with this starting point:

_MACOS = sys.platform == 'darwin'
_WIN32 = sys.platform == 'win32'
_CYGWIN= sys.platform == 'cygwin'
_AIX = sys.platform.startswith("aix")

...

if _AIX:
_NODE_GETTERS = [_unix_getnode, _netstat_getnode]
elif _MACOS:
_NODE_GETTERS = [_unix_getnode, _ifconfig_getnode, _netstat_getnode]
elif _CYGWIN:
_NODE_GETTERS = [_ipconfig_getnode]
elif _WIN32:
_NODE_GETTERS = [_windll_getnode, _ipconfig_getnode, _netbios_getnode]
else:
_NODE_GETTERS = [_unix_getnode, _ifconfig_getnode, _ip_getnode,
  _arp_getnode, _lanscan_getnode, _netstat_getnode]


What I am also wondering - is it worthwhile to have a way to only define the 
getter() routines a platform can actually use? e.g., On AIX I can call 
uuid._ipconfig_getter(), but get nonsense. Or is it too much effort?

Finally, can someone with access to other platforms where differences may be 
expected (e.g., Solaris, hpux, or even different flavors of Linux) - to make 
this _NODE_GETTERS mode complete (specific).

--

___
Python tracker 

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

Re: Undocumented issue: Open system call blocks on named pipes (and a feature request)

[Chris Angelico]

On Sat, Dec 29, 2018 at 4:24 AM Grant Edwards  wrote:
>
> On 2018-12-27, Daniel Ojalvo via Python-list  wrote:
>
>  open("this_is_a_pipe")
> >
>
> Opening a tty device can also block[1].  However, if somebody is using
> the open() builtin on tty devices that's probably the least of their
> problems.

Depending on what you mean by "block", pretty much anything can. It's
not indefinite, but this is clearly an example of blocking behaviour:

rosuav@sikorsky:~$ mkdir gideon_home
rosuav@sikorsky:~$ sshfs gideon: gideon_home/
rosuav@sikorsky:~$ python3
Python 3.8.0a0 (heads/master:8b9c33ea9c, Nov 20 2018, 02:18:50)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.time(); open("gideon_home/.bashrc"); time.time()
1546018477.1130645
<_io.TextIOWrapper name='gideon_home/.bashrc' mode='r' encoding='UTF-8'>
1546018477.8339248

Due to the latency introduced by having a completely-out-of-cache
remote access directory, simply opening an ordinary file with an
ordinary path took over half a second. But *this* type of blocking
access is NOT changed by adding os.O_NONBLOCK; it will still take that
half second even if you say "opener=nonblock". OTOH, this form of
blocking is a lot safer - normal file systems [1] might be slow, but
they can't deadlock, whereas a pipe most certainly could.

ChrisA

[1] Of course, you could use fusermount and shenanigans to do
basically anything. But at that point, you're deliberately shooting
yourself in the foot, and all I can advise is "don't do that".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Undocumented issue: Open system call blocks on named pipes (and a feature request)

[Grant Edwards]

On 2018-12-27, Daniel Ojalvo via Python-list  wrote:

 open("this_is_a_pipe")
>

Opening a tty device can also block[1].  However, if somebody is using
the open() builtin on tty devices that's probably the least of their
problems.

[1] Technically, opening any character-mode device could block --
serial ports are the only "common" example I can think of.

-- 
Grant Edwards   grant.b.edwardsYow! How many retured
  at   bricklayers from FLORIDA
  gmail.comare out purchasing PENCIL
   SHARPENERS right NOW??

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue35605] backported patch requires new sphinx, minimum sphinx version was not bumped

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +mdk, steve.dower

___
Python tracker 

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

[issue35605] backported patch requires new sphinx, minimum sphinx version was not bumped

[Anthony Sottile]

Anthony Sottile  added the comment:

oops, pressed the button too quickly, meant to mention that sphinx 1.6 was 
released 2017-05

--

___
Python tracker 

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

[issue35605] backported patch requires new sphinx, minimum sphinx version was not bumped

[Anthony Sottile]

New submission from Anthony Sottile :

Noticed this while packaging 3.6.8 for deadsnakes (ubuntu ppa)

This patch: https://github.com/python/cpython/pull/11251

Requires a version of sphinx where `sphinx.util.logging.getLogger` is 
available.  It appears that the first version which that was available was 1.6: 
https://github.com/sphinx-doc/sphinx/commit/6d4e6454093953943e79d4db6efeb17390870e62#diff-db360b033c6011189d978db1a4b7dcb7

For example, on ubuntu xenial (16.04) the newest packaged version of 
python3-sphinx available is 1.3.6 (released 2016-02) which satisfies the 
"minimum version": 
https://github.com/python/cpython/blob/3c6b436a57893dd1fae4e072768f41a199076252/Doc/conf.py#L36-L37

I hacked around it in this case by just using `logging.getLogger`: 
https://github.com/deadsnakes/python3.6/commit/9ba2234f35087a4bf67e3aecf2bd8dd0e3f67186

I'm not sure what the right answer is here, bumping the minimum version will 
make it _harder_ for packagers -- though I understand continuing to support old 
(2 years ago) things can be cumbersome.

--
assignee: docs@python
components: Build, Documentation
messages: 332665
nosy: Anthony Sottile, docs@python
priority: normal
severity: normal
status: open
title: backported patch requires new sphinx, minimum sphinx version was not 
bumped
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

Re: ANNOUNCE: TIB/Rendezvous module for python

[zhen . zhong]

Hi, There,

I am an engineer in Taiwan and I was trying to install 
rvpython-2.1final.tar.gz  but it's built up in python 2.x which cannot be 
installed in python 3 or above.

Is there any officially released version of rvpython  compatible 
with python 3 or above?

Thank you, sincerely. 


==
Zhen Zhong  鍾震
Innolux Corporation
TFT PIA CIM1-EA
TEL：037-586000#64734
苗栗縣竹南鎮新竹科學工業園區竹南基地科學路160號
No.160,Kesyue Rd., Chunan Science Park,Miao-Li Country 350,Taiwan
E-mail：zhen.zh...@innolux.com
=

This e-mail and any files transmitted with it are CONFIDENTIAL and 
intended solely for the use of the intended recipient.  If you are not the 
intended recipient or the named addressee, please notify the sender 
immediately and delete this e-mail and any files transmitted with it from 
your system; you should not disseminate, distribute, or copy this e-mail 
and any files transmitted with it, or take any action in reliance on the 
contents of the said e-mail and files.

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue35596] Fatal Python error: initfsencoding: unable to load the file system codec zipimport.ZipImportError: can't find module 'encodings'

[Nick Coghlan]

Nick Coghlan  added the comment:

Reviewing the diff at https://github.com/python/cpython/compare/v3.7.1...v3.7.2 
the only item I've spotted that seems like it could even plausibly be related 
is the tweak at 
https://github.com/python/cpython/compare/v3.7.1...v3.7.2#diff-baf5eab51059d96fb8837152dab0d1a4

(Click the Files tab to get your browser to jump to the anchor in the second 
link)

That's a change to the function that emits the "Fatal Python error: 
initfsencoding: unable to load the file system codec" message.

That change means that embedding applications could potentially be hitting the 
codec name resolution at 
https://github.com/python/cpython/blob/3.7/Python/pylifecycle.c#L1643 with the 
filesystem encoding set as "ascii", rather than handling that case through the 
"get_locale_encoding()" branch, which does the initial codec name lookup with 
the filesystem encoding still set to NULL (and hence falling back to the locale 
encoding as the default).

However, the only way that new branch could trigger is if check_force_ascii() 
(at https://github.com/python/cpython/blob/v3.7.2/Python/fileutils.c#L100 ) is 
returning 1 for some reason, which we only expect it to do on some misbehaving 
BSD OSes, not on Windows: https://github.com/python/cpython/pull/10233

--

___
Python tracker 

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