[issue28758] UnicodeDecodeError: 'gbk' codec can't decode byte 0xab in position 74: illegal multibyte sequence

[Terry J. Reedy]

Terry J. Reedy added the comment:

So, does there appear to be a Python bug to fix or should this be closed?

--

___
Python tracker 

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

[issue28288] Expose environment variable for Py_Py3kWarningFlag

[Benjamin Peterson]

Benjamin Peterson added the comment:

Yes, I suppose this falls under the general exemption in 2.x for -3
warning changes.

On Fri, Nov 25, 2016, at 09:13, Berker Peksag wrote:
> 
> Berker Peksag added the comment:
> 
> Roy's patch looks good to me in general. Benjamin, as the RM of 2.7, do
> you have any objections?
> 
> --
> nosy: +benjamin.peterson
> 
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue28739] PEP 498: docstrings as f-strings

[Guido van Rossum]

Guido van Rossum added the comment:

I don't really care that much, but I personally think that it would be more 
consistent (and a simpler rule) if *no* f-string (not even ones without 
substitutions) were to be allowed as docstrings.

In all other examples that Raymond shows it's the syntactic form that matters 
-- no on b-strings, yes on r-strings, yes on concatenation (using space), no on 
+, etc.

The language reference clearly defines f-strings as all strings with an 
f-prefix, and says that they *may* contain replacement fields.  So it's clear 
that an f-string without replacements is still an f-string, and it is still 
distinguished from other strings.  Hence I think it should not be allowed as a 
docstring.

(Also, what purpose could using the f-prefix for a docstring possibly have?  
All the other allowable combinations do have a use.)

--

___
Python tracker 

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

[issue28739] PEP 498: docstrings as f-strings

[Raymond Hettinger]

Raymond Hettinger added the comment:

[TJR]
> I think this issue should either be closed as 'not a bug' 
> or redefined as a doc issue.

I concur.  

FWIW, here are some comparisons.  
Not allowed:

   'Not counted as' + ' a docstring'
   'Not a docstring ' * 10
   b'Also not a docstring'

Allowed:

   'This is a ' 'docstring'
   r'This is a docstring'

--
nosy: +rhettinger

___
Python tracker 

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

[issue28804] file tell() report incorrect file position on Windows (but Linux is OK)

[Martin Panter]

Martin Panter added the comment:

Is this a duplicate of Issue 26016?

--
nosy: +martin.panter

___
Python tracker 

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

[issue28804] file tell() report incorrect file position on Windows (but Linux is OK)

[liugang]

liugang added the comment:

Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit 
(AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> f = open('e:\\1.txt')
>>> f.readline()
'1\n'
>>> f.tell()
340282367000166625996085689099021713410
>>> f.readline()
'2\n'
>>> f.tell()
340282367000166625996085689099021713412
>>>

--
title: file tell() report incorrect file position (Windows, Linux is OK) -> 
file tell() report incorrect file position on Windows (but Linux is OK)
Added file: http://bugs.python.org/file45649/1.txt

___
Python tracker 

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

[issue28804] file tell() report incorrect file position (Windows, Linux is OK)

[liugang]

New submission from liugang:

D:\Python35\python.exe "D:\PyCharm Community Edition 
2016.3\helpers\pydev\pydevconsole.py" 8871 8872
PyDev console: starting.
import sys; print('Python %s on %s' % (sys.version, sys.platform))
sys.path.extend(['C:\\Users\\liugang10\\PycharmProjects\\untitled', 
'C:/Users/liugang10/PycharmProjects/untitled'])
Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit 
(AMD64)] on win32
>>> f = open('e:\\1.txt')
>>> f.readline()
'1\n'
>>> f.tell()
340282367000166625996085689099021713410
>>> f.readline()
'2\n'
>>> f.tell()
340282367000166625996085689099021713412

--
assignee: terry.reedy
components: IDLE
files: 1.txt
messages: 281752
nosy: liugang10, terry.reedy
priority: normal
severity: normal
status: open
title: file tell() report incorrect file position (Windows, Linux is OK)
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file45648/1.txt

___
Python tracker 

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

[issue28758] UnicodeDecodeError: 'gbk' codec can't decode byte 0xab in position 74: illegal multibyte sequence

[Steve Dower]

Steve Dower added the comment:

For something as low level as os.popen you should read bytes and decode them 
manually with the correct encoding. If you use subprocess.Popen instead you can 
specify encoding="utf-8" in the call (on 3.6).

Unfortunately, it's a very bad idea to rely on the default encoding for 
inter-process communication, but it's also impossible for us to change the 
defaults without breaking existing code unnecessarily.

I'm not particularly aware of code-page 65001 itself being buggy, but there are 
certainly issues in the ANSI-mode console when you select it. On 3.6 we use the 
Unicode APIs directly for the console, but that has no impact on pipes or 
redirected handles, which is what this issue is encountering.

--

___
Python tracker 

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

[issue28777] Add asyncio.Queue __aiter__, __anext__ methods

[Guido van Rossum]

Guido van Rossum added the comment:

Also it's not clear that it's a good idea without more thought -- there's no 
way to end the loop on the producing side.

--

___
Python tracker 

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

[issue28777] Add asyncio.Queue __aiter__, __anext__ methods

[Guido van Rossum]

Guido van Rossum added the comment:

This should be an upstream PR first (GitHub.com/python/asyncio). Also, too late 
for 3.6.

--
versions:  -Python 3.5, Python 3.6

___
Python tracker 

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

[issue24339] iso6937 encoding missing

[John Helour]

John Helour added the comment:

@mdk

Big thanks for the checker.

>Looks like your implementation is missing some codepoints, like "\t":
>
>>>> >print("\t".encode(encoding='iso6937'))
> 
>[...]
>UnicodeError: encoding with 'iso6937' codec failed (UnicodeError: 
> Unacceptable utf-8 character)

The '\t'  character is undefined in the iso6937 table, like all chars within 
the range 0x00 - 0x1F. I don't know how to handle such input for conversion.

--

___
Python tracker 

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

[issue28788] ConfigParser should be able to write config to a given filename, not only into file object

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
title: Feature request: ConfigParser should be able to write config to a given 
filename, not only into file object -> ConfigParser should be able to write 
config to a given filename, not only into file object

___
Python tracker 

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

[issue28777] Add asyncio.Queue __aiter__, __anext__ methods

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
stage:  -> test needed
title: asinc iter queue -> Add asyncio.Queue __aiter__, __anext__ methods
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

[issue28763] Use en-dashes for ranges in docs

[Terry J. Reedy]

Terry J. Reedy added the comment:

I checked the patch with Rietveld and all the changes are '-' to '--' in 
numeric ranges in text. LGTM.

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

___
Python tracker 

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

[issue24339] iso6937 encoding missing

[John Helour]

John Helour added the comment:

PEP8 compliant, added missing codepoints, utf-8 to \u rewrited

--
Added file: http://bugs.python.org/file45647/iso6937.py

___
Python tracker 

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

[issue28758] UnicodeDecodeError: 'gbk' codec can't decode byte 0xab in position 74: illegal multibyte sequence

[Terry J. Reedy]

Terry J. Reedy added the comment:

I don't see what this has to do with Python.  Perhaps out Windows experts can, 
or can ask for more info.  The last I knew, code page 65001 was buggy, but that 
is not a Python issue.

--
components: +Windows
nosy: +paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware

___
Python tracker 

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

[issue28625] multiprocessing.Pool.imap swallows exceptions thrown by generators

[Davin Potts]

Davin Potts added the comment:

Closing this issue -- all further discussion moves to issue28699

--
resolution:  -> duplicate
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

[issue28696] imap from ThreadPool hangs by an exception in a generator function

[Davin Potts]

Davin Potts added the comment:

Closing this issue -- all further discussion moves to issue28699

--
resolution:  -> duplicate
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

[issue28699] Imap from ThreadPool behaves unexpectedly

[Davin Potts]

Davin Potts added the comment:

Attaching promised crude tests.

--
Added file: http://bugs.python.org/file45646/issue_28699_repro.py

___
Python tracker 

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

[issue28699] Imap from ThreadPool behaves unexpectedly

[Davin Potts]

Davin Potts added the comment:

@xiang.zhang:  Nice catch -- thank you for pointing out the additional issue 
that arises when trying to provoke the issue twice in a row.

The module attribute `job_counter` helped, in this situation, point out what 
might have otherwise been overlooked.

I didn't like any of my previously suggested approaches, but I think there's a 
4th option:
4.  Guard against misbehaving generators/iterables *before* they are put into 
the taskqueue.


Now when we provide a problematic generator/iterable to imap, the exception it 
triggers is caught and the resulting exception passed through the system to 
make use of the logic that is already in place.

This same issue can arise for imap_unordered() as well as imap() and can be 
addressed in the same manner.


Attaching another preliminary patch that still lacks formal tests but I'll 
attach crude versions of tests momentarily.

If we're still missing some use case or other logic path, now's the time to 
find it.

--
Added file: 
http://bugs.python.org/file45645/issue_28699_guards_iterable_still_lacks_formal_test_py3x.patch

___
Python tracker 

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

[issue28739] PEP 498: docstrings as f-strings

[Terry J. Reedy]

Terry J. Reedy added the comment:

Much of this discussion seems to duplicate and effectively re-open of #25179, 
wherein it was decided/accepted that true, non-degenerate, non-trivial, 
non-constant, f-strings that actually do formatting are not constants and do 
not and should not become docstrings.  I agree.  I think this issue should 
either be closed as 'not a bug' or redefined as a doc issue.

It was noted by Martin P. in #25179 that "a constant f-string without any 
interpolations does become a doc string."  That is because such is really a 
string literal and not really an f-string, in the same sense that 'circle of 
radius 0' is really a point and not a circle.

The current glossary entry is

"docstring
A string literal which appears as the first expression in a class, function 
or module. While ignored when the suite is executed, it is recognized by the 
compiler and put into the __doc__ attribute of the enclosing class, function or 
module. Since it is available via introspection, it is the canonical place for 
documentation of the object."

I suggest adding "Bytestring literals and non-trivial f-strings do not become 
docstrings." as the second sentence.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue28518] execute("begin immediate") throwing OperationalError

[Big Stone]

Big Stone added the comment:

rewording of sqlite documentation:
http://www.sqlite.org/src/info/a4205a83e4ed977a

--

___
Python tracker 

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

[issue28518] execute("begin immediate") throwing OperationalError

[Big Stone]

Big Stone added the comment:

Comment kindly provided by D. Richard Hipp himself:
"
I don't have a login for the python bug tracker so I cannot comment
there.  But I think I see the problem.  This is as Aviv Polivoda
remarks at https://bugs.python.org/issue28518#msg279808

I think this is a error in sqlite as the documentation says:
"ransaction control statements such as BEGIN, COMMIT, ROLLBACK,
SAVEPOINT, and RELEASE cause sqlite3_stmt_readonly() to return true,"

Except it is not a bug in SQLite, but rather an ambiguity in the
documentation.  In his quote, Aviv omitted the second clause from the
documentation:  "since the statements themselves do not actually
modify the database but rather they control the timing of when other
statements modify the database."  (Full text here:
https://www.sqlite.org/c3ref/stmt_readonly.html)

For a plain BEGIN statement, there are no changes to the database
file, so sqlite3_stmt_readonly() does indeed return TRUE.  But for a
BEGIN IMMEDIATE statement, there are database changes, because the
extra IMMEDIATE keyword causes the statement to go ahead and start
transaction "immediately".

So technically, the documentation is correct, though I can certainly
understand that it is misleading and ambiguous as currently worded.
Clarification will be checked in shortly and will appear in the 3.16.0
release.

Note also that behavior of sqlite3_stmt_readonly() has not changed
since that interface was first added for the 3.7.5 release on
2011-02-01.  So this is not an SQLite regression.  Rather, I presume
that Python has recently started using the sqlite3_stmt_readonly()
interface in a new way.



--
D. Richard Hipp
d...@sqlite.org
"

--
nosy: +Big Stone

___
Python tracker 

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

[issue28288] Expose environment variable for Py_Py3kWarningFlag

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

PYTHON3WARNINGS looks as Python 3 variant of PYTHONWARNINGS.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue28781] On Installation of 3.5 Python get error message

[Steve Dower]

Steve Dower added the comment:

I was hoping that Repair wouldn't be an option after doing that cleaning. Maybe 
try uninstalling through Programs and Features, then run those commands again, 
go into the places you installed it and delete the files, and then run a fresh 
install.

If you still get the Modify/Repair/Uninstall page when you run the installer, 
keep doing Uninstall until you get back to the Install/Customize page.

--

___
Python tracker 

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

[issue28518] execute("begin immediate") throwing OperationalError

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Here is a patch that allows executing "begin immediate" explicitly with any 
isolation_level. I don't know what behavior is more preferable.

--
Added file: http://bugs.python.org/file45644/sqlite-explicit-begin.patch

___
Python tracker 

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

[issue28754] Argument Clinic for bisect.bisect_left

[Julien Palard]

Julien Palard added the comment:

Quoting @martin
> * bisect_right(a, x[, lo[, hi]]) -> index
> This signature is removed. I think removing it is reasonable, because pydoc 
> can extract the proper signature from the Arg Clinic metadata.

In fact, http://docs.python.org/howto/clinic.html, bullet ".4", told me do 
remove it:

> If the old docstring had a first line that looked like a function signature, 
> throw that line away. (The docstring doesn’t need it anymore—when you use 
> help() on your builtin in the future, the first line will be built 
> automatically based on the function’s signature.)


> * Additional descriptions of each parameter. I tend to think these are 
> redundant with the main text, so agree with removing them from the patch now.

OK, will remove them.

* Addition of full stop (.) at end of first paragraph. I suggested this as a 
minor cleanup, but it could be fixed later if you prefer.

Can remove it to simplify verification, but as doctests will be different as 
doc told me to remove the signature, so is it work removing this dot ? I don't 
think so.

* Removal of default values in last paragraph. The first is redundant with the 
Arg Clinic signature, so I suggested to remove it. For the second, I would add 
it back if we remove the list of parameters, since it explains what the special 
value -1 means.

I'll revert it too as I'll remove the documentation in the parameter list.

Will upload a patch later.

--

___
Python tracker 

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

[issue8145] Documentation about sqlite3 isolation_level

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
nosy:  -terry.reedy

___
Python tracker 

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

[issue28802] Python 3.6.0b4 Reports ncurses present in Cygwin but fails to build for cygwin

[Berker Peksag]

Changes by Berker Peksag :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Fix curses module compilation with ncurses6

___
Python tracker 

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

[issue28802] Python 3.6.0b4 Reports ncurses present in Cygwin but fails to build for cygwin

[Masayuki Yamamoto]

New submission from Masayuki Yamamoto:

We're discussing a cause of this issue at #25720.

--
nosy: +masamoto

___
Python tracker 

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

[issue28288] Expose environment variable for Py_Py3kWarningFlag

[Berker Peksag]

Berker Peksag added the comment:

Roy's patch looks good to me in general. Benjamin, as the RM of 2.7, do you 
have any objections?

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue28733] Show how to use mock_open in modules other that __main__

[Berker Peksag]

Berker Peksag added the comment:

Thanks for the report and for the patch. I think expanding the "Where to patch" 
[1] section would be better. We can then refer to it from the mock_open() 
documentation.


[1] https://docs.python.org/3.6/library/unittest.mock.html#where-to-patch

--
nosy: +berker.peksag, michael.foord
stage:  -> patch review
versions:  -Python 3.3, Python 3.4

___
Python tracker 

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

[issue28738] Document SIGBREAK as argument for signal() under Windows.

[Berker Peksag]

Berker Peksag added the comment:

Thanks for the report and for the patch, Wojtek!

--
nosy: +berker.peksag
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.5

___
Python tracker 

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

[issue28738] Document SIGBREAK as argument for signal() under Windows.

[Roundup Robot]

Roundup Robot added the comment:

New changeset dddce0f539dd by Berker Peksag in branch '3.5':
Issue #28738: Document SIGBREAK as an acceptable value on Windows
https://hg.python.org/cpython/rev/dddce0f539dd

New changeset 43856eb83dc1 by Berker Peksag in branch '3.6':
Issue #28738: Merge from 3.6
https://hg.python.org/cpython/rev/43856eb83dc1

New changeset 04eba322be92 by Berker Peksag in branch 'default':
Issue #28738: Merge from 3.6
https://hg.python.org/cpython/rev/04eba322be92

--
nosy: +python-dev

___
Python tracker 

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

[issue28795] Misleading stating, that SIGINT handler is installed by default

[Jan Velecký]

Jan Velecký added the comment:

That's good.

--

___
Python tracker 

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

[issue28801] configparser: before_get() method of class Interpolation has positional 'parser' parameter that is not used.

[R. David Murray]

Changes by R. David Murray :


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

[issue28786] Warnings in Misc/NEWS

[SilentGhost]

Changes by SilentGhost :


--
resolution:  -> out of date
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

[issue28689] OpenSSL 1.1.0c test failures

[Charalampos Stratakis]

Charalampos Stratakis added the comment:

Tested this in Fedora Rawhide virtual machine, where the fix for the 
problematic openssl commit was backported, and now the tests hang at 
test_poplib.

Exception in thread Thread-982:
Traceback (most recent call last):
  File "/home/harris/dev/cpython/_install/lib/python3.6/threading.py", line 
916, in _bootstrap_inner
self.run()
  File "/home/harris/dev/cpython/_install/lib/python3.6/test/test_poplib.py", 
line 222, in run
asyncore.loop(timeout=0.1, count=1)
  File "/home/harris/dev/cpython/_install/lib/python3.6/asyncore.py", line 207, 
in loop
poll_fun(timeout, map)
  File "/home/harris/dev/cpython/_install/lib/python3.6/asyncore.py", line 150, 
in poll
read(obj)
  File "/home/harris/dev/cpython/_install/lib/python3.6/asyncore.py", line 87, 
in read
obj.handle_error()
  File "/home/harris/dev/cpython/_install/lib/python3.6/asyncore.py", line 83, 
in read
obj.handle_read_event()
  File "/home/harris/dev/cpython/_install/lib/python3.6/asyncore.py", line 423, 
in handle_read_event
self.handle_read()
  File "/home/harris/dev/cpython/_install/lib/python3.6/test/test_poplib.py", 
line 192, in handle_read
asynchat.async_chat.handle_read(self)
  File "/home/harris/dev/cpython/_install/lib/python3.6/asynchat.py", line 121, 
in handle_read
self.handle_error()
  File "/home/harris/dev/cpython/_install/lib/python3.6/asynchat.py", line 117, 
in handle_read
data = self.recv(self.ac_in_buffer_size)
  File "/home/harris/dev/cpython/_install/lib/python3.6/asyncore.py", line 374, 
in recv
data = self.socket.recv(buffer_size)
  File "/home/harris/dev/cpython/_install/lib/python3.6/ssl.py", line 987, in 
recv
return self.read(buflen)
  File "/home/harris/dev/cpython/_install/lib/python3.6/ssl.py", line 865, in 
read
return self._sslobj.read(len, buffer)
  File "/home/harris/dev/cpython/_install/lib/python3.6/ssl.py", line 627, in 
read
v = self._sslobj.read(len)
OSError: [Errno 0] Error

--

___
Python tracker 

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

[issue28803] Python 3.6.0b4 Reports ncurses present in Cygwin but fails to build for Cygwin

[Berker Peksag]

Changes by Berker Peksag :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Python 3.6.0b4 Reports ncurses present in Cygwin but fails to 
build for cygwin

___
Python tracker 

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

[issue28803] Python 3.6.0b4 Reports ncurses present in Cygwin but fails to build for Cygwin

[Richard S. Gordon]

Changes by Richard S. Gordon :


--
components: Build
nosy: rigordo
priority: normal
severity: normal
status: open
title: Python 3.6.0b4 Reports ncurses present in Cygwin but fails to build for 
Cygwin
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

[issue28796] FIX warnings in documentation build

[Roundup Robot]

Roundup Robot added the comment:

New changeset f16f0500b49b by Berker Peksag in branch 'default':
Issue #28796: Silence Sphinx warnings
https://hg.python.org/cpython/rev/f16f0500b49b

--
nosy: +python-dev

___
Python tracker 

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

[issue28796] FIX warnings in documentation build

[Berker Peksag]

Berker Peksag added the comment:

Thanks!

--
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior

___
Python tracker 

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

[issue28518] execute("begin immediate") throwing OperationalError

[Aviv Palivoda]

Aviv Palivoda added the comment:

There are already a few test's that start a transaction explicitly:

In dbapi.SqliteOnConflictTests CheckOnConflictRollbackWithExplicitTransaction, 
CheckOnConflictAbortRaisesWithExplicitTransactions which set ``isolation_level 
= None``.

On the other hand in transaction.TransactionalDDL.CheckTransactionalDDL the 
test do not set the isolation_level to None but start a transaction explicitly. 
The test pass because sqlite3_stmt_readonly return true for "begin" and "begin 
deferred".

I think that if we say that in order to start a transaction implicitly the 
isolation_level needs to be None CheckTransactionalDDL should be changed.

--

___
Python tracker 

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

[issue28802] Python 3.6.0b4 Reports ncurses present in Cygwin but fails to build for cygwin

[Richard s. Gordon]

Changes by Richard s. Gordon :


--
nosy: eclectic9509
priority: normal
severity: normal
status: open
title: Python 3.6.0b4 Reports ncurses present in Cygwin but fails to build for 
cygwin

___
Python tracker 

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

[issue28793] Copy-paste error in collections.abc docs for AsyncGenerator

[Berker Peksag]

Berker Peksag added the comment:

Thanks!

--
assignee:  -> docs@python
components: +Documentation
nosy: +berker.peksag, docs@python
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior

___
Python tracker 

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

[issue28793] Copy-paste error in collections.abc docs for AsyncGenerator

[Roundup Robot]

Roundup Robot added the comment:

New changeset 078c037b1571 by Berker Peksag in branch '3.6':
Issue #28793: Fix c/p error in AsyncGenerator documentation
https://hg.python.org/cpython/rev/078c037b1571

New changeset 0bf7c2d99bf1 by Berker Peksag in branch 'default':
Issue #28793: Merge from 3.6
https://hg.python.org/cpython/rev/0bf7c2d99bf1

--
nosy: +python-dev

___
Python tracker 

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

[issue28673] pyro4 with more than 15 threads often crashes 2.7.12

[STINNER Victor]

STINNER Victor added the comment:

> I suggest thread_PyThread_start_new_thread() raise RuntimeError("can't start 
> thread: finalizing")

Where *exactly*? Py_FinalizeEx() first calls
wait_for_thread_shutdown() and *then* sets _Py_Finalizing to tstate.

Does wait_for_thread_shutdown() complete on this bug?

Note: It's not the first time that I noticed a deadlock around this
code :-/ I recall a silly bug when you press CTRL+c while
wait_for_thread_shutdown() is running.

See for example threading_shutdown_interrupted.py attached to the
issue #20526. Run it and quickly press CTRL+c. Sometime, it does crash
Python with a segfault...
---
haypo@selma$ ./python threading_shutdown_interrupted.py
..Exception
ignored in: 
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/threading.py", line 1290,
in _shutdown
t.join()
  File "/home/haypo/prog/python/default/Lib/threading.py", line 1056, in join
.self._wait_for_tstate_lock()
  File "/home/haypo/prog/python/default/Lib/threading.py", line 1072,
in _wait_for_tstate_lock
...elif lock.acquire(block, timeout):
  File "threading_shutdown_interrupted.py", line 29, in killer
..raise KeyboardInterrupt()
KeyboardInterrupt:
^CSegmentation fault (core dumped)
---

Python finalization is a very fragile and complex task :-/

--

___
Python tracker 

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

[issue28800] Add RETURN_NONE bytecode instruction

[STINNER Victor]

STINNER Victor added the comment:

> Do you want to add RETURN_NONE or RETURN_CONST? Or both?

Only RETURN_NONE because on some corner cases it allow to avoid completely the 
None constant from code.co_consts and reduce the stack size.

I'm not sure that I want to start taking the same road of WPython which added a 
*lot* of specialized instructions (combining two or more existing 
instructions). As you said, it has a cost on the maintenance, and might have a 
negative impact if _PyEval_EvalFrameDefault() becomes too big.

--

___
Python tracker 

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

[issue28800] Add RETURN_NONE bytecode instruction

[STINNER Victor]

STINNER Victor added the comment:

Results of performance 0.5.0 on speed-python:

haypo@speed-python$ python3 -m perf compare_to -G --min-speed=3 
2016-11-23_19-34-default-3d660ed2a60e.json patch.json 
Slower (3):
- spectral_norm: 265 ms +- 2 ms -> 277 ms +- 7 ms: 1.04x slower
- xml_etree_iterparse: 217 ms +- 2 ms -> 226 ms +- 4 ms: 1.04x slower
- nqueens: 261 ms +- 2 ms -> 269 ms +- 3 ms: 1.03x slower

Faster (3):
- scimark_sor: 519 ms +- 10 ms -> 496 ms +- 7 ms: 1.05x faster
- mako: 43.0 ms +- 0.8 ms -> 41.5 ms +- 0.2 ms: 1.04x faster
- call_method: 16.2 ms +- 0.2 ms -> 15.7 ms +- 0.3 ms: 1.03x faster

Benchmark hidden because not significant (58): 2to3, call_method_slots, 
call_method_unknown, (...)


Hum, boring result. This change alone doesn't change any significant speedup, 
even some slowndon. Maybe it's just a bad idea. Maybe it should be combined 
with other new bytecode instructions. Maybe only a full new instruction set 
using registers show significant speedup. 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

[issue28673] pyro4 with more than 15 threads often crashes 2.7.12

[INADA Naoki]

INADA Naoki added the comment:

This script can cause deadlock on Python 3.6.

1. Other threads can register traceback to sys module after sys module dict is 
cleaned up.
2. In Py_Finalize, __del__ method of arbitrary object in the traceback can be 
called.
3. The __del__ method calls threading.Thread.start()
4. Thread.start() waits self.__started event which is set by Thread.__bootstrap
5. While finalizing, threads other than main thread exits when getting GIL. So 
Thread.__bootstrap() won't be called.
6. Thread.start() in main thread waits self.__started event forever.

I suggest thread_PyThread_start_new_thread() raise RuntimeError("can't start 
thread: finalizing")

--
Added file: http://bugs.python.org/file45643/finish-deadlock.py

___
Python tracker 

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

[issue28754] Argument Clinic for bisect.bisect_left

[Martin Panter]

Martin Panter added the comment:

Taking the first function, bisect_right(), as an example, I see these 
differences:

* bisect_right(a, x[, lo[, hi]]) -> index
This signature is removed. I think removing it is reasonable, because pydoc can 
extract the proper signature from the Arg Clinic metadata.

* Additional descriptions of each parameter. I tend to think these are 
redundant with the main text, so agree with removing them from the patch now.

* Addition of full stop (.) at end of first paragraph. I suggested this as a 
minor cleanup, but it could be fixed later if you prefer.

* Removal of default values in last paragraph. The first is redundant with the 
Arg Clinic signature, so I suggested to remove it. For the second, I would add 
it back if we remove the list of parameters, since it explains what the special 
value -1 means.

Do you want to revert all these differences?

--

___
Python tracker 

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

[issue8145] Documentation about sqlite3 isolation_level

[Florian Schulze]

Florian Schulze added the comment:

The documentation patch is a definite improvement.

--
nosy: +fschulze

___
Python tracker 

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

[issue28801] configparser: before_get() method of class Interpolation has positional 'parser' parameter that is not used.

[Wolfgang Maier]

Wolfgang Maier added the comment:

> Ah. Something like self._interpolation.before_get(self, section, option, 
> value, d) could be better written as 
> self._interpolation.before_get(parser=self, ...)

Yep, that's roughly what I was trying to explain.

> I still don't grock the apparent 'get()' signature mis-match however.

There is not much special here either. RawConfigParser inherits from 
MutableMapping, which in turn inherits from Mapping, which defines a get 
method, which RawConfigParser overwrites. The overwritten and the overwriting 
method *do* have different parameters, but I don't see why that matters.

In general, this does not look like a topic for the Python bug tracker (you are 
not reporting a bug, but you try to understand how correctly working code does 
its job), but rather for news:comp.lang.python or a PyCharm mailing list.

--

___
Python tracker 

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

[issue28785] Clarify the behavior of NotImplemented

[Martin Panter]

Martin Panter added the comment:

Correct, I meant to say the first fallback is the other call.

BTW your suggested text might hold for __eq__(), but for __ne__(), returning 
NotImplemented seems to bypass the “not a.__eq__(b)” fallback.

--

___
Python tracker 

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

[issue28754] Argument Clinic for bisect.bisect_left

[STINNER Victor]

STINNER Victor added the comment:

Martin: "Victor, what changes to the doc strings are you talking about?"

See attached check_bisect_doc.py script.

Before:
---
=== bisect_right ===
bisect_right(a, x[, lo[, hi]]) -> index

Return the index where to insert item x in list a, assuming a is sorted.

The return value i is such that all e in a[:i] have e <= x, and all e in
a[i:] have e > x.  So if x already appears in the list, i points just
beyond the rightmost x already there

Optional args lo (default 0) and hi (default len(a)) bound the
slice of a to be searched.

=== insort_right ===
insort_right(a, x[, lo[, hi]])

Insert item x in list a, and keep it sorted assuming a is sorted.

If x is already in a, insert it to the right of the rightmost x.

Optional args lo (default 0) and hi (default len(a)) bound the
slice of a to be searched.

=== bisect_left ===
bisect_left(a, x[, lo[, hi]]) -> index

Return the index where to insert item x in list a, assuming a is sorted.

The return value i is such that all e in a[:i] have e < x, and all e in
a[i:] have e >= x.  So if x already appears in the list, i points just
before the leftmost x already there.

Optional args lo (default 0) and hi (default len(a)) bound the
slice of a to be searched.

=== insort_left ===
insort_left(a, x[, lo[, hi]])

Insert item x in list a, and keep it sorted assuming a is sorted.

If x is already in a, insert it to the left of the leftmost x.

Optional args lo (default 0) and hi (default len(a)) bound the
slice of a to be searched.

---

After:
---
=== bisect_right ===
Return the index where to insert item x in list a, assuming a is sorted.

  a
The list in which x is to be inserted.
  x
The value to be inserted.
  lo
Lower bound, defaults to 0.
  hi
Upper bound, defaults to -1 (meaning len(a)).

The return value i is such that all e in a[:i] have e <= x, and all e in
a[i:] have e > x.  So if x already appears in the list, i points just
beyond the rightmost x already there.

Optional args lo and hi bound the slice of a to be searched.
=== insort_right ===
Insert item x in list a, and keep it sorted assuming a is sorted.

  a
The list in which x will be inserted.
  x
The value to insert.
  lo
Lower bound, defaults to 0.
  hi
Upper bound, defaults to -1 (meaning len(a)).

If x is already in a, insert it to the right of the rightmost x.

Optional args lo and hi bound the slice of a to be searched.
=== bisect_left ===
Return the index where to insert item x in list a, assuming a is sorted.

  a
The list in which x is to be inserted.
  x
The value to be inserted.
  lo
Lower bound, defaults to 0.
  hi
Upper bound, defaults to -1 (meaning len(a)).

The return value i is such that all e in a[:i] have e < x, and all e in
a[i:] have e >= x.  So if x already appears in the list, i points just
before the leftmost x already there.

Optional args lo and hi bound the slice of a to be searched.
=== insort_left ===
Insert item x in list a, and keep it sorted assuming a is sorted.

  a
The list in which x will be inserted.
  x
The value to insert.
  lo
Lower bound, defaults to 0.
  hi
Upper bound, defaults to -1 (meaning len(a)).

If x is already in a, insert it to the left of the leftmost x.

Optional args lo and hi bound the slice of a to be searched.

---

The output is different. I suggest to not touch the docstring in the patch 
upgrading _bisect.c to Argument Clinic to ease the review.

--
Added file: http://bugs.python.org/file45642/check_bisect_doc.py

___
Python tracker 

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

[issue28754] Argument Clinic for bisect.bisect_left

[Martin Panter]

Martin Panter added the comment:

Victor, what changes to the doc strings are you talking about? Adding 
descriptions of the parameters, maybe? Other than that they look very similar 
to me.

I haven’t looked closely, but the Python doc strings have been updated at least 
once more than the C doc strings: r54666 and Issue 1602378. So if you are 
copying anything, it might be better to copy from Py to C. But I would do that 
separately.

The doc strings and reference documentation just seem to have been added 
independently: ce2d120c3903 (main documentation) vs 67b3ac439f64 (doc strings)

--
nosy: +martin.panter

___
Python tracker 

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

[issue28801] configparser: before_get() method of class Interpolation has positional 'parser' parameter that is not used.

[Richard Prosser]

Richard Prosser added the comment:

Ah. Something like self._interpolation.before_get(self, section, option, value, 
d) could be better written as self._interpolation.before_get(parser=self, ...) 
- but that would require keyword arguments to be used throughout.

I still don't grock the apparent 'get()' signature mis-match however.

--

___
Python tracker 

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

[issue8145] Documentation about sqlite3 isolation_level

[Berker Peksag]

Berker Peksag added the comment:

The patch needs to be updated to address changes in issue 10740 so I'm moving 
the stage field back to 'patch review'.

--
stage: commit review -> patch review
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

[issue28518] execute("begin immediate") throwing OperationalError

[Berker Peksag]

Berker Peksag added the comment:

There is a patch in issue 8145 to improve that part of the documentation. It 
would be great if you could take a look at it :)

--

___
Python tracker 

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

[issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function

[STINNER Victor]

STINNER Victor added the comment:

I guess that the main question is if all platforms supported by Python do 
support intmax_t?

--

___
Python tracker 

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

[issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function

[STINNER Victor]

STINNER Victor added the comment:

intmax_t-4.patch is a single combined patch for Mercurial. To see individual 
changes, see the GitHub pull request:
https://github.com/python/cpython/pull/46/commits

--

___
Python tracker 

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

[issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function

[STINNER Victor]

STINNER Victor added the comment:

New attempt to support C intmax_t type, since Python 3.6 now supports a subset 
of C99: intmax_t-4.patch. Changes:

Add support for C intmax_t type:

Add new conversions functions for PyLong:
PyLong_FromIntMax()
PyLong_FromUIntMax()
PyLong_AsIntMax()
PyLong_AsIntMaxAndOverflow()
PyLong_AsUIntMax()

getargs: add 'm' format

New _testcapi constants: INTMAX_MAX, INTMAX_MIN, UINTMAX_MAX, 
SIZEOF_INTMAX_T

Add _testcapi.getargs_m() and _testcapi.test_long_intmax_api()

PyLong_FromVoidPtr() uses PyLong_FromUIntMax()

Use intmax_t in various modules

array, struct, ctypes and memoryview are not modified yet to support intmax_t.

--

To ease the review of this large patch, I created a GitHub pull request: 
https://github.com/python/cpython/pull/46

--
Added file: http://bugs.python.org/file45641/intmax_t-4.patch

___
Python tracker 

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

[issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue28801] configparser: before_get() method of class Interpolation has positional 'parser' parameter that is not used.

[Richard Prosser]

Richard Prosser added the comment:

Thanks for the prompt reply. I still don't fully understand yet but there 
aren't any errors reported so I presume that it is OK.

There is another related matter however: PyCharm (2016.2.3) indicates that a 
get() method signature does not match that of the Mapping class one ...

557
558class RawConfigParser(MutableMapping):

761
762def get(self, section, option, *, raw=False, vars=None, fallback=_UNSET):


There are other similar cases I believe.

So I am not sure what to make of that, either.

--
hgrepos: +363

___
Python tracker 

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

[issue28518] execute("begin immediate") throwing OperationalError

[Florian Schulze]

Florian Schulze added the comment:

Ok, I reread 
https://docs.python.org/3/library/sqlite3.html#controlling-transactions several 
times now. I think it's confusing.

I want explicit transaction handling, but ``isolation_level = None`` turns on 
"autocommit mode". Unfortunately I don't have suggestions on how to improve the 
documentation.

For us, ``isolation_level = None`` and the explicit ``begin immediate`` seems 
to be the correct way and it works with all Python versions, including 3.6.0.

So, I would say this is "not a bug" in Python, but my understanding of the 
sqlite3 module is flawed. The documentation could be better, but I don't know 
how to make it better.

--

___
Python tracker 

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

[issue22298] Lib/warnings.py _show_warning does not protect against being called with a file like object which is closed

[Terry J. Reedy]

Terry J. Reedy added the comment:

In 3.6, the code in question is

def _showwarnmsg_impl(msg):
file = msg.file
if file is None:
file = sys.stderr
if file is None:
# sys.stderr is None when run with pythonw.exe:
# warnings get lost
return
text = _formatwarnmsg(msg)
try:
file.write(text)
except OSError:
# the file (probably stderr) is invalid - this warning gets lost.
pass

When the write is attempted, *file* is not None.  It can either be sys.stderr 
or something else, successfully opened.  If writing to sys.stderr fails, we 
properly should give up.

If writing to something else fails, I now think we should try to write an 
exception to stderr.  So I thing the bug here, if any, is unconditionally 
passing.  Perhaps the exception clause should be replaced (in a new issue) with 
something like

 except (OSError, ValueError):
if msg.file is not sys.stderr:
raise

--
resolution:  -> not a bug
stage: test needed -> 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

[issue28800] Add RETURN_NONE bytecode instruction

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Do you want to add RETURN_NONE or RETURN_CONST? Or both?

Adding new special opcodes can decrease the size of the code and increase 
performance of some cases. But it adds maintenance burden, increases the 
complexity of the compiler and peephole optimizer, and increases the size of 
ceval loop. The latter can have negative effect on the performance. I think we 
should add new specialized opcodes only if they adds measurable gain to global 
performance or large speed up of important particular cases.

It would help if you gather the statistics of RETURN_* opcodes. How many 
RETURN_VALUE, RETURN_CONST and RETURN_NONE instructions are compiled and 
executed during running Python tests? Compare it with total number of compiled 
and executed instructions.

--

___
Python tracker 

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

[issue28518] execute("begin immediate") throwing OperationalError

[Berker Peksag]

Berker Peksag added the comment:

I haven't had a time to investigate this yet, but I don't think there is an 
issue with SQLite itself.

Note that pysqlite behaves the same way since version 2.8.0 and I couldn't find 
a similar report in their issue tracker.

Like Serhiy, I'm also a little puzzled with the reproducer. I think if you want 
to start an explicit transaction, the preferred way would be to set 
isolation_level to None. Otherwise, the sqlite3 module will start one 
implicitly for you (or perhaps I still don't understand PEP 249's transaction 
model 100% correctly :))

(If we decide that this is not a regression, we should add a test case to cover 
this use case.)

--

___
Python tracker 

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

[issue28801] configparser: before_get() method of class Interpolation has positional 'parser' parameter that is not used.

[Wolfgang Maier]

Wolfgang Maier added the comment:

Ah, that's kind of confusing at first!

the 'self' in the method calls (like on line 796) refers to the ConfigParser 
instance and will be bound to the parser parameter. The first parameter, the 
'self' in the interpolation method definition, is not provided as usual because 
the method is called on an _interpolation instance. => Nothing special here 
except the names of the arguments

--
nosy: +wolma
type: compile error -> 

___
Python tracker 

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

[issue28800] Add RETURN_NONE bytecode instruction

[STINNER Victor]

STINNER Victor added the comment:

I'm proposing this patch because I noticed that reducing the number of opcodes 
makes Python faster in my old registervm project: a fork of CPython which uses 
a register-based bytecode:
http://faster-cpython.readthedocs.io/registervm.html

I also plan to propose a CALL_PROCEDURE method to replace 
CALL_FUNCTION+POP_TOP. Only for the the simple CALL_FUNCTION, not for complex 
CALL_FUNCTION_KW nor CALL_FUNCTION_EX.

--

___
Python tracker 

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

[issue22298] Lib/warnings.py _show_warning does not protect against being called with a file like object which is closed

[Julius Lehmann-Richter]

Julius Lehmann-Richter added the comment:

Hey Wolfgang,

thank you for the clarification.

I would never write such code of course, I stumbled across this with a 
third-party program.

I understand your point of view and I actually agree. I would not have even 
opened this report if it had not been for that comment.

If the error is still reproducable in the software I will open a bug with them 
instead and tell them to please fix it :P

As far as I am concerned this is not a bug (any more)

Cheers Julius

--

___
Python tracker 

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

[issue28800] Add RETURN_NONE bytecode instruction

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
components: +Interpreter Core
nosy: +rhettinger
stage:  -> patch review
type:  -> enhancement

___
Python tracker 

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

[issue28801] configparser: before_get() method of class Interpolation has positional 'parser' parameter that is not used.

[Richard Prosser]

New submission from Richard Prosser:

>From https://hg.python.org/cpython/file/3.5/Lib/configparser.py (for example):

358class Interpolation:
359"""Dummy interpolation that passes the value through with no changes."""
360
361def before_get(self, parser, section, option, value, defaults):
362return value

but a typical invocation misses out the 'parser' parameter:

796return self._interpolation.before_get(self, section, option, 
value,
797  d)

As far as I can see, this is not a keyword-only parameter, yet PyCharm seems to 
treat it as one. So maybe this is some new behaviour that I don't understand 
yet but there seems to be a fault here, IMO.

I am using Python 3.5.2 on Windows 7, after using the 'futurize' tool on some 
legacy 2.7 code that extended self._interpolate (which no longer exists in 3+).

--
hgrepos: 362
messages: 281697
nosy: rprosser
priority: normal
severity: normal
status: open
title: configparser: before_get() method of class Interpolation has positional 
'parser' parameter that is not used.
type: compile error
versions: Python 3.5

___
Python tracker 

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

[issue28800] Add RETURN_NONE

[STINNER Victor]

New submission from STINNER Victor:

Attached patch adds a new bytecode instruction: RETURN_NONE. It is similar to 
"LOAD_CONST; RETURN_VALUE" but it avoids the need of adding None to constants 
of the code object. For function with an empty body, it reduces the stack size 
from 1 to 0.


Example on reference Python 3.7:

>>> def func(): return
... 
>>> import dis; dis.dis(func)
  1   0 LOAD_CONST   0 (None)
  2 RETURN_VALUE
>>> func.__code__.co_stacksize
1



Example on patched Python 3.7:

>>> def func(): return
... 
>>> import dis; dis.dis(func)
  1   0 RETURN_CONST
>>> func.__code__.co_stacksize
0


If the function has a docstring, RETURN_CONST avoids adding None to code 
constants:

>>> def func():
...  "docstring"
...  return
... 
>>> func.__code__.co_consts
('docstring',)


I will now run benchmarks on the patch.

--
files: return_none.patch
keywords: patch
messages: 281696
nosy: haypo, matrixise, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add RETURN_NONE
versions: Python 3.7
Added file: http://bugs.python.org/file45640/return_none.patch

___
Python tracker 

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

[issue28800] Add RETURN_NONE bytecode instruction

[STINNER Victor]

Changes by STINNER Victor :


--
title: Add RETURN_NONE -> Add RETURN_NONE bytecode instruction

___
Python tracker 

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

[issue28782] SEGFAULT when running a given coroutine

[STINNER Victor]

STINNER Victor added the comment:

Martin Richard: "Thank you all for fixing this so quickly, it's been done 
amazingly fast!"

Even if I didn't write the commit a77756e480c2 which introduced the regression, 
I pushed it and so I felt responsible. It's a good motivation to fix it 
quickly. So nobody notice :-D

--

___
Python tracker 

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

[issue28782] SEGFAULT when running a given coroutine

[Martin Richard]

Martin Richard added the comment:

Thank you all for fixing this so quickly, it's been done amazingly fast!

--

___
Python tracker 

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

[issue22298] Lib/warnings.py _show_warning does not protect against being called with a file like object which is closed

[Wolfgang Maier]

Wolfgang Maier added the comment:

Ah, I just found Issue607668, which discusses the changeset 2e7fe55c0e11 that 
introduced IOError suppression. The actual use case at the time was different 
and I have no idea whether it would still be a problem today.

--

___
Python tracker 

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

[issue22298] Lib/warnings.py _show_warning does not protect against being called with a file like object which is closed

[Wolfgang Maier]

Wolfgang Maier added the comment:

Hi Julius,

I guess it's a question of control and responsibilities.
If you write a program that may issue warnings under some conditions, that 
program may, for example, be used with stderr redirected to a file. Now it is 
possible that file gets removed while your program is running, then, upon the 
next warning, the program would crash with an IOError. In effect, this would 
let external cirumstances that are not under control by the programmer escalate 
a non-critical warning message to a true exception. It's debatable whether that 
should be prevented or not, but that seems to be the decision that Mark Hammond 
made long ago.
If, OTOH, your program chooses to close sys.stderr, that is a deliberate 
decision and it's the programmers responsibility then not to try to write to it 
anymore. Suppressing the resulting ValueError would only hide the fact that due 
to a programming error no warnings can be issued anymore.
Not sure if this makes any sense to you or others, but that's how I came to 
think about this.

--

___
Python tracker 

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

[issue28518] execute("begin immediate") throwing OperationalError

[Aviv Palivoda]

Aviv Palivoda added the comment:

I searched in the sqlite tickets from something related to this issue and I 
couldn't find anything. I wanted to check the sqlite-users mailing list to see 
if anyone had already reported it but there is a problem in gmane archives.

I tried to find a good way to solve this problem but I couldn't. I am adding a 
patch that should solve this problem but it is for sure not a good way :(.

--
keywords: +patch
Added file: http://bugs.python.org/file45639/28518.patch

___
Python tracker 

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

[issue22298] Lib/warnings.py _show_warning does not protect against being called with a file like object which is closed

[Julius Lehmann-Richter]

Julius Lehmann-Richter added the comment:

Hey Wolfgang,

thank you for looking into this old one again ;)

The argument you are making does not answer the original bug report though as 
far as I can see.

My initial problem was not the AttributeError about the missing write but a 
ValueError (I/O operation on closed file).

Also this seems to have started a discussion about good programming practice 
between Terry and Antoine, my initial argument though was that, when you are 
catching an IOError for an invalid file, why not catch the ValueError for the 
closed file (since a closed file is surely not a valid target for a write 
operation).

I would really like to be educated on this if I am missing something, why does 
the argument for not silencing errors and expecting good programming practice 
apply to the ValueError of a closed standard error which has not been set to 
None but not to an IOError of a passed in file object?

Cheers Julius

--

___
Python tracker 

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

[issue28781] On Installation of 3.5 Python get error message

[Mark Harris]

Mark Harris added the comment:

Hi Steve,

Thanks looking into this for me. I tried the below and ran the lines in cmd 
with admin privileges. Then I tried running repair again. I'm afraid when I 
type python in the command prompt it has the same message as before about 
missing python35.dll. 

I know you said that not all the commands would work, however when I ran "reg 
delete HKLM\Software\Python\PythonCore\3.5-32\InstalledFeatures /f /reg:32" it 
couldn't find the file. I don't know if that helps at all.

If you wanted to know how I caused this issue, I was having problems getting 
pip to work, so tried re-installing a few times(clicking generic user a few 
times in installation), into various locations, thinking it was something to do 
with the PATH. It didn't seem to be updating the path in the installation.

Hence why it's a bit of a mess! Any suggestions on further cleaning I could do?

Thanks again for all your help on this.

--

___
Python tracker 

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

[issue12844] Support more than 255 arguments

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

No longer changes to Python/compile.c are needed. Here is a patch against 3.7 
that just removes the limit of the number of passed arguments in Python/ast.c 
and adds tests.

But still there is a limitation on the number of function parameters. It is 
caused by using a bytes objects as co_cell2arg.

--
stage:  -> patch review
versions: +Python 3.7
Added file: http://bugs.python.org/file45638/no-args-limit.patch

___
Python tracker 

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

[issue28799] Drop CALL_PROFILE special build?

[STINNER Victor]

Changes by STINNER Victor :


--
keywords: +patch
Added file: http://bugs.python.org/file45637/remove_call_profile.patch

___
Python tracker 

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

[issue28799] Drop CALL_PROFILE special build?

[STINNER Victor]

New submission from STINNER Victor:

Python/ceval.c contains conditional code to compute statistics on function 
calls when CALL_PROFILE is defined.

Extract of Misc/SpecialBuilds.txt:

CALL_PROFILE


Count the number of function calls executed.

When this symbol is defined, the ceval mainloop and
helper functions count the number of function calls
made.  It keeps detailed statistics about what kind of
object was called and whether the call hit any of the
special fast paths in the code.

Statistics can later be collected by sys.callstats().

I'm unable to find any unit test on this feature. The feature was added in 
Python 2.3.1 by the changeset 16856c9514e0 in 2003:
---
changeset:   27712:16856c9514e0
branch:  legacy-trunk
user:Jeremy Hylton 
date:Wed Feb 05 23:13:00 2003 +
files:   Include/ceval.h Include/compile.h Misc/SpecialBuilds.txt 
Python/ceval.c Python/compile.c Python/sysmodule.c
description:
Small function call optimization and special build option for call stats.

-DCALL_PROFILE: Count the number of function calls executed.

When this symbol is defined, the ceval mainloop and helper functions
count the number of function calls made.  It keeps detailed statistics
about what kind of object was called and whether the call hit any of
the special fast paths in the code.

Optimization:

When we take the fast_function() path, which seems to be taken for
most function calls, and there is minimal frame setup to do, avoid
call PyEval_EvalCodeEx().  The eval code ex function does a lot of
work to handle keywords args and star args, free variables,
generators, etc.  The inlined version simply allocates the frame and
copies the arguments values into the frame.

The optimization gets a little help from compile.c which adds a
CO_NOFREE flag to code objects that don't have free variables or cell
variables.  This change allows fast_function() to get into the fast
path with fewer tests.

I measure a couple of percent speedup in pystone with this change, but
there's surely more that can be done.
---

The changeset adds an optimization using CO_NOFREE and the CALL_PROFILE feature.

My problem is that with my work on FASTCALL, it became harder to track where 
the functions are called in practice. It maybe out of the Python/ceval.c file. 
I'm not sure that statistics are still computed correctly after my FASTCALL 
changes, and I don't know how to check it.

Python has already sys.setprofile(), cProfile and profile modules. There is 
also sys.settrace(). Do we still need CALL_PROFILE?

Attached patch removes the feature:

* Calling the the untested and undocumented sys.callstats() function now emits 
a DeprecationWarning warning
* Remove the PyEval_GetCallStats() function and its documentation

PyEval_GetCallStats() seems to be part of the stable API, but I don't expect 
that anyone uses it outside the CPython source code since it requires to 
rebuild CPython with a special build flag (-D CALL_PROFILE).

--
messages: 281687
nosy: haypo
priority: normal
severity: normal
status: open
title: Drop CALL_PROFILE special build?
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

[issue15533] subprocess.Popen(cwd) documentation

[Wolfgang Maier]

Wolfgang Maier added the comment:

Before I forget again what I've gathered yesterday about this issue, here's a 
summary of the problem:

When the the first element of args or the executable argument of 
subprocess.Popen does not specify an absolute path, the way the executable gets 
discovered is platform-dependent.
On POSIX platforms, if the argument contains a directory part, the executable 
gets looked for relative to the current working directory. If the argument is 
just a basename, the PATH is searched.
On Windows, the executable argument and the first element of args are treated 
in different ways: If the executable is specified through the executable 
argument, it is always looked for relative to the current working directory 
only, but if it's specified through args, it's searched for using 
Windows-specific rules as documented for the underlying CreateProcess function 
(see 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx).

Now, on top of all this, if the cwd argument of Popen is used, then, in Python3 
on POSIX-platforms, the current working directory gets changed to cwd *before* 
the above interpretation happens, i.e., if executable or args[0] contains a 
dirname, the executable is looked for relative to cwd.
On Windows, however, cwd becomes the current working directory of the new 
process, but is *not* used during the executable lookup.

I guess with this being rather complicated it would be nice to have a dedicated 
section explaining the interpretation of relative paths as arguments instead of 
trying to get only the cwd wording right.

--
components: +Library (Lib)
type:  -> behavior

___
Python tracker 

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

[issue28754] Argument Clinic for bisect.bisect_left

[STINNER Victor]

STINNER Victor added the comment:

issue28754-4.diff does 3 things:
* convert C code to Argument Clinic
* change docstrings of the C code
* change unit tests

issue28754-5.diff doesn't touch tests, but still does 2 things. Sadly, I 
dislike the changes on docstrings because it makes the C docstring and the 
Python docstring inconsistent.

I suggest to copy/paste docstring between C and Python code.

By the way, why do we have a docstring different from Doc/library/bisect.rst? 
Maybe we can simply use the same doc everywhere, but just add reST formatting 
in Doc/library/bisect.rst?

Julien: I suggest to first restrict your change to Argument Clinic, and later 
write a new patch to update docstrings. I prefer to only do one thing per 
commit.

--

___
Python tracker 

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

[issue28772] Bus error in Python 3.6.0beta

[SilentGhost]

Changes by SilentGhost :


--
resolution: not a bug -> third party
stage:  -> resolved

___
Python tracker 

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

[issue28753] Clinic: Converting Your First Function is not up to date

[STINNER Victor]

STINNER Victor added the comment:

issue28753.fastcall.diff LGTM.

--

___
Python tracker 

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