[issue36946] Possible signed integer overflow in slice handling

2019-05-16 Thread Zackery Spytz


Change by Zackery Spytz :


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

___
Python tracker 

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



[issue36946] Possible signed integer overflow in slice handling

2019-05-16 Thread Zackery Spytz


New submission from Zackery Spytz :

Python 3.8.0a4+ (heads/master:870b035bc6, May 16 2019, 20:53:02) 
[GCC 9.0.1 20190402 (experimental) [trunk revision 270074]] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> 'hi'[1::sys.maxsize]
Objects/unicodeobject.c:14038:55: runtime error: signed integer overflow: 1 + 
9223372036854775807 cannot be represented in type 'long int'
'i'
>>>

This is because unicode_subscript() performs an extra addition (cur += step) at 
the end of the for loop (which can overflow). The result of that final addition 
is not actually used.

A patch to fix this issue was posted on #1621, but it seems that the patch has 
been abandoned. The bug is also described in detail in that issue. I have 
tweaked the patch and will open a PR.

--
components: Extension Modules, Interpreter Core
messages: 342689
nosy: ZackerySpytz, martin.panter
priority: normal
severity: normal
status: open
title: Possible signed integer overflow in slice handling
type: behavior
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



[issue26092] doctest should allow custom sys.displayhook

2019-05-16 Thread Noam Yorav-Raphael


Noam Yorav-Raphael  added the comment:

Tim, thanks for letting me know. I certainly don't mind if you close this bug, 
since it undoes my old (and still relevant) fix.

--
nosy: +noamraph

___
Python tracker 

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



[issue18060] Updating _fields_ of a derived struct type yields a bad cif

2019-05-16 Thread Jeffrey Kintscher


Change by Jeffrey Kintscher :


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

___
Python tracker 

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



[issue36602] Recursive directory list with pathlib.Path.iterdir

2019-05-16 Thread Laurie Opperman


Laurie Opperman  added the comment:

I think I may have broken bedevere-bot by request change reviews before the PR 
was assigned...

--

___
Python tracker 

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



[issue36564] Infinite loop with short maximum line lengths in EmailPolicy

2019-05-16 Thread Abhilash Raj


Abhilash Raj  added the comment:

Moving the conversation here from https://github.com/python/cpython/pull/12732 
for David.

I previously suggested HeaderParseError because of the fact that we could fail 
to parse a value into a Header Object in the above scenario.

@r.david.murray Would it be more appropriate to have something like a 
"PolicyError" in case where the policy's max_line_length isn't long enough to 
fit the shortest encoded word?

--

___
Python tracker 

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



[issue36751] Changes in the inspect module for PEP 570

2019-05-16 Thread mike bayer


mike bayer  added the comment:

Just did some benchmarks, and while Signature has apparently had a big speedup 
in Python 3.6, it is still much less performant than either the Python 2.7 or 
Python 3.3 implementations, anywhere from 6-18 times slower approximately 
depending on the function.   For those of us that need a getargspec that is 
only used on selected, internal functions where we don't need the newer 
language features, it's likely worth it to vendor the Python 3.3 
getfullargspec() implementation which is very simple:

https://gist.github.com/zzzeek/0eb0636fa3917f36ffd887d9f765c208

--

___
Python tracker 

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



[issue21861] io class name are hardcoded in reprs

2019-05-16 Thread Windson Yang


Windson Yang  added the comment:

IIUC, in the c code we just hardcode the name "_io.FileIO" for "PyFileIO_Type" 
in https://github.com/python/cpython/blob/master/Modules/_io/fileio.c#L1180. If 
we want to get a dynamic name, we should replace the hardcode name with the 
module name (like "__main__"). I found this also happens on other modules like 
collections.

--
nosy: +Windson Yang

___
Python tracker 

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



[issue36889] Merge StreamWriter and StreamReader into just asyncio.Stream

2019-05-16 Thread Ian Good


Change by Ian Good :


--
nosy: +icgood

___
Python tracker 

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



[issue36751] Changes in the inspect module for PEP 570

2019-05-16 Thread mike bayer


mike bayer  added the comment:

> We are talking again and again that we have a lot of old things in the 
> standard library but it seems that removing them is also a problem.

I agree that the reason we have these deprecation warnings is so that we do get 
notified and we do fix them.  I think Signature is tough here because it is so 
different from how getfullargspec() worked which makes it difficult to port 
towards, and its very long and complicated invocation steps, with many loops, 
function and method calls, object creation overhead, none of which existed in 
Python 3.3's 20 line getfullargspec() implementation, is making me very 
hesitant to switch to it and I'm continuing to consider just writing my own 
thing that keeps the overhead as low as possible; but I will run timing tests 
on all versions of things before I do anything like that.

--

___
Python tracker 

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



[issue36763] PEP 587: Rework initialization API to prepare second version of the PEP

2019-05-16 Thread STINNER Victor


Change by STINNER Victor :


--
pull_requests: +13284

___
Python tracker 

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



[issue36763] PEP 587: Rework initialization API to prepare second version of the PEP

2019-05-16 Thread STINNER Victor


STINNER Victor  added the comment:


New changeset 870b035bc6da96689b59dd6f79782ec6f1873617 by Victor Stinner in 
branch 'master':
bpo-36763: Cleanup precmdline in _PyCoreConfig_Read() (GH-13371)
https://github.com/python/cpython/commit/870b035bc6da96689b59dd6f79782ec6f1873617


--

___
Python tracker 

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



[issue36876] Global C variables are a problem.

2019-05-16 Thread Eric Snow


Change by Eric Snow :


--
keywords: +patch
pull_requests: +13283
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



[issue36763] PEP 587: Rework initialization API to prepare second version of the PEP

2019-05-16 Thread STINNER Victor


Change by STINNER Victor :


--
pull_requests: +13282

___
Python tracker 

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



[issue26092] doctest should allow custom sys.displayhook

2019-05-16 Thread Tim Peters


Tim Peters  added the comment:

Oops!  Should be issue 8048.

--

___
Python tracker 

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



[issue26092] doctest should allow custom sys.displayhook

2019-05-16 Thread Tim Peters


Tim Peters  added the comment:

Noam Yorav-Raphael, I tried to add you because this is pushing back against 
your patch in issue 8408.  It's been some years now, and nobody has cared 
enough to pursue it, so I'll just close this if you still don't care ;-)

As doctest's original author, I appreciate why 8408 was done, but don't think 
it was "a good" solution.  In fact doctest can have no idea whether an example 
was _intended_ to be run with or without a custom shell's displayhook function 
invoked to massage the output first.  So more sensible would have been to add a 
new doctest directive + optional argument, to make the intent explicit.

Which is certainly more work, and hasn't actually come up as "a problem" yet.

--

___
Python tracker 

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



[issue26092] doctest should allow custom sys.displayhook

2019-05-16 Thread Tim Peters


Change by Tim Peters :


--
nosy: +noam, tim.peters

___
Python tracker 

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



[issue36850] shutil.copy2 fails with even with source network filesystem not supporting extended attributes

2019-05-16 Thread Ying Wang


Change by Ying Wang :


--
pull_requests: +13280

___
Python tracker 

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



[issue24564] shutil.copytree fails when copying NFS to NFS

2019-05-16 Thread Ying Wang


Change by Ying Wang :


--
keywords: +patch
pull_requests: +13279

___
Python tracker 

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



[issue36755] [2.7] test_httplib leaked [8, 8, 8] references with OpenSSL 1.1.1

2019-05-16 Thread Benjamin Peterson


Change by Benjamin Peterson :


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

___
Python tracker 

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



[issue36751] Changes in the inspect module for PEP 570

2019-05-16 Thread Nick Coghlan


Nick Coghlan  added the comment:

Thanks Pablo.

Noting for the record: positional-only arguments aren't new *semantically", 
since extension modules have always allowed them, and you've long been able to 
emulate them in Python code by accepting "*args".

Prior to the introduction of argument clinic and __text_signature__, the 
inspect module wouldn't report *anything* particularly useful for affected 
signatures, so folks have long built argument introspection based systems 
around the assumption that they will only be passed functions that they can 
successfully introspect.

The introduction of a Python level syntax for positional-only arguments doesn't 
change that logic, as all a consuming application has to do to be compatible 
with them is to adopt the principle "if an argument can be supplied 
positionally, it will be supplied positionally", and then only use keywords for 
keyword-only arguments.

Alternatively, consuming frameworks are also free to make "don't use 
positional-only arguments" a constraint on the callable inputs they accept.

That said, we *may* want to add a "num_position_only" attribute to FullArgSpec 
that isn't part of the tuple unpacking, for similar reasons to why we 
undeprecated getfullargspec in the first place: the easiest way to migrate from 
getfullargspec to Signature is to write a wrapper API, and if the existence of 
a wrapper API is inevitable (as I now believe it is, after our experience with 
the first attempted deprecation), we may as well maintain a properly tested one 
in the standard library, rather than seeing multiple variants of the same code 
spring up elsewhere.

--

___
Python tracker 

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



[issue36468] Treeview: wrong color change

2019-05-16 Thread Matthew Barnett


Matthew Barnett  added the comment:

I've just come across the same problem.

For future reference, adding the following code before using a Treeview widget 
will fix the problem:

def fixed_map(option):
# Fix for setting text colour for Tkinter 8.6.9
# From: https://core.tcl.tk/tk/info/509cafafae
#
# Returns the style map for 'option' with any styles starting with
# ('!disabled', '!selected', ...) filtered out.

# style.map() returns an empty list for missing options, so this
# should be future-safe.
return [elm for elm in style.map('Treeview', query_opt=option) if
  elm[:2] != ('!disabled', '!selected')]

style = ttk.Style()
style.map('Treeview', foreground=fixed_map('foreground'),
  background=fixed_map('background'))

--
nosy: +mrabarnett

___
Python tracker 

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



[issue36945] Add _PyPreConfig.configure_locale: allow to leave LC_CTYPE unchanged when embedding Python

2019-05-16 Thread STINNER Victor


Change by STINNER Victor :


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

___
Python tracker 

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



[issue36945] Add _PyPreConfig.configure_locale: allow to leave LC_CTYPE unchanged when embedding Python

2019-05-16 Thread STINNER Victor


New submission from STINNER Victor :

Py_Initiliaze() always call setlocale(LC_CTYPE, "") on all platforms to set the 
LC_CTYPE locale to the user preferred locale.

That's fine when Py_Main() is used: when Python is the only "owner" of a 
process.

I'm not sure that it's fine when Python is embedded into an application.

I propose to add _PyPreConfig.configure_locale: when set to 0, it leaves the 
LC_CTYPE locale unchanged. The caller is responsible to choose its favorite 
locale.

I'm not sure if it's real issue in practice. Maybe users learnt how to 
workaround this limitation.

By the way, I modified Python to always call setlocale(LC_CTYPE, "") on 
Windows, bpo-34485:

commit 177d921c8c03d30daa32994362023f777624b10d
Author: Victor Stinner 
Date:   Wed Aug 29 11:25:15 2018 +0200

bpo-34485, Windows: LC_CTYPE set to user preference (GH-8988)

On Windows, the LC_CTYPE is now set to the user preferred locale at
startup: _Py_SetLocaleFromEnv(LC_CTYPE) is now called during the
Python initialization. Previously, the LC_CTYPE locale was "C" at
startup, but changed when calling setlocale(LC_CTYPE, "") or
setlocale(LC_ALL, "").

pymain_read_conf() now also calls _Py_SetLocaleFromEnv(LC_CTYPE) to
behave as _Py_InitializeCore(). Moreover, it doesn't save/restore the
LC_ALL anymore.

On Windows, standard streams like sys.stdout now always use
surrogateescape error handler by default (ignore the locale).

This change caused a performance regression: bpo-35195 "[Windows] Python 3.7 
initializes LC_CTYPE locale at startup, causing performance issue on msvcrt 
isdigit()".

Attached PR implements proposed change.

--
components: Interpreter Core
messages: 342677
nosy: ncoghlan, steve.dower, twouters, vstinner
priority: normal
severity: normal
status: open
title: Add _PyPreConfig.configure_locale: allow to leave LC_CTYPE unchanged 
when embedding Python
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



[issue29282] Fused multiply-add: proposal to add math.fma()

2019-05-16 Thread Caleb Donovick


Change by Caleb Donovick :


--
nosy: +donovick

___
Python tracker 

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



[issue18060] Updating _fields_ of a derived struct type yields a bad cif

2019-05-16 Thread Jeffrey Kintscher


Jeffrey Kintscher  added the comment:

The t1.py test case calls both PyCStructUnionType_update_stgdict() and 
PyCStgDict_clone(), both of which are broken. The test case in t2.py is simpler 
than t1.py in that it only calls PyCStructUnionType_update_stgdict().

PyCStructUnionType_update_stgdict() gets called whenever _fields_ gets assigned 
a new list of element tuples. The function is supposed to copy any inherited 
element pointers in parent classes and append the new elements. The element 
pointers array in each child class is supposed to be cumulative (i.e. parent 
class element pointers plus child class element pointers).

_fields_ is represented by a StgDictObject structure, and the relevant member 
variables are 'ffi_type_pointer.elements', 'len', and 'size'. 
'ffi_type_pointer.elements' is an array of ffi_type pointers padded with a NULL 
pointer at the end. 'size' is the number of bytes in the array excluding the 
padding. 'len' is the number of elements in the current class (i.e. excluding 
the elements in parent classes).

PyCStructUnionType_update_stgdict() allocates a new 'ffi_type_pointer.elements' 
array by adding 1 to the sum of 'len' and the 'len' member of the parent class, 
then multiplying by sizeof(ffi_type *). This works just fine when there is a 
single parent class, but breaks when there are multiple levels of inheritance. 
For example:

   class Base(Structure):
  _fields_ = [('y', c_double),
  ('x', c_double)]

class Mid(Base):
_fields_ = []

class Vector(Mid):
_fields_ = []

PyCStructUnionType_update_stgdict() gets called for each of the three _fileds_ 
assignments. Assuming a pointer size of 8 bytes, Base has these values:

ffi_type_pointer.elements = array of 3 pointers (x, y, and NULL padding).
len = 2
size = 16 (i.e. 2 * sizeof(ffi_type *))

Mid has these values:

ffi_type_pointer.elements = array of 3 pointers (x, y, and NULL padding).
len = 0
size = 16 (i.e. 2 * sizeof(ffi_type *))

Vector has these values:

ffi_type_pointer.elements = array of 1 pointer (x)
len = 0
size = 16 (i.e. 2 * sizeof(ffi_type *))

Vector's 'len' and 'size' are correct, but 'ffi_type_pointer.elements' contains 
one element instead of three. Vector should have:

ffi_type_pointer.elements = array of 3 pointers (x, y, and NULL padding).
len = 0
size = 16 (i.e. 2 * sizeof(ffi_type *))

'ffi_type_pointer.elements' got truncated because 
PyCStructUnionType_update_stgdict() uses the parent class's 'len' field to 
determine the size of the new array to allocate. As can be seen, Mid's 'len' is 
zero, so a new array with one element gets allocated and copied (0 element 
pointers plus a trailing NULL pointer for padding). Notice that Vector's 'size' 
is correct because the value is calculated as Mid's 'size' plus zero (for zero 
elements being added in the child class).

Similarly, PyCStgDict_clone() has the same problem because it also uses the 
similar calculations based on 'len' to determine the new 
'ffi_type_pointer.elements' array size that gets allocated and copied.

The solution proposed by lauri.alanko effectively redefines the 'len' member 
variable to be the total number of elements defined in the inheritance chain 
for _fields_. While this does fix the allocation/copying issue, it breaks other 
code that expects the 'len' variables in the parent and child classes to be 
distinct values instead of cumulative. For example (from 
StructureTestCase.test_positional_args() in Lib/ctypes/test/test_structures.py),

class W(Structure):
_fields_ = [("a", c_int), ("b", c_int)]
class X(W):
_fields_ = [("c", c_int)]
class Y(X):
pass
class Z(Y):
_fields_ = [("d", c_int), ("e", c_int), ("f", c_int)]

z = Z(1, 2, 3, 4, 5, 6)

will throw an exception because Z's 'len' will be 6 instead of the expected 3.

A better solution is to use 'size' to allocate and copy 
'ffi_type_pointer.elements' since its value is already properly calculated and 
propagated through inheritance.

--
Added file: https://bugs.python.org/file48332/t2.py

___
Python tracker 

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



[issue36943] Windows test changes for Windows ARM64

2019-05-16 Thread Paul Monson


Change by Paul Monson :


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

___
Python tracker 

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



[issue36942] Windows code changes for Windows ARM64

2019-05-16 Thread Paul Monson


Change by Paul Monson :


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

___
Python tracker 

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



[issue36941] Windows build changes for Windows ARM64

2019-05-16 Thread Paul Monson


Change by Paul Monson :


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

___
Python tracker 

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



[issue36944] Add support for ARM64 to libffi

2019-05-16 Thread Paul Monson


New submission from Paul Monson :

These changes are also submitted to libffi as 
https://github.com/libffi/libffi/pull/490

--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
title: W -> Add support for ARM64 to libffi
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



[issue36944] W

2019-05-16 Thread Paul Monson


Change by Paul Monson :


--
nosy: Paul Monson
priority: normal
severity: normal
status: open
title: W

___
Python tracker 

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



[issue36943] Windows test changes for Windows ARM64

2019-05-16 Thread Paul Monson


New submission from Paul Monson :

Add Windows test changes for Windows ARM64

--
components: Windows
messages: 342674
nosy: Paul Monson, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows test changes for Windows ARM64
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



[issue36942] Windows code changes for Windows ARM64

2019-05-16 Thread Paul Monson


New submission from Paul Monson :

Add ifdef changes for Windows ARM64

--
components: Windows
messages: 342673
nosy: Paul Monson, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows code changes for Windows ARM64
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



[issue36941] Windows build changes for Windows ARM64

2019-05-16 Thread Paul Monson


New submission from Paul Monson :

Add build file changes for Windows ARM64

--
components: Build, Windows
messages: 342672
nosy: Paul Monson, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows build changes for Windows ARM64
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



[issue34509] Starting to use gcc-8 on CI

2019-05-16 Thread Jun Aruga


Jun Aruga  added the comment:

Sure, alright. Thanks for informing me.

On Thu, 16 May 2019 at 00:08, Zachary Ware  wrote:
>
>
> Zachary Ware  added the comment:
>
> We do now have at least one builder using GCC 8 (ware-gentoo-x86) and one 
> using GCC 9 (cstratak-fedora), so I'm closing the issue.  Thanks for bringing 
> this up, and sorry it fell through the cracks for a while!
>
> --
> resolution:  -> fixed
> stage: patch review -> resolved
> status: open -> closed
>
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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



[issue36751] Changes in the inspect module for PEP 570

2019-05-16 Thread Pablo Galindo Salgado


Change by Pablo Galindo Salgado :


--
priority: release blocker -> normal

___
Python tracker 

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



[issue36751] Changes in the inspect module for PEP 570

2019-05-16 Thread Pablo Galindo Salgado


Pablo Galindo Salgado  added the comment:


New changeset aee19f54f6fe45f6b3c906987941e5a8af4468e9 by Pablo Galindo in 
branch 'master':
bpo-36751: Undeprecate getfullargspec (GH-13245)
https://github.com/python/cpython/commit/aee19f54f6fe45f6b3c906987941e5a8af4468e9


--

___
Python tracker 

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



[issue36751] Changes in the inspect module for PEP 570

2019-05-16 Thread Pablo Galindo Salgado


Pablo Galindo Salgado  added the comment:

For now, I am going to proceed to merge PR13245 and un-deprecate 
getfullargspec().

Being said that I would want to remark that if test suites are broken when 
deprecation warnings are emitted that is (1) their own choice, (2) precisely to 
detect when some deprecation is happening. If we apply some version of this 
reasoning to everything the standard library will not be able to deprecate 
anything (not even raise deprecation warnings!). We are talking again and again 
that we have a lot of old things in the standard library but it seems that 
removing them is also a problem.

I want to make clear that I understand the arguments here and this is why I am 
going to merge PR13245 and I also apologize for any pain this may cause, but I 
also would ask people for empathy towards the standard library, Python and core 
developers.

Regarding PEP570, getfullargspec() will report positional-only arguments as 
regular arguments.

--

___
Python tracker 

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



[issue26515] Update extending/embedding docs to new way to build modules in C

2019-05-16 Thread Petr Viktorin


Petr Viktorin  added the comment:

Correct usage of multi-phase init might now get users stuck when they start 
needing per-module state. See PEP 573 "Module State Access from C Extension 
Methods" for the (hopefully) last thing that prevents me from generally 
recommending multi-phase init.

That PEP is on my list for after PRP 590 is done.
Before it's implemented, I'm happy leaving PyModuleDef_Init to experts -- that 
is, have it in the reference docs only.

--

___
Python tracker 

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



[issue36748] Optimize textio write buffering

2019-05-16 Thread Michele Angrisano


Change by Michele Angrisano :


--
pull_requests: +13274

___
Python tracker 

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



[issue36751] Changes in the inspect module for PEP 570

2019-05-16 Thread Miro Hrončok

Miro Hrončok  added the comment:

As a downstream maintainers of Python in Fedora, this is a great PITA for us. A 
lot of projects unfortunately treat DeprecationWarnings as errors and we run 
upstream test suites. It appears that this particular DeprecationWarning is now 
failing the test suites of the majority of important Python libraries. The 
warning is there from pluggy (a pytest dependency, already fixed), hypothesis, 
etc... We mitigate this from the testing framework dependencies, only to 
realize the tested library itself uses it as well. Current list of problematic 
packages includes pytest, tornado, sqlalchemy, numpy, dateutil and others.

I'm not saying that should be the only reason not to deprecate stuff (nothing 
could be deprecated if we stretch that argument too far), but clearly 
"deprecating warning doesn't hurt" is not an argument either.

--

___
Python tracker 

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



[issue36751] Changes in the inspect module for PEP 570

2019-05-16 Thread mike bayer


mike bayer  added the comment:

> A deprecating warning doesn't hurt: you are still able to run your code.

this is very much untrue in modern testing environments, as it is common that 
test suites fail on deprecation warnings, especially in libraries, to ensure 
downstream compatibility.  My observation is that as Python 3 has been 
generally a lot more aggressive about new language features than things used to 
be in the py2k days, a lot more of these deprecations have been coming through. 
 

I've looked at pep 570 and this new syntax does not affect the four libraries 
for which I have to rewrite getfullargspec, so while I'm looking a bit at 
things like the "Signature" backport for py2.7 (funcsigs), the pure-Python 
complexity of Signature is very hard to take on as well as a py2k-only 
dependency so I'm still leaning towards producing the most minimal 
getfullargspec() I can use that continues to work for "traditional" Python 
signatures.

i understand that Signature is "future-proof", but it is heavy on the pure 
Python and object creation and does not provide for any simple py2k/py3k 
cross-compatibility solution.   I'd very much prefer that Signature at least be 
written in C for a few major versions, as well as the community has had time to 
move further python-3-only,  before getfullargspec is so aggressively 
deprecated.

--

___
Python tracker 

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



[issue8400] zipimporter find_module fullname mis-documented

2019-05-16 Thread Brett Cannon


Brett Cannon  added the comment:

Actually find_module() should be deprecated and find_spec() should be defined 
instead (and the same goes for load_module(); see bpo-9699). So I'm personally 
fine w/ making this a doc problem w/ the plan to eventually deprecate the 
method.

--

___
Python tracker 

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



[issue36675] Doctest directives and comments missing from code samples

2019-05-16 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

> Doctest directives in code examples should be suppressed everywhere 
> *except* in the doctest.html examples showing how to use directives.  
> The patch only exposes them for doctest.html and not for ctypes or 
> anywhere else.

Thanks for the patch, and the extra information, but I disagree with the 
decision to suppress the directives.

The reason I found this problem in the first case was that I started 
with the ctypes documentation, where it says:

"Since some code samples behave differently under Linux, Windows, or Mac 
OS X, they contain doctest directives in comments."

and I was very keen to see those directives so I could learn the right 
way to deal with platform-dependent doctests. I was very confused that 
they weren't visible.

https://docs.python.org/3/library/ctypes.html

I think that doctest directives are as much a part of documenting 
correct usage as any other part of the example code, and they are 
(semi-)human readable and (almost) self-documenting.

Consider this example from ctypes:

>>> c_wchar_p("Hello, World")
c_wchar_p(140018365411392)

In the absence of a directive, but knowing that it may have been 
surpressed, I don't know how to interpret that. Is the output some 
arbitrarily chosen value that doctest ought to skip? Or is that the 
actual output that c_wchar_p("Hello, World") will return every single 
time without fail?

If I was a ctypes expert, it might be blindingly obvious to me, but I'm 
not, so I'm left in the dark. I don't know whether I should expect that 
precise output each and every time, or something platform and 
implementation specific.

If the directive #doctest:+SKIP was visible, I would know that it was an 
arbitrarily chosen example. 

My preference would be:

- keep the doctest directives visible, everywhere;

- make them a clickable link to the appropriate section 
  in the doctest documentation;

- and, if possible, on mouse-over, they should display a
  tooltip with a message like 

  "The output of this example is arbitrary."

Or similar wording.

> They really should not be in the dir example code that I linked to.
> https://docs.python.org/3/library/functions.html#dir

On the contrary: I think that the presence of the +SKIP directive helps 
demonstrate that the output shown is a made-up example, not normative.

(Of course it helps that I know doctest, but even if I didn't, the 
tooltip message would help.)

--

___
Python tracker 

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



[issue36880] Returning None from a callback with restype py_object decrements None's refcount too much

2019-05-16 Thread dgelessus


Change by dgelessus :


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

___
Python tracker 

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



[issue36930] Windows proxy settings automatically used ... partly

2019-05-16 Thread Immo Wetzel


Immo Wetzel  added the comment:

issue is only on urllib2 and requests (external lib)
ticket opened: https://github.com/kennethreitz/requests/issues/5095

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



[issue35926] Need openssl 1.1.1 support on Windows for ARM and ARM64

2019-05-16 Thread Steve Dower


Steve Dower  added the comment:


New changeset aa73841a8fdded4a462d045d1eb03899cbeecd65 by Steve Dower in branch 
'3.7':
bpo-35926: Add support for OpenSSL 1.1.1b on Windows (GH-11779)
https://github.com/python/cpython/commit/aa73841a8fdded4a462d045d1eb03899cbeecd65


--

___
Python tracker 

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



[issue36511] Add Windows ARM32 buildbot

2019-05-16 Thread Steve Dower


Steve Dower  added the comment:

Paul - looks like there's a timeout being hit due to lack of output. Any ideas?

https://buildbot.python.org/all/#/builders/203/builds/6

--

___
Python tracker 

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



[issue36930] Windows proxy settings automatically used ... partly

2019-05-16 Thread Immo Wetzel


Immo Wetzel  added the comment:

thanks for pointing this out. I've retested urllib3 with success. requests with 
no success. so I'll write a new issue on requests. Thanks a lot

--

___
Python tracker 

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



[issue36763] PEP 587: Rework initialization API to prepare second version of the PEP

2019-05-16 Thread STINNER Victor


STINNER Victor  added the comment:


New changeset 54b43bb3bb88339b63182b3515cda3efa530ed62 by Victor Stinner in 
branch 'master':
bpo-36763: Add _PyCoreConfig.configure_c_stdio (GH-13363)
https://github.com/python/cpython/commit/54b43bb3bb88339b63182b3515cda3efa530ed62


--

___
Python tracker 

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



[issue36930] Windows proxy settings automatically used ... partly

2019-05-16 Thread Steve Dower


Steve Dower  added the comment:

requests is a third-party library, so if they're finding your settings you 
probably need to report it to them.

urllib2 is only part of Python 2.x. Do you have a repro with urllib on Python 3?

--

___
Python tracker 

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



[issue36930] Windows proxy settings automatically used ... partly

2019-05-16 Thread Immo Wetzel


Immo Wetzel  added the comment:

>Can you clarify how you are setting your proxy configuration and how >Python 
>is finding out about it?
The windows host get his proxy configuration via group police from the Active 
Directory. The group policy points to a specific file wpad.dat formerly known 
as proxy.pac
This is a configuration used for IE and Chrome automatically from the hosts.

How Python finds this out and is using this is unclear to me. There is 
definitely no environment variable setting done.

>Also, which libraries are you using?
request and urllib2 both are failing

>As far as I'm aware, Python itself does nothing special to load proxy settings 
>from normal Windows configuration. Doing so would be a feature request (though 
>it's one I'd like to see happen).

I was guessing so too. Especially cos all help site tell me how to specify 
proxy objects for use with requests lib. But obviously there is something 
existing.

--

___
Python tracker 

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



[issue36930] Windows proxy settings automatically used ... partly

2019-05-16 Thread Steve Dower


Steve Dower  added the comment:

Can you clarify how you are setting your proxy configuration and how Python is 
finding out about it?

Also, which libraries are you using?

As far as I'm aware, Python itself does nothing special to load proxy settings 
from normal Windows configuration. Doing so would be a feature request (though 
it's one I'd like to see happen).

--

___
Python tracker 

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



[issue36763] PEP 587: Rework initialization API to prepare second version of the PEP

2019-05-16 Thread STINNER Victor


Change by STINNER Victor :


--
pull_requests: +13272

___
Python tracker 

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



[issue36675] Doctest directives and comments missing from code samples

2019-05-16 Thread Jeroen Demeyer


Jeroen Demeyer  added the comment:

> Doctest directives in code examples should be suppressed everywhere *except* 
> in the doctest.html examples showing how to use directives.

Thanks for clarifying. I missed that.

--

___
Python tracker 

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



[issue36763] PEP 587: Rework initialization API to prepare second version of the PEP

2019-05-16 Thread STINNER Victor


STINNER Victor  added the comment:


New changeset 9ef5dcaa0b3c7c7ba28dbb3ec0c9507d9d05e3a9 by Victor Stinner in 
branch 'master':
bpo-36763: Add _Py_InitializeMain() (GH-13362)
https://github.com/python/cpython/commit/9ef5dcaa0b3c7c7ba28dbb3ec0c9507d9d05e3a9


--

___
Python tracker 

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



[issue36940] Update Py_FrozenMain() for _PyCoreConfig (PEP 587)

2019-05-16 Thread STINNER Victor


New submission from STINNER Victor :

Python/frozenmain.c should use pre-initialization and be adapted for 
_PyCoreConfig. Py_FrozenMain() reimplements some features which are now 
implemented by _Py_InitializeFromConfig():

* disable C streams (stdin, stdout, stderr) buffering
* decode argv using Py_DecodeLocale()
* set the program name (call Py_SetProgramName())
* set sys.argv
* reimplement the REPL

It seems like it could use _Py_RunMain(), but I'm not sure.

--
components: Interpreter Core
messages: 342653
nosy: ncoghlan, steve.dower, twouters, vstinner
priority: normal
severity: normal
status: open
title: Update Py_FrozenMain() for _PyCoreConfig (PEP 587)
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



[issue36675] Doctest directives and comments missing from code samples

2019-05-16 Thread Terry J. Reedy


Terry J. Reedy  added the comment:

Doctest directives in code examples should be suppressed everywhere *except* in 
the doctest.html examples showing how to use directives.  The patch only 
exposes them for doctest.html and not for ctypes or anywhere else.

They really should not be in the dir example code that I linked to.
https://docs.python.org/3/library/functions.html#dir
The problem there are the double comments with both a real comment and a 
directive.

https://devguide.python.org/documenting/#source-code does not say anything 
about '::' causing suppression of comments and ':' leaving them.  It is 
misleading in implying the '::' is required for a code block.

--

___
Python tracker 

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



[issue36763] PEP 587: Rework initialization API to prepare second version of the PEP

2019-05-16 Thread STINNER Victor


Change by STINNER Victor :


--
pull_requests: +13271

___
Python tracker 

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



[issue36763] PEP 587: Rework initialization API to prepare second version of the PEP

2019-05-16 Thread STINNER Victor


STINNER Victor  added the comment:


New changeset ae239f6b0626e926613a4a1dbafa323bd41fec32 by Victor Stinner in 
branch 'master':
bpo-36763: Add _PyCoreConfig.parse_argv (GH-13361)
https://github.com/python/cpython/commit/ae239f6b0626e926613a4a1dbafa323bd41fec32


--

___
Python tracker 

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



[issue36675] Doctest directives and comments missing from code samples

2019-05-16 Thread Éric Araujo

Éric Araujo  added the comment:

OP is about the documentation page for doctest itself!

--

___
Python tracker 

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



[issue36921] Deprecate yield from and @coroutine in asyncio

2019-05-16 Thread miss-islington


New submission from miss-islington :


New changeset 68b34a720485f399e8699235b8f4e08f227dd43b by Miss Islington (bot) 
(Andrew Svetlov) in branch 'master':
bpo-36921: Deprecate @coroutine for sake of async def (GH-13346)
https://github.com/python/cpython/commit/68b34a720485f399e8699235b8f4e08f227dd43b


--
nosy: +miss-islington

___
Python tracker 

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



[issue36675] Doctest directives and comments missing from code samples

2019-05-16 Thread Jeroen Demeyer


Jeroen Demeyer  added the comment:

Isn't it a *feature* that those doctest directives are not shown? Those 
directives are meant for the doctest module only, not for the reader of the 
rendered documentation.

--
nosy: +jdemeyer

___
Python tracker 

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



[issue36763] PEP 587: Rework initialization API to prepare second version of the PEP

2019-05-16 Thread STINNER Victor


Change by STINNER Victor :


--
pull_requests: +13270

___
Python tracker 

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



[issue36763] PEP 587: Rework initialization API to prepare second version of the PEP

2019-05-16 Thread STINNER Victor


STINNER Victor  added the comment:


New changeset dbacfc227381fbc7b3c886ea0bd7806ab3dc62c2 by Victor Stinner in 
branch 'master':
bpo-36763: _PyInitError always use int for exitcode (GH-13360)
https://github.com/python/cpython/commit/dbacfc227381fbc7b3c886ea0bd7806ab3dc62c2


--

___
Python tracker 

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



[issue36939] Allow to use shutil.copytree for existing destination directory with optional argument

2019-05-16 Thread jack1142


jack1142  added the comment:

Sorry, it looks like I was looking at 3.7 branch and this is already 
implemented in master branch.

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



[issue36939] Allow to use shutil.copytree for existing destination directory with optional argument

2019-05-16 Thread jack1142


New submission from jack1142 :

Currently shutil.copytree will allow to copy tree only if destination directory 
doesn't exist. I think there could be added `exist_ok` keyword argument 
(defaulting to `False`), which when set to `True` would prevent function from 
raising `FileExistsError`.
This is pretty easy to implement as `os.makedirs` command that raises this 
error already has `exist_ok` kwarg, which prevent function from raising that 
exception already.

--
components: Library (Lib)
messages: 342645
nosy: jack1142
priority: normal
severity: normal
status: open
title: Allow to use shutil.copytree for existing destination directory with 
optional argument
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



[issue36763] PEP 587: Rework initialization API to prepare second version of the PEP

2019-05-16 Thread STINNER Victor


Change by STINNER Victor :


--
pull_requests: +13269

___
Python tracker 

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



[issue36927] traceback docstrings should explicitly state return values instead of referring to other functions

2019-05-16 Thread Michele Angrisano


Change by Michele Angrisano :


--
keywords: +patch
pull_requests: +13268
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



[issue36938] Py_XDECREF on PyUnicodeobject raises SIGSEGV signal

2019-05-16 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

PyTuple_SetItem() steals a reference to the added item. You should not call 
Py_XDECREF() for it.

--
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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



[issue35589] BaseSelectorEventLoop.sock_sendall() performance regression: extra copy of data

2019-05-16 Thread Andrew Svetlov


Change by Andrew Svetlov :


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



[issue35589] BaseSelectorEventLoop.sock_sendall() performance regression: extra copy of data

2019-05-16 Thread miss-islington


miss-islington  added the comment:


New changeset 6e7890028213b30939327e7cf885bf097fc14472 by Miss Islington (bot) 
(Andrew Svetlov) in branch 'master':
bpo-35589: Prevent buffer copy in sock_sendall() (GH-11418)
https://github.com/python/cpython/commit/6e7890028213b30939327e7cf885bf097fc14472


--
nosy: +miss-islington

___
Python tracker 

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



[issue36938] Py_XDECREF on PyUnicodeobject raises SIGSEGV signal

2019-05-16 Thread Khalil


New submission from Khalil :

I Have a set of callbacks from a C extension to a Python code and I noticed 
that when I report a unicode string to the Python code, and use the Py_XDECREF 
on it then whole application crashes with the SIGSEGV signal.This is a snippet 
of the codes:

/***/

PyObject *MyString = PyUnicode_FromString("BlaBla");
PyTuple_SetItem(MyTuple, 0, MyString);
PyObject_CallObject(callback, PyTuple);

Py_XDECREF(MyString);
Py_XDECREF(MyTuple);
...
/***/

when I create my string within the set item then it works fine, like below:

PyTuple_SetItem(MyTuple, 0, PyUnicode_FromString("BlaBla"));
PyObject_CallObject(callback, PyTuple);
Py_XDECREF(MyTuple);
...

--
components: Extension Modules
messages: 342642
nosy: Khalilmtg
priority: normal
severity: normal
status: open
title: Py_XDECREF on PyUnicodeobject raises SIGSEGV signal
type: crash
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



[issue36936] CALL_FUNCTION_KW opcode: keyword names must be non-empty

2019-05-16 Thread Jeroen Demeyer


Jeroen Demeyer  added the comment:

Adding that assertion allows future optimizations and simplifications: with the 
assertion, "keyword arguments are passed" becomes equivalent to

  kwnames != NULL

instead of

  kwnames != NULL && PyTuple_GET_SIZE(kwnames) > 0

This may not be useful right now, but it will become more useful when 
implementing PEP 590.

--

___
Python tracker 

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



[issue36936] CALL_FUNCTION_KW opcode: keyword names must be non-empty

2019-05-16 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

Then I do not see a reason to add an assertion.

--

___
Python tracker 

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



[issue36937] New _PyObject_MakeTpCall() function

2019-05-16 Thread Jeroen Demeyer


Jeroen Demeyer  added the comment:

I forgot to mention that the idea and first implementation comes from Mark 
Shannon.

--

___
Python tracker 

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



[issue36937] New _PyObject_MakeTpCall() function

2019-05-16 Thread Jeroen Demeyer


Change by Jeroen Demeyer :


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

___
Python tracker 

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



[issue36936] CALL_FUNCTION_KW opcode: keyword names must be non-empty

2019-05-16 Thread Jeroen Demeyer


Jeroen Demeyer  added the comment:

> What happens when pass an empty tuple?

The way how bytecode is compiled, that doesn't actually happen so it's an 
entirely hypothetical question.

The various XXX_FastCallKeywords functions seem to allow passing an empty tuple 
to mean "no keyword arguments", so I guess that nothing breaks when you would 
actually pass an empty tuple

--

___
Python tracker 

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



[issue31078] pdb's debug command (Pdb.do_debug) doesn't use rawinput even if the parent pdb uses rawinput

2019-05-16 Thread daniel hahler


daniel hahler  added the comment:

> I think a good alternative patch might be:

This however makes it behave different in tests, where stdout might be 
mocked/wrapped intentionally.

Therefore I think using the parent's `use_rawinput` is the better fix for this 
(the originally proposed patch).

--

___
Python tracker 

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



[issue36936] CALL_FUNCTION_KW opcode: keyword names must be non-empty

2019-05-16 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

What happens when pass an empty tuple?

--
nosy: +serhiy.storchaka

___
Python tracker 

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



[issue31078] pdb's debug command (Pdb.do_debug) doesn't use rawinput even if the parent pdb uses rawinput

2019-05-16 Thread daniel hahler


daniel hahler  added the comment:

Just for reference and searchability: this causes tab completion to not work 
with `debug foo()` also.

--

___
Python tracker 

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



[issue31078] pdb's debug command (Pdb.do_debug) doesn't use rawinput even if the parent pdb uses rawinput

2019-05-16 Thread daniel hahler


daniel hahler  added the comment:

It was added in 477c8d5e702 (a huge svn merge commit), with this reference:


  r45955 | georg.brandl | 2006-05-10 19:13:20 +0200 (Wed, 10 May 2006) | 4 
lines

  Patch #721464: pdb.Pdb instances can now be given explicit stdin and
  stdout arguments, making it possible to redirect input and output
  for remote debugging.

I think a good alternative patch might be:

```diff
 Lib/pdb.py | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git i/Lib/pdb.py w/Lib/pdb.py
index f5d33c27fc..daf49b3629 100755
--- i/Lib/pdb.py
+++ w/Lib/pdb.py
@@ -141,7 +141,9 @@ def __init__(self, completekey='tab', stdin=None, 
stdout=None, skip=None,
  nosigint=False, readrc=True):
 bdb.Bdb.__init__(self, skip=skip)
 cmd.Cmd.__init__(self, completekey, stdin, stdout)
-if stdout:
+if stdout and stdout is not sys.stdout:
+# stdout gets passed with do_debug for example, but should usually
+# not disable using raw input then.
 self.use_rawinput = 0
 self.prompt = '(Pdb) '
 self.aliases = {}
```

--
versions: +Python 3.9

___
Python tracker 

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



[issue36927] traceback docstrings should explicitly state return values instead of referring to other functions

2019-05-16 Thread Michele Angrisano


Michele Angrisano  added the comment:

If Aaron can't working on it, I can do it. Just tell me.

Thanks.

--
nosy: +Michele Angrisano

___
Python tracker 

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



[issue36937] New _PyObject_MakeTpCall() function

2019-05-16 Thread Jeroen Demeyer


New submission from Jeroen Demeyer :

Add a new private function

PyObject *_PyObject_MakeTpCall(PyObject *callable, PyObject *const *args, 
Py_ssize_t nargs, PyObject *keywords)

to call "callable" using tp_call, but with arguments given using the 
FastCallKeywords or FastCallDict convention (both are allowed, see also 
https://github.com/python/peps/pull/1038).

The code is not new, it's essentially moving the tp_call case out of 
_PyObject_FastCallKeywords() and _PyObject_FastCallDict().

This was first proposed (as public API under the name PyCall_MakeTpCall) for 
PEP 590 but it makes sense to do this independently.

--
components: Interpreter Core
messages: 342632
nosy: Mark.Shannon, jdemeyer, petr.viktorin, vstinner
priority: normal
severity: normal
status: open
title: New _PyObject_MakeTpCall() function
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



[issue36936] CALL_FUNCTION_KW opcode: keyword names must be non-empty

2019-05-16 Thread Jeroen Demeyer


Change by Jeroen Demeyer :


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

___
Python tracker 

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



[issue36936] CALL_FUNCTION_KW opcode: keyword names must be non-empty

2019-05-16 Thread Jeroen Demeyer


New submission from Jeroen Demeyer :

Document and add an assertion that the "keyword names" tuple of the 
CALL_FUNCTION_KW opcode must be non-empty. This is already the case with the 
current compiler: if there are no keyword arguments in a call, then the 
CALL_FUNCTION_KW opcode is not used.

In light of https://github.com/python/peps/pull/1049 it's good to make this an 
explicit guarantee.

--
components: Interpreter Core
messages: 342631
nosy: Mark.Shannon, jdemeyer, petr.viktorin, vstinner
priority: normal
severity: normal
status: open
title: CALL_FUNCTION_KW opcode: keyword names must be non-empty
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



[issue36930] Windows proxy settings automatically used ... partly

2019-05-16 Thread SilentGhost


Change by SilentGhost :


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



[issue36930] Windows proxy settings automatically used ... partly

2019-05-16 Thread SilentGhost


SilentGhost  added the comment:

Immo, please be careful when editing the fields. You've set the values that 
were explicitly removed by the developer. Library is fine.

--
assignee: terry.reedy -> 
components:  -IDLE, IO
nosy: +SilentGhost, orsenthil -terry.reedy
type:  -> behavior
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



[issue36930] Windows proxy settings automatically used ... partly

2019-05-16 Thread Immo Wetzel


Immo Wetzel  added the comment:

ok where should I place this . IO or Library ?

If this is not a bug  I really have to do some soul-searching

--
assignee:  -> terry.reedy
components: +IDLE
nosy: +terry.reedy
versions: +Python 3.6 -Python 3.8

___
Python tracker 

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



[issue36935] bpo-35813 introduced usage of the deprecated PyErr_SetFromWindowsErrWithUnicodeFilename() function

2019-05-16 Thread Eryk Sun


Eryk Sun  added the comment:

This was my fault for recommending PyErr_SetFromWindowsErrWithUnicodeFilename 
without checking the header for deprecation. 

PyErr_SetFromWindowsErrWithUnicodeFilename is an internal function (added for 
PEP 277, circa 2.4), which was never documented in the C API. I don't follow 
why Serhiy deprecated it in 2016, since at the same time he updated it to use 
PyUnicode_FromWideChar instead of PyUnicode_FromUnicode. I see no fundamental 
difference in terms of resource usage between it and 
PyErr_SetExcFromWindowsErrWithFilename, which instead calls 
PyUnicode_DecodeFSDefault.

In this case, the section object (file mapping) name is useful information in 
the exception. If the deprecation isn't lifted, it puts the onus on us to 
implement this functionality -- i.e. PyUnicode_FromWideChar, 
PyErr_SetExcFromWindowsErrWithFilenameObjects, Py_XDECREF. Or maybe add a new 
PyErr_SetExcFromWindowsErrWithWideCharFilename function that takes a `const 
wchar_t *` string, and document it in the C API.

--
nosy: +eryksun

___
Python tracker 

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



[issue36748] Optimize textio write buffering

2019-05-16 Thread Inada Naoki


Change by Inada Naoki :


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

___
Python tracker 

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



[issue36748] Optimize textio write buffering

2019-05-16 Thread Inada Naoki


Inada Naoki  added the comment:


New changeset bfba8c373e362d48d4ee0e0cf55b8d9c169344ae by Inada Naoki in branch 
'master':
bpo-36748: optimize TextIOWrapper.write() for ASCII string (GH-13002)
https://github.com/python/cpython/commit/bfba8c373e362d48d4ee0e0cf55b8d9c169344ae


--

___
Python tracker 

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