[issue33823] A BUG in concurrent/asyncio
New submission from Python++ : ProcessPoolExecutor cannot specify the number of cores when running the Muti-Sub Event Loops, which results in the resulting statistics of the last code run cannot be promised to be separated. I'm deep hoping some genius can propose a solution and fix these problems. -- components: asyncio messages: 319229 nosy: Python++, asvetlov, yselivanov priority: normal severity: normal status: open title: A BUG in concurrent/asyncio type: behavior versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue33823> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33823] A BUG in concurrent/asyncio
Change by Python++ : Added file: https://bugs.python.org/file47637/BUG for concurrent.futures(Found by william).py ___ Python tracker <https://bugs.python.org/issue33823> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33823] A BUG in concurrent/asyncio
Python++ added the comment: First Kind of resutl sets: = Process-2:<4816> is ProcessExecuting [0] MainThread:<4816> is ThreadExecuting [0] exe_iter:0 sub_iter:0 Run for Wheel and result:0 callback number:1 MainThread:<4816> is ThreadExecuting [1] exe_iter:0 sub_iter:1 Run for Wheel and result:2 callback number:2 Process-1:<4512> is ProcessExecuting [1] MainThread:<4512> is ThreadExecuting [0] exe_iter:1 sub_iter:0 Run for Wheel and result:0 callback number:1 MainThread:<4512> is ThreadExecuting [1] exe_iter:1 sub_iter:1 Run for Wheel and result:2 callback number:2 == Program runs with different Threads: Tread ID: 4816 and 4512 callback numbers are 1, 2; 1, 2 Second Kind of resutl sets: == Process-1:<7360> is ProcessExecuting [0] MainThread:<7360> is ThreadExecuting [0] exe_iter:0 sub_iter:0 Run for Wheel and result:0 callback number:1 MainThread:<7360> is ThreadExecuting [1] exe_iter:0 sub_iter:1 Run for Wheel and result:2 callback number:2 Process-1:<7360> is ProcessExecuting [1] MainThread:<7360> is ThreadExecuting [0] exe_iter:1 sub_iter:0 Run for Wheel and result:0 callback number:3 MainThread:<7360> is ThreadExecuting [1] exe_iter:1 sub_iter:1 Run for Wheel and result:2 callback number:4 = Program runs with the same and only Thread: Tread ID: 7360 callback numbers are 1, 2; 3, 4 Based on the above situation, it is impossible to ensure that multiple processes will run the program all the way by employing Process Pool. 2018-06-11 2:18 GMT+08:00 Yury Selivanov : > > Yury Selivanov added the comment: > > > which results in the resulting statistics of the last code run cannot be > promised to be separated. > > I'm sorry but I cannot parse your message and the attached code snippet. > Please try to formulate the actual bug/feature request more clearly. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue33823> > ___ > -- ___ Python tracker <https://bugs.python.org/issue33823> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33823] A BUG in concurrent/asyncio
Python++ added the comment: First Kind of resutl sets: = Process-2:<4816> is ProcessExecuting [0] MainThread:<4816> is ThreadExecuting [0] exe_iter:0 sub_iter:0 Run for Wheel and result:0 callback number:1 MainThread:<4816> is ThreadExecuting [1] exe_iter:0 sub_iter:1 Run for Wheel and result:2 callback number:2 Process-1:<4512> is ProcessExecuting [1] MainThread:<4512> is ThreadExecuting [0] exe_iter:1 sub_iter:0 Run for Wheel and result:0 callback number:1 MainThread:<4512> is ThreadExecuting [1] exe_iter:1 sub_iter:1 Run for Wheel and result:2 callback number:2 == Program runs with different Threads: Tread ID: 4816 and 4512 callback numbers are 1, 2; 1, 2 Second Kind of resutl sets: == Process-1:<7360> is ProcessExecuting [0] MainThread:<7360> is ThreadExecuting [0] exe_iter:0 sub_iter:0 Run for Wheel and result:0 callback number:1 MainThread:<7360> is ThreadExecuting [1] exe_iter:0 sub_iter:1 Run for Wheel and result:2 callback number:2 Process-1:<7360> is ProcessExecuting [1] MainThread:<7360> is ThreadExecuting [0] exe_iter:1 sub_iter:0 Run for Wheel and result:0 callback number:3 MainThread:<7360> is ThreadExecuting [1] exe_iter:1 sub_iter:1 Run for Wheel and result:2 callback number:4 = Program runs with the same and only Thread: Tread ID: 7360 callback numbers are 1, 2; 3, 4 Based on the above situation, it is impossible to ensure that multiple processes will run the program all the way by employing Process Pool. 2018-06-11 15:09 GMT+08:00 Python++ : > > Python++ added the comment: > > First Kind of resutl sets: > > = > > Process-2:<4816> is ProcessExecuting [0] > MainThread:<4816> is ThreadExecuting [0] > exe_iter:0 sub_iter:0 > Run for Wheel and result:0 > callback number:1 > MainThread:<4816> is ThreadExecuting [1] > exe_iter:0 sub_iter:1 > Run for Wheel and result:2 > callback number:2 > Process-1:<4512> is ProcessExecuting [1] > MainThread:<4512> is ThreadExecuting [0] > exe_iter:1 sub_iter:0 > Run for Wheel and result:0 > callback number:1 > MainThread:<4512> is ThreadExecuting [1] > exe_iter:1 sub_iter:1 > Run for Wheel and result:2 > callback number:2 > == > Program runs with different Threads: > Tread ID: 4816 and 4512 > callback numbers are 1, 2; 1, 2 > > > Second Kind of resutl sets: > > == > Process-1:<7360> is ProcessExecuting [0] > MainThread:<7360> is ThreadExecuting [0] > exe_iter:0 sub_iter:0 > Run for Wheel and result:0 > callback number:1 > MainThread:<7360> is ThreadExecuting [1] > exe_iter:0 sub_iter:1 > Run for Wheel and result:2 > callback number:2 > Process-1:<7360> is ProcessExecuting [1] > MainThread:<7360> is ThreadExecuting [0] > exe_iter:1 sub_iter:0 > Run for Wheel and result:0 > callback number:3 > MainThread:<7360> is ThreadExecuting [1] > exe_iter:1 sub_iter:1 > Run for Wheel and result:2 > callback number:4 > = > > Program runs with the same and only Thread: > Tread ID: 7360 > callback numbers are 1, 2; 3, 4 > > Based on the above situation, it is impossible to ensure that multiple > processes will run the program all the way by employing Process Pool. > > 2018-06-11 2:18 GMT+08:00 Yury Selivanov : > > > > > Yury Selivanov added the comment: > > > > > which results in the resulting statistics of the last code run cannot > be > > promised to be separated. > > > > I'm sorry but I cannot parse your message and the attached code snippet. > > Please try to formulate the actual bug/feature request more clearly. > > > > -- > > > > ___ > > Python tracker > > <https://bugs.python.org/issue33823> > > ___ > > > > -- > > ___ > Python tracker > <https://bugs.python.org/issue33823> > ___ > -- ___ Python tracker <https://bugs.python.org/issue33823> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32810] Expose ags_gen and agt_gen in asynchronous generators
Andrew Svetlov added the comment: Make sense at first glaze. -- ___ Python tracker <https://bugs.python.org/issue32810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32816] Python's json dumps/loads make integer keys of the dict str
New submission from Korabelnikov Aleksandr :
when i serialize and deserialize python built-in structure I'm expect output
same as input
arr2 = [1,2,'3']
arr2_json = json.dumps(arr2)
json.loads(arr2_json)
Out[16]: [1, 2, '3']
BUT when I'm tring do it with dict I got str keys instead of integer
dict1 = {0: 'object0', '1': 'object2'}
json1 = json.dumps(dict1)
json.loads(json1)
Out[6]: {'0': 'object0', '1': 'object2'}
Notice keys must be [0, '1'] but actually are ['0', '1']
--
components: Library (Lib)
messages: 311951
nosy: solin
priority: normal
severity: normal
status: open
title: Python's json dumps/loads make integer keys of the dict str
type: behavior
versions: Python 3.5
___
Python tracker
<https://bugs.python.org/issue32816>
_______
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32820] Add bits method to ipaddress
Eric Osborne added the comment:
It is often useful to have non-decimal representations of IP addresses.
Hex shows up a lot in sniffer traces, which is why I wanted to provide
__index__, but that's not going to happen. I use binary a lot when
teaching subnet masking and address summarization - if you line up bit
patterns it's much easier to show how things lay out. It's easy enough to
use bin(int(addr)) but that doesn't zero-pad the string it returns. I find
myself doing something like
In [23]: a
Out[23]: IPv4Address('1.2.3.4')
In [24]: x = bin(int(a))[2:]
In [25]: full_x = '0b' + ('0' * (32-len(x)) + x)
In [26]: full_x
Out[26]: '0b0001001000110100'
Although, as Eric Smith has pointed out, there's a one liner way to do
this. But if an IP address can represent itself as an integer (IMO the
least useful form) it should have at least a binary representation, and
lack of a seperate __bin__ means this is as close as I could get.
eric
On Mon, Feb 12, 2018 at 7:39 AM Christian Heimes
wrote:
>
> Christian Heimes added the comment:
>
> I agree with Serhiy and Eric. It's a needless complication of the module.
> What's the actual use case of printing a human readable bit representation
> of an IP address?
>
> --
> nosy: +christian.heimes
>
> ___
> Python tracker
> <https://bugs.python.org/issue32820>
> ___
>
--
___
Python tracker
<https://bugs.python.org/issue32820>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32852] trace changes sys.argv from list to tuple
New submission from Kyle Altendorf : Normally sys.argv is a list but when using the trace module sys.argv gets changed to a tuple. In my case this caused an issue with running an entry point due to the line: sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0]) When researching I found: https://stackoverflow.com/questions/47688568/trace-sys-argv-args-typeerror-tuple-object-does-not-support-item-assig They point out where trace assigns a tuple to sys.argv. https://github.com/python/cpython/blob/master/Lib/trace.py#L708 I'll see what I can do to put together a quick patch. $ cat t.py import sys print(sys.version) print(type(sys.argv)) $ /home/altendky/.pyenv/versions/3.7.0a2/bin/python t.py 3.7.0a2 (default, Feb 15 2018, 11:20:36) [GCC 6.3.0 20170516] $ /home/altendky/.pyenv/versions/3.7.0a2/bin/python -m trace --trace t.py --- modulename: t, funcname: t.py(1): import sys t.py(3): print(sys.version) 3.7.0a2 (default, Feb 15 2018, 11:20:36) [GCC 6.3.0 20170516] t.py(5): print(type(sys.argv)) --- modulename: trace, funcname: _unsettrace trace.py(71): sys.settrace(None) -- components: Library (Lib) messages: 312213 nosy: altendky priority: normal severity: normal status: open title: trace changes sys.argv from list to tuple versions: Python 3.6, Python 3.7 _______ Python tracker <https://bugs.python.org/issue32852> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30449] Improve __slots__ datamodel documentation
Change by Mariatta Wijaya : -- stage: patch review -> backport needed ___ Python tracker <https://bugs.python.org/issue30449> ___ _______ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30622] Fix NPN guard for OpenSSL 1.1
Change by Christian Heimes : -- pull_requests: +5656 ___ Python tracker <https://bugs.python.org/issue30622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32970] Improve disassembly of the MAKE_FUNCTION instruction
Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +5707 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue32970> ___ _______ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31226] shutil.rmtree fails when target has an internal directory junction (Windows)
Change by Vidar Fauske : -- keywords: +patch pull_requests: +5764 stage: test needed -> patch review ___ Python tracker <https://bugs.python.org/issue31226> ___ _______ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32540] venv docs - doesn't match behavior
Jason R. Coombs added the comment: @jtrouverie: Yes, please do. Thanks! -- ___ Python tracker <https://bugs.python.org/issue32540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
