[issue35198] Build issue while compiling cpp files in AIX

2019-01-04 Thread Kevin


Kevin  added the comment:

Ah. We always compile with GCC, so would not have hit that particular problem.

--

___
Python tracker 

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



[issue35657] multiprocessing.Process.join() ignores timeout if child process use os.exec*()

2019-01-04 Thread Josh Rosenberg


Josh Rosenberg  added the comment:

Looks like the cause of the change was when os.pipe was changed to create 
non-inheritable pipes by default; if I monkey-patch 
multiprocessing.popen_fork.Popen._launch to use os.pipe2(0) instead of 
os.pipe() to get inheritable descriptors or just clear FD_CLOEXEC in the child 
with fcntl.fcntl(child_w, fcntl.F_SETFD, 0), the behavior returns to Python 2's 
behavior.

The problem is caused by the mismatch in lifetimes between the pipe fd and the 
child process itself; normally the pipe lives as long as the child process 
(it's never actually touched in the child process at all, so it just dies with 
the child), but when exec gets involved, the pipe is closed long before the 
child ends.

The code in Popen.wait that is commented with "This shouldn't block if wait() 
returned successfully" is probably the issue; wait() first waits on the parent 
side of the pipe fd, which returns immediately when the child execs and the 
pipe is closed. The code is assumes the poll on the process itself can be run 
in blocking (since the process should have ended already) but this assumption 
is wrong of course.

Possible solutions:

1. No code changes; document that exec in worker processes is unsupported (use 
subprocess, possibly with a preexec_fn, for this use case).

2. Precede the call to process_obj._bootstrap() in the child with 
fcntl.fcntl(child_w, fcntl.F_SETFD, 0) to clear the CLOEXEC flag on the child's 
descriptor, so the file descriptor remains open in the child post-exec. Using 
os.pipe2(0) instead of os.pipe() in _launch would also work and restore the 
precise 3.3 and earlier behavior, but it would introduce reintroduce race 
conditions with parent threads, so it's better to limit the scope to the child 
process alone, for the child's version of the fd alone.

3. Change multiprocessing.popen_fork.Popen.wait to use os.WNOHANG for all calls 
with a non-None timeout (not just timeout=0.0), rather than trusting 
multiprocessing.connection.wait's return value (which only says whether the 
pipe is closed, not whether the process is closed). Problem is, this would just 
change the behavior from waiting for the lifetime of the child no matter what 
to waiting until the exec and then returning immediately, even well before the 
timeout; it might also introduce race conditions if the fd registers as being 
closed before the process is fully exited. Point is, this approach would likely 
require a lot of subtle tweaks to make it work.

I'm in favor of either #1 or #2. #2 feels like a intentionally opening a 
resource leak on the surface, but I think it's actually fine, since we already 
signed up for a file descriptor that would live for the life of the process; 
the fact that it's exec-ed seems sort of irrelevant.

--
keywords: +3.4regression

___
Python tracker 

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



[issue35657] multiprocessing.Process.join() ignores timeout if child process use os.exec*()

2019-01-04 Thread Josh Rosenberg


Josh Rosenberg  added the comment:

I don't know what triggered the change, but I strongly suspect this is not a 
supported use of the multiprocessing module; Process is for worker processes 
(still running Python), and it has a lot of coordination machinery set up 
between parent and child (for use by, among other things,  join) that exec 
severs rather abruptly.

Launching unrelated child processes is what the subprocess module is for.

--
nosy: +josh.r

___
Python tracker 

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



[issue35631] Improve typing docs wrt abstract/concrete collection types

2019-01-04 Thread Ivan Levkivskyi


Ivan Levkivskyi  added the comment:

I think this can be closed now. Whether to merge doc-fix backport to now 
security-only 3.6 branch is up to Ned.

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



[issue35631] Improve typing docs wrt abstract/concrete collection types

2019-01-04 Thread miss-islington


miss-islington  added the comment:


New changeset 902196d867a34cc154fa9c861c883e69232251c6 by Miss Islington (bot) 
in branch '3.7':
bpo-35631: Improve typing docs wrt abstract/concrete collection types (GH-11396)
https://github.com/python/cpython/commit/902196d867a34cc154fa9c861c883e69232251c6


--
nosy: +miss-islington

___
Python tracker 

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



[issue35631] Improve typing docs wrt abstract/concrete collection types

2019-01-04 Thread miss-islington


Change by miss-islington :


--
pull_requests: +10853, 10854, 10855, 10856, 10857, 10858

___
Python tracker 

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



[issue35631] Improve typing docs wrt abstract/concrete collection types

2019-01-04 Thread miss-islington


Change by miss-islington :


--
pull_requests: +10856, 10857, 10858

___
Python tracker 

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



[issue35631] Improve typing docs wrt abstract/concrete collection types

2019-01-04 Thread miss-islington


Change by miss-islington :


--
pull_requests: +10856, 10857

___
Python tracker 

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



[issue35631] Improve typing docs wrt abstract/concrete collection types

2019-01-04 Thread Ivan Levkivskyi

Ivan Levkivskyi  added the comment:


New changeset 31ec52a9afedd77e36a3ddc31c4c45664b8ac410 by Ivan Levkivskyi 
(Ville Skyttä) in branch 'master':
bpo-35631: Improve typing docs wrt abstract/concrete collection types (GH-11396)
https://github.com/python/cpython/commit/31ec52a9afedd77e36a3ddc31c4c45664b8ac410


--

___
Python tracker 

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



[issue35631] Improve typing docs wrt abstract/concrete collection types

2019-01-04 Thread miss-islington


Change by miss-islington :


--
pull_requests: +10854, 10856

___
Python tracker 

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



[issue35631] Improve typing docs wrt abstract/concrete collection types

2019-01-04 Thread miss-islington


Change by miss-islington :


--
pull_requests: +10853, 10854

___
Python tracker 

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



[issue35631] Improve typing docs wrt abstract/concrete collection types

2019-01-04 Thread miss-islington


Change by miss-islington :


--
pull_requests: +10853

___
Python tracker 

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



[issue23867] Argument Clinic: inline parsing code for 1-argument functions

2019-01-04 Thread STINNER Victor


STINNER Victor  added the comment:

Nice optimization! I wanted to implement it, but then I forgot.

--

___
Python tracker 

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



[issue24928] mock.patch.dict spoils order of items in collections.OrderedDict

2019-01-04 Thread Vaibhav Gupta


Vaibhav Gupta  added the comment:

Hi Emmanuel

Please go ahead and make a PR. :)

--

___
Python tracker 

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



[issue24928] mock.patch.dict spoils order of items in collections.OrderedDict

2019-01-04 Thread Emmanuel Arias


Emmanuel Arias  added the comment:

ping Vaibhav :-)

> I would like to make a PR for this.

--
nosy: +eamanu

___
Python tracker 

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



[issue35658] Reggie_Linear_Regression_Solution.ipynb devide by 10 diff with multiply by .1

2019-01-04 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Not a bug. 0.1 is a binary floating point value, please read the FAQs:

https://docs.python.org/3/faq/design.html#why-are-floating-point-calculations-so-inaccurate

1/10 = 0.1 in decimal cannot be represented *exactly* in binary floating point, 
so when you type 0.1 as a float, the actual value you get is the closest number 
you can get using 53 bits for the significant digits, 8 bits for the exponent 
and 1 bit for the sign (plus or minus). That is approximately 
0.156 or so.

Unfortunately you cannot get any closer to 1/10 in binary floating point 
numbers, for the same reason you cannot get 1/3 exactly in decimal.

See also 

https://stackoverflow.com/questions/8215437/floating-point-accuracy-in-python

https://stackoverflow.com/questions/21895756/why-are-floating-point-numbers-inaccurate

https://stackoverflow.com/questions/1089018/why-cant-decimal-numbers-be-represented-exactly-in-binary?noredirect=1=1

--
nosy: +steven.daprano
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



[issue35609] Improve of abc.py docstring

2019-01-04 Thread Emmanuel Arias


Emmanuel Arias  added the comment:

> No plan for removal.  See https://bugs.python.org/issue28886#msg282582

Thanks!

--

___
Python tracker 

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



[issue35658] Reggie_Linear_Regression_Solution.ipynb devide by 10 diff with multiply by .1

2019-01-04 Thread Bart van den Donk


New submission from Bart van den Donk :

possible_ms1 = [i*.1 for i in range(-100, 101, 1)] #your list comprehension here
print(possible_ms1)
possible_ms2 = [i/10 for i in range(-100, 101, 1)] #your list comprehension here
print(possible_ms2)

Multiply by .1 gives dirty results.
Divide by 10 gives clean results.

--
components: Demos and Tools, Regular Expressions
messages: 332973
nosy: Bart van den Donk, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Reggie_Linear_Regression_Solution.ipynb devide by 10 diff with multiply 
by .1
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



[issue10948] Trouble with dir_util created dir cache

2019-01-04 Thread Malcolm Smith


Malcolm Smith  added the comment:

Please reopen this issue. The distutils2 project has now been abandoned, so 
that's no longer a justification for taking no action. 

At the very least, the documentation should be fixed to either warn about this 
surprising behavior, or make it clear that the the dir_util functions are for 
distutils internal use only.

--
nosy: +Malcolm Smith
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



[issue35198] Build issue while compiling cpp files in AIX

2019-01-04 Thread Michael Felt


Michael Felt  added the comment:

While the PR probably solves this - there is a 'bug' in pandas (I expect) that 
prevents me from completing the test - as, I expect LONG before the .cpp source 
is to be compiled - there is a error because a wrong flag is passed to the 
compiler (-Wno-unused-function) and the build stops.

Have not had the time to disect pandas so that I can get a .cpp source compiled.

+
Successfully installed pip-18.1
root@x066:[/data/prj/python/git/kadler]pip list
/opt/lib/python3.8/site-packages/pip/_vendor/html5lib/_trie/_base.py:3: 
DeprecationWdeprecated, and in 3.8 it will stop working
  from collections import Mapping
PackageVersion
-- ---
pip18.1
setuptools 39.0.1
root@x066:[/data/prj/python/git/kadler]pip install numpy
/opt/lib/python3.8/site-packages/pip/_vendor/html5lib/_trie/_base.py:3: 
DeprecationWdeprecated, and in 3.8 it will stop working
  from collections import Mapping
Collecting numpy
/opt/lib/python3.8/site-packages/pip/_vendor/msgpack/fallback.py:220: 
PendingDepreca
  warnings.warn(
  Using cached 
https://files.pythonhosted.org/packages/2d/80/1809de155bad674b494248b
Installing collected packages: numpy
  Running setup.py install for numpy ... done
Successfully installed numpy-1.15.4

...
Installing collected packages: six, python-dateutil, pytz, pandas
...
copying pandas/io/formats/templates/html.tpl -> 
build/lib.aix-6.1-3.8-pydebug/pandas/io/formats/templates
UPDATING build/lib.aix-6.1-3.8-pydebug/pandas/_version.py
set build/lib.aix-6.1-3.8-pydebug/pandas/_version.py to '0.23.4'
running build_ext
building 'pandas._libs.algos' extension
creating build/temp.aix-6.1-3.8-pydebug
creating build/temp.aix-6.1-3.8-pydebug/pandas
creating build/temp.aix-6.1-3.8-pydebug/pandas/_libs
xlc_r -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/include -O2 
-qmaxmem=-1 -qarch=pwr5 -Ipandas/_libs/src/klib -Ipandas/_libs/src 
-I/opt/lib/python3.8/site-packages/numpy/core/include 
-I/opt/include/python3.8dm -c pandas/_libs/algos.c -o 
build/temp.aix-6.1-3.8-pydebug/pandas/_libs/algos.o -Wno-unused-function
xlc_r: 1501-210 (S) command option Wno-unused-function contains an 
incorrect subargument
error: command 'xlc_r' failed with exit status 40


Command "/opt/bin/python3 -u -c "import setuptools, 
tokenize;__file__='/tmp/pip-install-xnscgehv/pandas/setup.py';f=getattr(tokenize,
 'open', open)(__file__);code=f.read().replace('\r\n', 
'\n');f.close();exec(compile(code, __file__, 'exec'))" install --record 
/tmp/pip-record-0w46p413/install-record.txt --single-version-externally-managed 
--compile" failed with error code 1 in /tmp/pip-install-xnscgehv/pandas/

--

___
Python tracker 

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



[issue35657] multiprocessing.Process.join() ignores timeout if child process use os.exec*()

2019-01-04 Thread Huazuo Gao


New submission from Huazuo Gao :

import os
import time
from multiprocessing import Process

p = Process(target=lambda:os.execlp('bash', 'bash', '-c', 'sleep 1.5'))
t0 = time.time()
p.start()
p.join(0.1)
print(time.time() - t0)

---

Python 3.5 - 3.8 take 1.5 sec to finish
Python 2.7 take 0.1 sec to finish

--
components: Library (Lib)
messages: 332970
nosy: Huazuo Gao
priority: normal
severity: normal
status: open
title: multiprocessing.Process.join() ignores timeout if child process use 
os.exec*()
type: behavior
versions: Python 3.5, Python 3.6, 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



[issue35655] documentation have wrong info about fibo module examples

2019-01-04 Thread Christian Heimes


Christian Heimes  added the comment:

The documentation examples are not based on the 3rd party Fibo Python package. 
All examples are based on the short script 
https://docs.python.org/3/tutorial/modules.html?highlight=fibo#modules :

  For instance, use your favorite text editor to create a file
  called fibo.py in the current directory with the following contents

--
nosy: +christian.heimes
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



[issue35656] More matchers in unittest.mock

2019-01-04 Thread Petter S


New submission from Petter S :

The ``ANY`` object in ``unittest.mock`` is also pretty useful when verifying 
dicts in tests:

self.assertEqual(result, {
"message": "Hi!",
"code": 0,
"id": mock.ANY
})

Then it does not matter what the (presumably randomly generated) id is. For the 
same use cases, objects like ``APPROXIMATE`` (for approximate floating-point 
matching) and ``MATCHES`` (taking a boolean lambda) would be pretty useful, I 
think.

--
components: Library (Lib)
messages: 332968
nosy: Petter S
priority: normal
severity: normal
status: open
title: More matchers in unittest.mock
type: enhancement

___
Python tracker 

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



[issue35655] documentation have wrong info about fibo module examples

2019-01-04 Thread Juan


New submission from Juan :

The below sections in modules documentation have wrong information about fibo 
module:
6. Modules
6.1. More on Modules
6.1.1. Executing modules as scripts
6.3. The dir() Function

The name of module is Fibo not fibo and the attributes are fab,fab2 not 
fib,fib2.


root@archlinux ~]# python2 --version
Python 2.7.15
[root@archlinux ~]# pip2 --version
pip 18.1 from /usr/lib/python2.7/site-packages/pip (python 2.7)
[root@archlinux ~]# pip2 install fibo
Collecting fibo
  Using cached 
https://files.pythonhosted.org/packages/24/50/e74bd48bbef1040afb01b107e6cfbc3c1e991be24c10c40a37e335383e54/Fibo-1.0.0.tar.gz
Installing collected packages: fibo
  Running setup.py install for fibo ... done
Successfully installed fibo-1.0.0
[root@archlinux ~]# pip2 list modules |grep -i fibo
Fibo 1.0.0  
[root@archlinux ~]# python2
Python 2.7.15 (default, Jun 27 2018, 13:05:28) 
[GCC 8.1.1 20180531] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import fibo
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named fibo
>>> import Fibo
>>> Fibo.fib(10)
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'module' object has no attribute 'fib'
>>> Fibo.fib2(10)
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'module' object has no attribute 'fib2'
>>> Fibo.fab(10)
1
1
2
3
5
8
13
21
34
55
>>> Fibo.fab2(10)
[1, 1, 2, 3, 5, 8, 13, 21, 34, 55]
>>> Fibo.__name__
'Fibo'
>>> dir(Fibo)
['Fab', '__builtins__', '__doc__', '__file__', '__name__', '__package__', 
'fab', 'fab2', 'fab4']

--
assignee: docs@python
components: Documentation
messages: 332967
nosy: docs@python, eric.araujo, ezio.melotti, juanbaio10, mdk, willingc
priority: normal
severity: normal
status: open
title: documentation have wrong info about fibo module examples
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, 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



[issue35654] Remove 'guarantee' that sorting only relies on __lt__ from sorting howto

2019-01-04 Thread Martijn Pieters


Martijn Pieters  added the comment:

(I have no opinion on this having to be a language feature however)

--

___
Python tracker 

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



[issue35654] Remove 'guarantee' that sorting only relies on __lt__ from sorting howto

2019-01-04 Thread Martijn Pieters


Martijn Pieters  added the comment:

Well, if this is indeed by design (and I missed the list.sort() reference) then 
I agree the HOWTO should not be changed!

I'd be happy to change this to asking for more explicit mentions in the docs 
for sorted, heapq and bisect that using only < (__lt__) is a deliberate choice.

--

___
Python tracker 

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



[issue35545] asyncio.base_events.create_connection doesn't handle scoped IPv6 addresses

2019-01-04 Thread twisteroid ambassador


twisteroid ambassador  added the comment:

Oh wait, there's also this in asyncio docs for loop.sock_connect:

Changed in version 3.5.2: address no longer needs to be resolved. sock_connect 
will try to check if the address is already resolved by calling 
socket.inet_pton(). If not, loop.getaddrinfo() will be used to resolve the 
address.

https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.sock_connect

So this is where the current bug comes from! My PR 11403 basically undid this 
change.

My proposal, as is probably obvious, is to undo this change and insist on 
passing only resolved address tuples to loop.sock_connect(). My argument is 
that this feature never worked properly: 

* As mentioned in the previous message, this does not work on ProactorEventLoop.
* On SelectorEventLoop, the resolution done by loop.sock_connect() is pretty 
weak anyways: it only takes the first resolved address, unlike 
loop.create_connection() that actually tries all the resolved addresses until 
one of them successfully connects.

Users should use create_connection() or open_connection() if they want to avoid 
the complexities of address resolution. If they are reaching for low_level APIs 
like loop.sock_connect(), they should also handle loop.getaddrinfo() themselves.

--

___
Python tracker 

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



[issue35545] asyncio.base_events.create_connection doesn't handle scoped IPv6 addresses

2019-01-04 Thread twisteroid ambassador


twisteroid ambassador  added the comment:

I just noticed that in the socket module, an AF_INET address tuple is allowed 
to have an unresolved host name. Quote:

A pair (host, port) is used for the AF_INET address family, where host is a 
string representing either a hostname in Internet domain notation like 
'daring.cwi.nl' or an IPv4 address like '100.50.200.5', and port is an integer.

https://docs.python.org/3/library/socket.html#socket-families

Passing a tuple of (hostname, port) to socket.connect() successfully connects 
the socket (tested on Windows). Since the C struct sockaddr_in does not support 
hostnames, socket.connect obviously does resolution at some point, but its 
implementation is in C, and I haven't looked into it.

BaseSelectorEventLoop.sock_connect() calls socket.connect() directly, therefore 
it also supports passing in a tuple of (hostname, port). I just tested 
ProactorEventLoop.sock_connect() on 3.7.1 on Windows, and it does not support 
hostnames, raising OSError: [WinError 10022] An invalid argument was supplied.

I personally believe it's not a good idea to allow hostnames in address tuples 
and in sock.connect(). However, the socket module tries pretty hard to 
basically accept any (host, port) tuple as address tuples, whether host is an 
IPv4 address, IPv6 address or host name, so that's probably not going to change.

--

___
Python tracker 

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



<    1   2