date:20160702


Raymond Hettinger added the comment:

Though this gives us a nicely reduced line count, I'm disinclined to do this 
for several reasons:

The benefit is too small to warrant this kind of atypical macro/include magic 
(with "magic" being the pattern of making a series of #defines followed by an 
#inclusion of a .h file that uses those definition to generate code that would 
normally be in a .c file and then #undefining so that the pattern can be 
repeated elsewhere).

Anyone trying to maintain this code will have to rediscover what you're doing 
and mentally unroll all the steps.  I also think it will confuse static tools 
like CTAGs, making the source harder to trace.

In general, the rule of refactoring is to express every idea only once in the 
source, so I do understand the motivation for this patch; however, this patch 
results in a net increase in maintenance burden and will make it more difficult 
for our newer core developers to understand the code.  Currently listobject.c 
and tupleobject.c are separately digestible and intelligible -- one can read 
and make changes to each without learning new macros and without worrying about 
the effects of tight coupling ("don't tug on that, you never know what it might 
be attached to").

I don't think we're solving a real problem here.  The code currently works fine 
and is easy to digest one object type at a time.  

For me, the patch interferes with the way I think about and work with these 
modules.  I reason about the what the iterator is doing in conjuction with the 
surrounding code for the rest of the type.  This patch has a conflicting notion 
which is that sequence iteration is a single concept that should be reasoned 
about independently of how the type is implemented.  

If someone later wants to do major surgery to one of the types (such as being 
contemplated now with compacts dicts being applied to dictobject.c), the 
maintainer would have to first undo this patch.

FWIW, I looked at similar transformations many times and have always concluded 
that it would make us worse off even though the code size would be smaller.  
For example, the itertools module has internal redundancy; however, that is a 
net benefit because it allows each tool to be reasoned about separately and to 
be maintained without worrying about the effects on the other tools.

So, please put me down for a -1.  Factoring and less code are generally good, 
but tricky macro/define/include/undefine magic is bad.  Tight coupling is also 
bad.

I worry that in you efforts to "refactor" just about everything in the entire 
code base, you are invalidating the design decisions of every developer who 
came before you.  In creating many new macros, we're increasing the learning 
curve for subsequent maintainers (they have to first learn what tricks the 
macros are doing and what is behind the abstraction before being able to do 
anything).  Also, it creates was somewhat constipated coding style where 
everything has been squeezed tightly together and lost the simple fluidity and 
lucidity that it had before.

--
nosy: +rhettinger

___
Python tracker 

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

[issue27438] Refactor simple iterators implementation


Changes by Raymond Hettinger :


--
nosy: +tim.peters

___
Python tracker 

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

[issue27051] Create PIP gui

2016-07-02 Thread Upendra Kumar


Upendra Kumar added the comment:

For using threading with Tkinter there are two options : either to use 
threading or asyncio ( coroutines ). Because asyncio is easier as compared to 
threading, therefore I would like to use it.

But, coroutines are available only in Python >=3.5. Therefore should we target 
all Python 3 users or Python>=3.5 users?

--

___
Python tracker 

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

[issue27439] product function patch

2016-07-02 Thread Utkan Gezer


New submission from Utkan Gezer:

An issue of enhancement by the introduction of a built-in product() function 
for the multiplication operation, functions similar to how sum does for the 
addition operation.

This issue is a reincarnation of Issue 1093 for Python 2.6, now for 3.6.

Ref: http://bugs.python.org/issue1093

--
messages: 269706
nosy: Utkan Gezer
priority: normal
severity: normal
status: open
title: product function patch
type: enhancement
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

[issue27439] product function patch

2016-07-02 Thread Emanuel Barry


Emanuel Barry added the comment:

What is the use case, and why is a regular for loop not enough? The bar for 
adding new builtin functions is high, and I don't think this meets it.

--
nosy: +ebarry

___
Python tracker 

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

[issue27439] product function patch

2016-07-02 Thread Utkan Gezer


Utkan Gezer added the comment:

The use case is similar to the use case of sum() function, which is analogous 
to the sigma notation in mathematics, and is analogous to the use case of the 
pi notation in mathematics.

Regular loop should be equally enough to achieve the function of sum(), yet the 
sum() exists. Only apparent (to me) difference between the sum() and product() 
is that sum() is already built-in while product() is yet to be.

--

___
Python tracker 

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

[issue27439] product function patch

2016-07-02 Thread Steven D'Aprano

Steven D'Aprano added the comment:

On Sat, Jul 02, 2016 at 11:40:48AM +, Utkan Gezer wrote:
> 
> New submission from Utkan Gezer:
> 
> An issue of enhancement by the introduction of a built-in product() 
> function for the multiplication operation, functions similar to how 
> sum does for the addition operation.

I will likely be introducing an internal product() to the statistics 
module, for use in calculating the geometric mean. 

The problem with product() is similar to the problem with sum(). There 
are three different implementations of sum in the std lib: a general 
purpose one optimised for speed as the builtin, one optimized for 
floating point accuracy in the math module, and an internal-only private 
one optimized for exactness in the statistics module. I expect that 
product() will have the same tradeoffs, only even more so since it will 
overflow much more easily than sum() will.

--
nosy: +steven.daprano

___
Python tracker 

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

[issue27439] Add a product() function to the standard library

2016-07-02 Thread Emanuel Barry


Emanuel Barry added the comment:

With the existence of multiple sum() functions (and potentially multiple 
product() functions), would it be worth it to group these all into one module? 
It also doesn't help that there is an itertools.product function that has yet 
another purpose.

I maintain my stance that this doesn't meet the bar for entry in the builtins, 
but adding this to the stdlib is much more reasonable (and likely).

--
title: product function patch -> Add a product() function to the standard 
library

___
Python tracker 

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

[issue27440] Trigonometric bug

2016-07-02 Thread Shubham Singh


New submission from Shubham Singh:

The value of sine and tangent, using math module is showing wrong.Screenshot is 
attached.

--
components: Extension Modules, Windows
files: Sin.jpg
messages: 269711
nosy: ShubhamSingh.er, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Trigonometric bug
type: resource usage
versions: Python 3.5
Added file: http://bugs.python.org/file43606/Sin.jpg

___
Python tracker 

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

[issue26137] [idea] use the Microsoft Antimalware Scan Interface

2016-07-02 Thread Alexander Riccio


Alexander Riccio added the comment:

It's not just Stuxnet, as at least one other Advanced Persistent Threat uses 
that tactic. An APT (likely Russian intelligence) recently used encoded 
PowerShell to break into the Democratic National Committe: 
https://www.crowdstrike.com/blog/bears-midst-intrusion-democratic-national-committee/

>From that article:

> This one-line powershell command, stored only in WMI database, establishes an 
> encrypted connection to C2 and downloads additional powershell modules from 
> it, executing them in memory.

(As a fun coincidence, they also used py2exe to distribute other modules, which 
is kinda like a separate interpreter using safe_exec)

--

___
Python tracker 

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

[issue26137] [idea] use the Microsoft Antimalware Scan Interface

2016-07-02 Thread Alexander Riccio


Alexander Riccio added the comment:

We might want to use some kind of Group Policy setting, for the same reason 
that many Windows security configuration options are there, and that DoD STIGs 
for Windows https://www.stigviewer.com/stig/windows_8_8.1/ are almost totally 
about configuring Group Policy settings.

--

___
Python tracker 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

2016-07-02 Thread Mathieu Dupuy


Mathieu Dupuy added the comment:

Hi.
I'm back, and willing to move forward on this issue. With the new code layout, 
the compiled regexes  now lay in datetime classes as class attributes. Will it 
be possible to import date, time and datetime from datetime.py in _datetime.c 
without a problem ?

By the way, I just discovered, that the way we treat microseconds differs from 
the strptime one : we are smarter read every digits and smartly round to six, 
strptime doesn't go that far and just *truncate* to this. Should go that way, 
for consistency with what strptime does, maybe ?

--

___
Python tracker 

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

[issue27441] redundant assignments to ob_size of new ints that _PyLong_New returned

2016-07-02 Thread Oren Milman


New submission from Oren Milman:

 current state 
In six different functions, the following happens:
1. Function x calls _PyLong_New, with var y as the size argument.
* Among others, _PyLong_New sets the ob_size of the new int to y (the 
size argument it received).
2. Function x sets the ob_size of the new int to y, even though y is 
already the value of ob_size.

The functions in which this happens are:
1. in Objects/longobject.c:
- PyLong_FromUnsignedLong
- PyLong_FromLongLong
- PyLong_FromUnsignedLongLong
- PyLong_FromSsize_t
- PyLong_FromSize_t
2. in Python/marshal.c:
- r_PyLong

With regard to relevant changes made in the past, it seems that the redundant 
assignment was added (in each of these six functions) on the last major 
rewriting of the function, or when the function was first added, and remained 
there to this day.

The revisions in which the redundant assignments were added:
1. changeset 18114 (https://hg.python.org/cpython/rev/31cd0db0f09f):
- PyLong_FromUnsignedLong
2. changeset 38307 (https://hg.python.org/cpython/rev/5a63369056a7):
- PyLong_FromLongLong
- PyLong_FromUnsignedLongLong
3. changeset 46460 (https://hg.python.org/cpython/rev/b04f2052e812):
- PyLong_FromSize_t
- PyLong_FromSsize_t
4. changeset 52215 (https://hg.python.org/cpython/rev/bb5de24a343f):
- r_PyLong


 proposed changes 
Remove these six redundant assignments.


 diff 
The proposed patches diff file is attached.


 tests 
I built the patched CPython for x86, and played with it a little. Everything 
seemed to work as usual. 

In addition, I ran 'python_d.exe -m test -j3' (on my 64-bit Windows 10) with 
and without the patches, and got quite the same output.
The outputs of both runs are attached.

--
components: Interpreter Core
files: CPythonTestOutput.txt
messages: 269715
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: redundant assignments to ob_size of new ints that _PyLong_New returned
type: performance
Added file: http://bugs.python.org/file43607/CPythonTestOutput.txt

___
Python tracker 

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

[issue27441] redundant assignments to ob_size of new ints that _PyLong_New returned

2016-07-02 Thread Oren Milman


Changes by Oren Milman :


Added file: http://bugs.python.org/file43609/patchedCPythonTestOutput_ver1.txt

___
Python tracker 

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

[issue27441] redundant assignments to ob_size of new ints that _PyLong_New returned

2016-07-02 Thread Oren Milman


Changes by Oren Milman :


--
keywords: +patch
Added file: http://bugs.python.org/file43608/issue27441_ver1.diff

___
Python tracker 

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

[issue27442] expose Android API level in sys.implementation


New submission from Xavier de Gaye:

Expose the Android API level that python was built against, in 
sys.implementation as _android_api.
Purposes:
* Identify the platform as Android.
* Allow detecting a mismatch with the runtime sdk version returned by 
platform.android_ver() (issue 26855), for example when the runtime sdk is lower 
than the built API level.

--
assignee: xdegaye
components: Interpreter Core
messages: 269716
nosy: haypo, xdegaye
priority: normal
severity: normal
status: open
title: expose Android API level in sys.implementation
type: enhancement
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

[issue27442] expose Android API level in sys.implementation


Xavier de Gaye added the comment:

Patch added.

--
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file43610/android_api.patch

___
Python tracker 

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

[issue26865] Meta-issue: support of the android platform


Xavier de Gaye added the comment:

issue #27442: expose Android API level in sys.implementation

--
dependencies: +expose Android API level in sys.implementation

___
Python tracker 

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

[issue27141] Fix collections.UserList shallow copy

2016-07-02 Thread Pascal Chambon


Changes by Pascal Chambon :


--
nosy: +pakal

___
Python tracker 

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

[issue27442] expose Android API level in sys.implementation

2016-07-02 Thread Chi Hsuan Yen


Chi Hsuan Yen added the comment:

I don't think sys.implementation is a good place to contain the information of 
the underlying platform. By Doc/sys.rst:

An object containing information about the implementation of the currently 
running Python interpreter.

--
nosy: +Chi Hsuan Yen

___
Python tracker 

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

[issue27442] expose Android API level in sys.implementation

2016-07-02 Thread Chi Hsuan Yen


Chi Hsuan Yen added the comment:

Sorry, it's Doc/library/sys.rst

--

___
Python tracker 

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

[issue27442] expose Android API level in sys.implementation


Xavier de Gaye added the comment:

> I don't think sys.implementation is a good place to contain the information 
> of the underlying platform.

Quite the opposite, the ndk API level gives an information about the 
implementation of the currently running Python interpreter saying that this 
Python has been built against this version of Android libc identified by this 
API level.

--

___
Python tracker 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

2016-07-02 Thread Anders Hovmöller


Anders Hovmöller added the comment:

> 
> By the way, I just discovered, that the way we treat microseconds differs 
> from the strptime one : we are smarter read every digits and smartly round to 
> six, strptime doesn't go that far and just *truncate* to this. Should go that 
> way, for consistency with what strptime does, maybe ?

I'm strongly against silently throwing away data and calling it even. If we 
want compatibility with strptime then it should be a separate flag like 
silent_truncate_milliseconds=True. 

On another matter: does the latest proposed code pass the tests in my ISO8601 
implementation that I mentioned 2013 (! time flies)?

--

___
Python tracker 

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

[issue27366] PEP487: Simpler customization of class creation

2016-07-02 Thread Martin Teichmann


Martin Teichmann added the comment:

This is a C implementation of PEP 487, directly in the Python core

--
Added file: http://bugs.python.org/file43611/pep487a.patch

___
Python tracker 

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

[issue27442] expose Android API level in sys.implementation

2016-07-02 Thread Chi Hsuan Yen


Chi Hsuan Yen added the comment:

OK I see the rationale.

--

___
Python tracker 

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

[issue27440] Trigonometric bug

2016-07-02 Thread R. David Murray


R. David Murray added the comment:

I would imagine that this is a consequence of platform-dependent floating point 
math.  Not to mention working with an irrational number.  See also issue 8309.

--
nosy: +mark.dickinson, r.david.murray
type: resource usage -> behavior

___
Python tracker 

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

[issue27442] expose Android API level in sys.implementation

2016-07-02 Thread STINNER Victor


STINNER Victor added the comment:

I woupd prefer to have a public attribute.

--

___
Python tracker 

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

[issue27422] Deadlock when mixing threading and multiprocessing


Davin Potts added the comment:

It would be nice to find an appropriate place to document the solid general 
guidance Raymond provided; though merely mentioning it somewhere in the docs 
will not translate into it being noticed.  Not sure where to put it just yet...

Martin:  Is there a specific situation that prompted your discovering this 
behavior?  Mixing the spinning up of threads with the forking of processes 
requires appropriate planning to avoid problems and achieve desired 
performance.  If you have a thoughtful design to your code but are still 
triggering problems, can you share more of the motivation?


As a side note, this is more appropriately labeled as a 'behavior' rather than 
a 'crash' -- the Python executable does not crash in any way but merely hangs 
in an apparent lock contention.

--
nosy: +davin
type: crash -> behavior

___
Python tracker 

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

[issue27440] Trigonometric bug

2016-07-02 Thread Tim Peters


Tim Peters added the comment:

Python's floats are emphatically not doing symbolic arithmetic - they use the 
platform's binary floating point facilities, which can only represent a subset 
of rationals exactly.  All other values are approximated.

In particular, this shows the exact value of the approximation used for pi:

>>> import math
>>> from decimal import Decimal
>>> Decimal(math.pi)
Decimal('3.141592653589793115997963468544185161590576171875')

That isn't the mathematical pi, but is the closest approximation representable 
as a platform Python binary float (same as type "double" in the platform C).

Here's the difference between math.pi and a better decimal approximation to pi:

>>> Decimal(math.pi) - Decimal("3.141592653589793238462643383279502884")
Decimal('-1.224646799147353177224094238E-16')

So math.pi is a little bit smaller than the mathematical pi.

Mathematically, using the subtraction formula for sine:
 
sin(pi - e) = sin(pi)*cos(e) - sin(e)*cos(pi) =
0*cos(e) - sin(e)*-1 =
0 + sin(e) =
sin(e)

So mathematically sin(pi - e) = sin(e), and if |e| is close to 0 then sin(e) ~= 
e.

For that reason, it's not a coincidence that the result you got for 
math.sin(math.pi) = 1.22464...e-16 is approximately equal to the difference 
(shown above) between the mathematical pi and math.pi.  It's not due to gross 
inaccuracy in sine, it's due to that pi isn't exactly representable as a Python 
float.

Note that this has nothing to do with Python specifically.  You'll see the same 
kind of behaviors in any language exposing the platform floating point 
facilities.

If you need to do symbolic computations, then you need much fancier facilities.

--
nosy: +tim.peters
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

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

[issue27443] __length_hint__() of bytearray iterator can return negative integer


New submission from Serhiy Storchaka:

>>> ba = bytearray(b'ab')
>>> it = iter(ba)
>>> next(it)
97
>>> ba.clear()
>>> list(it)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: __length_hint__() should return >= 0

Proposed patch fixes this issue.

--
components: Interpreter Core
files: bytearray_iterator_length_hint.patch
keywords: patch
messages: 269729
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: __length_hint__() of bytearray iterator can return negative integer
type: behavior
versions: Python 3.5, Python 3.6
Added file: 
http://bugs.python.org/file43612/bytearray_iterator_length_hint.patch

___
Python tracker 

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

[issue27438] Refactor simple iterators implementation


Serhiy Storchaka added the comment:

Thank you for your detailed explanation Raymond.

In any case, the work on this patch helped to find a bug in bytearray iterator 
(issue27443).

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

___
Python tracker 

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

[issue26765] Factor out common bytes and bytearray implementation


Changes by Serhiy Storchaka :


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

[issue26800] Don't accept bytearray as filenames part 2


Serhiy Storchaka added the comment:

Ping.

--

___
Python tracker 

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

[issue27439] Add a product() function to the standard library


Raymond Hettinger added the comment:

Actually, Guido already vetoed the idea: http://bugs.python.org/issue1093

--
nosy: +rhettinger
resolution:  -> rejected
status: open -> closed

___
Python tracker 

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

[issue27081] Cannot capture sys.stderr output from an uncaught exception in a multiprocessing Process using a multiprocessing Queue


Davin Potts added the comment:

I took the example snippet and cleaned things up a bit, adding some crude 
timestamping and commentary.  (Attached)

In the example, when the Process finally dies, a lot of information has been 
put onto the Queue but it hasn't necessarily had enough time to be synced to 
the parent process so it may be only a truncated subset of the data that 
remains available/visible/retrievable on the parent.  How much data gets synced 
to the parent depends on many factors and should even vary from one run to 
another.

That is to say that a multiprocessing.Queue is not going to hold up a dying 
process to finish communicating data to other processes.

--
Added file: http://bugs.python.org/file43613/issue27081.py

___
Python tracker 

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

[issue27422] Deadlock when mixing threading and multiprocessing


Raymond Hettinger added the comment:

FWIW, this isn't even a Python specific behavior.  It is just how threads, 
locks, and processes work (or in this case don't work).  The code is doing what 
it is told to do which happens to not be what you want (i.e. a user bug rather 
than a Python bug).

I think a FAQ entry would be a reasonable place to mention this (it comes up 
more often than one would hope).

--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python
resolution:  -> not a bug

___
Python tracker 

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

[issue26903] ProcessPoolExecutor(max_workers=64) crashes on Windows


Changes by Davin Potts :


--
nosy: +davin

___
Python tracker 

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

[issue27443] __length_hint__() of bytearray iterator can return negative integer


Raymond Hettinger added the comment:

This patch looks correct.  Nice catch.

--

___
Python tracker 

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

[issue27081] Cannot capture sys.stderr output from an uncaught exception in a multiprocessing Process using a multiprocessing Queue

2016-07-02 Thread ppperry


ppperry added the comment:

I believe that regardless of the number of prints to sys.stderr that happen 
before the recursion error, all of them will get sent to the parent. The 
problem is that the queue is flushed before the uncaught error is sent to 
stderr, not after.

--

___
Python tracker 

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

[issue27081] Cannot capture sys.stderr output from an uncaught exception in a multiprocessing Process using a multiprocessing Queue

2016-07-02 Thread Emanuel Barry


Emanuel Barry added the comment:

Worth of note: #26823 will actually change printing to stderr for recursion 
errors (if/when it gets merged that is; I don't know what's holding it up). It 
might be interesting to see if you can still witness this issue with the patch 
applied.

--
nosy: +ebarry

___
Python tracker 

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

[issue27444] Python doesn't build due to test_float.py broken on non-IEEE machines

2016-07-02 Thread Greg Stark


New submission from Greg Stark:

The file Test/test_float.py has a decorator for tests that must be skipped on 
non-IEEE machines. However just eyeballing it it seems there are a few tests 
that test behaviour around Inf and NaN that are lacking this decorator.

Alternately it's possible this is actually a core interpreter bug where even 
code which is never called is now triggering floating point exceptions due to 
some constant propagation optimization or something like that.

To reproduce, try to install on a non-IEE machine such as a VAX and your 
install will crash with:

Compiling 
/usr/pkgsrc/lang/python27/work/.destdir/usr/pkg/lib/python2.7/test/test_filecmp.py
 ...
Compiling 
/usr/pkgsrc/lang/python27/work/.destdir/usr/pkg/lib/python2.7/test/test_fileinput.py
 ...
Compiling 
/usr/pkgsrc/lang/python27/work/.destdir/usr/pkg/lib/python2.7/test/test_fileio.py
 ...
Compiling 
/usr/pkgsrc/lang/python27/work/.destdir/usr/pkg/lib/python2.7/test/test_float.py
 ...
[1]   Floating point exception (core dumped) PYTHONPATH=/usr/...
*** Error code 136

Stop.
make: stopped in /usr/pkgsrc/lang/python27/work/Python-2.7.10
*** Error code 1


I do happen to have been compiling with -O0 -g so I have a core file and a 
binary with symbols (if you have a VAX gdb...) but here's the backtrace:

#0  0x7f687748 in float_mul (v=0x7ee82f54, w=0x7ee82f54, 2129145684, 
2129145684) at Objects/floatobject.c:658
#1  0x7f65eb56 in binary_op1 (v=0x7ee82f54, w=0x7ee82f54, op_slot=8, 
2129145684, 2129145684, 8) at Objects/abstract.c:945
#2  0x7f65f572 in PyNumber_Multiply (v=0x7ee82f54, w=0x7ee82f54, 2129145684, 
2129145684) at Objects/abstract.c:1216
#3  0x7f72e573 in fold_binops_on_constants (codestr=0x7f28b169 "d\001", 
consts=0x7f0b5dcc, 2133373289, 2131451340)
at Python/peephole.c:108
#4  0x7f72f56c in PyCode_Optimize (code=0x7f3316a8, consts=0x7f0b5dcc, 
names=0x7f0948ec, 
lineno_obj=0x7f0b5840, 2134054568, 2131451340, 2131314924, 2131449920) at 
Python/peephole.c:482
#5  0x7f71d3ad in makecode (c=0x7fffc810, a=0x7fffc5b0, 2147469328, 2147468720) 
at Python/compile.c:3883
#6  0x7f71d77d in assemble (c=0x7fffc810, addNone=1, 2147469328, 1) at 
Python/compile.c:3999
#7  0x7f717527 in compiler_function (c=0x7fffc810, s=0x7eb82bf0, 2147469328, 
2125999088) at Python/compile.c:1422
#8  0x7f719552 in compiler_visit_stmt (c=0x7fffc810, s=0x7eb82bf0, 2147469328, 
2125999088) at Python/compile.c:2122
#9  0x7f716d00 in compiler_body (c=0x7fffc810, stmts=0x7ebc88f8, 2147469328, 
2126285048) at Python/compile.c:1209
#10 0x7f717882 in compiler_class (c=0x7fffc810, s=0x7ebd2608, 2147469328, 
2126325256) at Python/compile.c:1477
#11 0x7f719564 in compiler_visit_stmt (c=0x7fffc810, s=0x7ebd2608, 2147469328, 
2126325256) at Python/compile.c:2124
#12 0x7f716d00 in compiler_body (c=0x7fffc810, stmts=0x7eb53010, 2147469328, 
2125803536) at Python/compile.c:1209
#13 0x7f716db6 in compiler_mod (c=0x7fffc810, mod=0x7ebe1438, 2147469328, 
2126386232) at Python/compile.c:1229
#14 0x7f7151f3 in PyAST_Compile (mod=0x7ebe1438, filename=0x7f2c15b4 
"/usr/pkg/lib/python2.7/test/test_float.py", 
flags=0x7fffc8c0, arena=0x7f3482f0, 2126386232, 2133595572, 2147469504, 
2134147824) at Python/compile.c:292
#15 0x7f733849 in Py_CompileStringFlags (
str=0x7eb43014 "\nimport unittest, struct\nimport os\nfrom test import 
test_support\nimport math\nfrom math import isinf, isnan, copysign, 
ldexp\nimport operator\nimport random\nimport fractions\nimport sys\nimport 
time\n\nINF ="..., 
filename=0x7f2c15b4 "/usr/pkg/lib/python2.7/test/test_float.py", start=257, 
flags=0x7fffc8c0, 2125738004, 2133595572, 257, 2147469504) at 
Python/pythonrun.c:1428
#16 0x7f705dc6 in builtin_compile (self=0x0, args=0x7f08f914, kwds=0x0, 0, 
2131294484, 0) at Python/bltinmodule.c:559
#17 0x7f6a5b8a in PyCFunction_Call (func=0x7f32a96c, arg=0x7f08f914, kw=0x0, 
2134026604, 2131294484, 0)
at Objects/methodobject.c:85
#18 0x7f713023 in call_function (pp_stack=0x7fffca44, oparg=3, 2147469892, 3) 
at Python/ceval.c:4035
#19 0x7f70fe32 in PyEval_EvalFrameEx (f=0x7f29568c, throwflag=0, 2133415564, 0) 
at Python/ceval.c:2681
#20 0x7f711523 in PyEval_EvalCodeEx (co=0x7f25cad0, globals=0x7f29a3e4, 
locals=0x0, args=0x7f3b7874, argcount=4, 
kws=0x7f3b7884, kwcount=0, defs=0x7f29d3a8, defcount=3, 
closure=0x0, 2133183184, 2133435364, 0, 2134603892, 4, 2134603908, 0, 
2133447592, 3, 0) at Python/ceval.c:3267
#21 0x7f71337c in fast_function (func=0x7f29b924, pp_stack=0x7fffcd30, n=4, 
na=4, nk=0, 2133440804, 2147470640, 4, 4, 0)
at Python/ceval.c:4131
#22 0x7f713106 in call_function (pp_stack=0x7fffcd30, oparg=4, 2147470640, 4) 
at Python/ceval.c:4056
#23 0x7f70fe32 in PyEval_EvalFrameEx (f=0x7f3b76ec, throwflag=0, 2134603500, 0) 
at Python/ceval.c:2681
#24 0x7f711523 in PyEval_EvalCodeEx (co=0x7f23ecc8, globals=0x7f33e714, 
locals=0x0, args=0x7f2d1198, argcount=5, 
kws=0x7f2d11ac, kwcount=0, defs=0x7f24bfd8, defcount=4, 
closure=0x0, 2133060808, 213410

[issue27081] Cannot capture sys.stderr output from an uncaught exception in a multiprocessing Process using a multiprocessing Queue

2016-07-02 Thread ppperry


ppperry added the comment:

This issue isn't specific to recursion errors. It only occurs when the error 
message is long enough, so #26823 would fix the RecursionError case, but it 
would still happen when someone calls a function with a billion-character-long 
name that raises an error, for example.

--

___
Python tracker 

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

[issue27445] Charset instance not passed to set_payload()

2016-07-02 Thread Claude Paroz


New submission from Claude Paroz:

In issue #16324, I contributed an improvement so as MIMEText __init__ accept 
Charset instances, not only encoding strings. The use case is from Django where 
we customize the Charset.body_encoding before passing it to the MIMEText 
initialization.

Unfortunately, what I didn't notice when Berker adapted my patch is that the 
Charset is casted to its string representation for the whole method, while I 
initially intended to let the unchanged Charset passed to self.set_payload. And 
the test I suggested was not smart enough to detect that.

--
components: email
messages: 269740
nosy: barry, claudep, r.david.murray
priority: normal
severity: normal
status: open
title: Charset instance not passed to set_payload()
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

[issue27445] Charset instance not passed to set_payload()

2016-07-02 Thread Claude Paroz


Changes by Claude Paroz :


--
keywords: +patch
Added file: http://bugs.python.org/file43614/issue27445.diff

___
Python tracker 

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

[issue27444] Python doesn't build due to test_float.py broken on non-IEEE machines


Changes by Raymond Hettinger :


--
nosy: +mark.dickinson, tim.peters

___
Python tracker 

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

[issue26624] Windows hangs in call to CRT setlocale()

Terry J. Reedy added the comment:

I have recent gotten
WARN: ucrtbased contains known issues. Please update Visual Studio or the
Windows SDK.
See: http://bugs.python.org/issue26624
F:\Python\dev\36\PCbuild\python.vcxproj(91,5): warning MSB3073: The command
""F:\Python\dev\36\PCBuild\win32\python_d.exe"
"F:\Python\dev\36\PC\validate_ucrtbase.py" ucrtbased" exited with code 1.

but Python still ran for me. Today, I recompiled, and python stopped running
when I try to either run IDLE or patchcheck. To eliminate the old .dll as a
cause, I tried to 'update'. How to do so?

I started VS by double clicking pcbuild/python.vcxproj. The first barrier was
that Community 2015 is only good for 30 days (the compiler invoked by build.bat
still ran) and I could not access the menu. Once I got the license renewed, so
VS ran, there is no Update entry on Help or anywhere else on the menu that I
could find. (I seem to remember that VC Express updated automatically.)

When I started VS2015 from the start menu instead, there was a splash screen
with News and a link to a brand new Update 3.
https://blogs.msdn.microsoft.com/visualstudio/2016/06/27/visual-studio-2015-update-3-and-net-core-1-0-available-now/

I clicked the first link and downloaded vs2015.3.exe. ran it, and left the
minimal selection of components alone. After 3 GB downloaded and installed,
there are error messages that *cannot* be copied and pasted. Here is a summary:
1. VS update prereq: Installer failed. bad hash 0x80091007
(did this mess up everything?)
2. Team J. Serv CTP! SToryboarding Pack file not found 0x80070002
(This does not seem like something I requested.)
3. VC++IDE base resource package ditto as to error.
(Perhaps not needed for build.bat)
Log file attached. I will restart and see what happens.

--
nosy: +terry.reedy
Added file: http://bugs.python.org/file43615/dd_vs_community_20160702172149.log

___
Python tracker

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

[issue26624] Windows hangs in call to CRT setlocale()


Terry J. Reedy added the comment:

After the 'update', the compiler ran and re-linked all the targets.  The 
warning about the old .dll remains.  Perhaps I should remove and re-install?

The crash also remain.  I'll backdate the repository to mid-June when I 
successfully compiled and ran and see if I can find a particular commit causing 
the problem.

--

___
Python tracker 

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

[issue26765] Factor out common bytes and bytearray implementation


Terry J. Reedy added the comment:

Serhiy, compiling 3.6 on Windows after this patch lets it start, but causes it 
to crash both importing tkinter and running patchcheck.  Compiling 3.6 after 
your previous patch for #27007 and the test suite runs without error.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue26624] Windows hangs in call to CRT setlocale()


Terry J. Reedy added the comment:

The problem was the last patch, for #26765.  In spite of the faulty .dll, the 
test suite ran OK.

--

___
Python tracker 

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

[issue27405] Ability to trace Tcl commands executed by Tkinter


Terry J. Reedy added the comment:

After re-compiling, import tkinter crashed 3.6.  Reversion did not help.  After 
trying to update VS2015 (not successfully), and doing a binary search, it was 
your patch for #26765.

--

___
Python tracker 

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

[issue27444] Python doesn't build due to test_float.py broken on non-IEEE machines

2016-07-02 Thread R. David Murray


R. David Murray added the comment:

It looks like you are in the compiling step, so the decorators have nothing to 
do with it.  This does appear to be a platform issue in the interpreter core, 
and you'll have to track it down since we don't have access to your platform 
(at least, I don't think any of the core devs are set up to test on VAX).

--
nosy: +r.david.murray

___
Python tracker 

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

[issue26765] Factor out common bytes and bytearray implementation


Terry J. Reedy added the comment:

Checking, I see that 3 of 4 Windows buildbots ran with this patch, so there 
must be something significantly different about my VS install with respect to 
this particular patch.  #26624 might or might not have something to do with it 
(see my posts today).  I can't tell from the logs which update the buildbots 
are running.

The fourth, x86windows7 crashed before running anything 
(http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/11283/steps/test/logs/stdio),
 after having previously run part way through the tests.  It *might* have a 
similar problem, or might not.

--

___
Python tracker 

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

[issue27442] expose Android API level in sys.implementation

2016-07-02 Thread Ned Deily


Ned Deily added the comment:

Typically, for other sorts of build configuration data, we have relied on 
extracting that from the ./configure-produced Makefile and making it available 
via sysconfig.get_config_var().  I think we should be cautious about bloating 
sys.implementation with platform-specific data unless there is an overriding 
need for it, for example, if it is needed during interpreter initialization 
before sysconfig can be initialized.  If not, I'd look at adding the needed 
values as configuration variables in configure.ac.

--
nosy: +ned.deily

___
Python tracker 

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

[issue27363] Complex numbers with negative zero parts do not roundtrip properly

2016-07-02 Thread ppperry


Changes by ppperry :


--
title: Complex numbers with negative zero imaginary parts do not roundtrip 
properly -> Complex numbers with negative zero parts do not roundtrip properly

___
Python tracker 

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

[issue27440] Trigonometric bug

2016-07-02 Thread Steven D'Aprano


Steven D'Aprano added the comment:

I know this issue is closed, but for future reference, ShubhamSingh.er, if you 
submit any further bug reports, please don't submit screen shots unless 
necessary. Just copy and paste the text from your terminal into the issue 
tracker. A screen shot is more work for you, less useful to us, and impossible 
for the blind and visually-impaired to work with using a screen reader.

--
nosy: +steven.daprano

___
Python tracker 

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

[issue27081] Cannot capture sys.stderr output from an uncaught exception in a multiprocessing Process using a multiprocessing Queue