[issue30940] Documentation for round() is incorrect.

[Mark Dickinson]

Mark Dickinson added the comment:

[Serhiy]
> Wasn't this change a mistake? Seems Mark opposed to it.

Shrug. It seemed unnecessary to me to explicitly support `None` as a second 
argument, but it's done now; reverting the change at this point would do more 
harm than good.

So indeed there's a minor inaccuracy in the docs here. I'd suggest replacing 
the sentence identified with:

"The return value is an integer if *ndigits* is omitted or *None*. Otherwise 
the return value has the same type as *number*."

--

___
Python tracker 

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

[issue9262] IDLE: Revise or replace tabbedpages for multi-editor window.

[Vedran Čačić]

Vedran Čačić added the comment:

Hm, interesting. Yes, I admit I didn't even know Firefox behaved in such a way, 
and I have used Firefox for quite a long time. But I'd say it only proves my 
point. How will users know about it?

Also: you probably want, when a user clicks on some file to say "Open with 
IDLE", for it to open in a new tab. There are experienced users (me included) 
that want it to open in a new window. Can we get a configuration option? Or at 
least a command line switch? (Like chrome --new-window.)

--

___
Python tracker 

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

[issue18558] Iterable glossary entry needs clarification

[Vedran Čačić]

Vedran Čačić added the comment:

I think this is backwards. "Refusing the temptation to guess" in this case can 
mean returning True for is_iterable. After all, we can always have something 
like

class Deceptive:
def __iter__(self):
raise TypeError("I'm not really iterable")

and it's not the business of instancecheck to actually iterate (either via 
__iter__, or __getitem__). Its task is to check whether it has a corresponding 
attribute (not set to None, per the new convention of explicitly disabling 
protocols).

It could be different if the "old __getitem__ iteration" was deprecated, or at 
least scheduled to be deprecated, but as far as I can tell, it isn't. (It 
really should be documented if it were so.)

_At least_, the documentation of 
https://docs.python.org/3/library/collections.abc.html#collections.abc.Iterable 
should be more precise in saying (instead of just "See also the definition of 
iterable.") something like "Note that the definition of iterable in the 
glossary is more general than what this method checks, by design / omission / 
backward compatibility / apathy / whatever."

(Ok, the last part might be too much. But it's essential to point out the 
things are different, and whether it's meant to stay that way.)

--
nosy: +veky

___
Python tracker 

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

[issue30943] printf-style Bytes Formatting sometimes do not worked.

[zaazbb]

New submission from zaazbb:

# works.
>>> b'\x00\x08%(amount)b'% {b'amount':b'1'}
b'\x00\x081'
# not work.
>>> b'\x11\x00\x08%(amount)b'% {b'amount':b'1'}
b'\x11\x00\x08%(amount)b'

# not work.
>>> amount=bytearray(b'0010')
>>> posnum=bytearray(b'423')
>>> date_ =b'170717'
>>> time_=b'160006'
>>> b'\x02\x03\x13\x9f\x00\x00\x04NULL\x9f\x01\x00\x01\x02\x9f\x03\x00\x0c\xd6\xd0\xb9\xfa\xd2\xf8\xc1\xaa\xb2\xe2\xca\xd4\x9f\x04\x00\x0f307310083980007\x9f\x05\x00\x0814025520\x9f\x14\x00\x0200\x9f\x19\x00\x08\xbd\xbb\xd2\xd7\xb3\xc9\xb9\xa6\x9f\x07\x00\x0803072900\x9f\x08\x00\n0014243000\x9f\t\x00\x08\xbd\xf0\xbf\xa8\xd6\xd0\xd0\xc4\x9f\n\x00\x0800092900\x9f\r\x00\x06000145\x9f\x0e\x00\x0681\x9f\x10\x00\x0c162246168268\x9f\x11\x00\x08%(date)s\x9f\x12\x00\x06%(time)s\x9f\x02\x00\x0c%(amount)s\x9f\x1b\x00\x04\x9f\x0b\x00\x13622452*2994\x9f\x0c\x00\x01S\x9f\x0f\x00\x00\x9f\x13\x00.FK:\xbb\xb7\xd3\xce\xd1\xc7\xcc\xab\xb3\xa9\xcf\xed\xd2\xf8\xc1\xaa\xd3\xc5\xbb\xdd\nZX:promo.unionpay.com\n\x9f\x1f\x00\x03%(posnum)s\x9f\x1a\x00\x00\x9f\xa1\x00\x01\x01\x9f\xa0\x00\x01\x01\x03\x00'%
>>>  {b'amount': amount,b'date': date_,b'time': time_,b'posnum': posnum}
b'\x02\x03\x13\x9f\x00\x00\x04NULL\x9f\x01\x00\x01\x02\x9f\x03\x00\x0c\xd6\xd0\xb9\xfa\xd2\xf8\xc1\xaa\xb2\xe2\xca\xd4\x9f\x04\x00\x0f307310083980007\x9f\x05\x00\x0814025520\x9f\x14\x00\x0200\x9f\x19\x00\x08\xbd\xbb\xd2\xd7\xb3\xc9\xb9\xa6\x9f\x07\x00\x0803072900\x9f\x08\x00\n0014243000\x9f\t\x00\x08\xbd\xf0\xbf\xa8\xd6\xd0\xd0\xc4\x9f\n\x00\x0800092900\x9f\r\x00\x06000145\x9f\x0e\x00\x0681\x9f\x10\x00\x0c162246168268\x9f\x11\x00\x08%(date)s\x9f\x12\x00\x06%(time)s\x9f\x02\x00\x0c%(amount)s\x9f\x1b\x00\x04\x9f\x0b\x00\x13622452*2994\x9f\x0c\x00\x01S\x9f\x0f\x00\x00\x9f\x13\x00.FK:\xbb\xb7\xd3\xce\xd1\xc7\xcc\xab\xb3\xa9\xcf\xed\xd2\xf8\xc1\xaa\xd3\xc5\xbb\xdd\nZX:promo.unionpay.com\n\x9f\x1f\x00\x03%(posnum)s\x9f\x1a\x00\x00\x9f\xa1\x00\x01\x01\x9f\xa0\x00\x01\x01\x03\x00'

Environment:
Python 3.6.1
Windows 10 64bit.

--
components: Library (Lib)
messages: 298465
nosy: zaazbb
priority: normal
severity: normal
status: open
title: printf-style Bytes Formatting sometimes do not worked.
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

[issue30850] [2.7] bsddb3: test01_basic_replication() of test_bsddb3 fails randomly on AMD64 Windows8.1 Refleaks 2.7

[STINNER Victor]

STINNER Victor added the comment:

http://buildbot.python.org/all/builders/AMD64%20Windows8.1%20Refleaks%202.7/builds/50

...
test03_ThreadedTransactions (bsddb.test.test_thread.HashThreadedTransactions) 
... ok
test03_ThreadedTransactions 
(bsddb.test.test_thread.BTreeThreadedNoWaitTransactions) ... ok
test03_ThreadedTransactions 
(bsddb.test.test_thread.HashThreadedNoWaitTransactions) ... ok
testCheckElapsedTime (test.test_bsddb3.TimingCheck) ... beginning 6 repetitions
123456
..
Berkeley DB 4.7.25: (May 15, 2008)
Test path prefix:  d:\temp\z-test_bsddb3-4292
XXX: timeout happened beforestartup was confirmed - see issue 3892
test test_bsddb3 failed -- Traceback (most recent call last):
  File 
"D:\buildarea\2.7.ware-win81-release.refleak\build\lib\bsddb\test\test_lock.py",
 line 132, in test04_lock_timeout2
self.assertGreaterEqual(end_time-start_time, 0.0999)
AssertionError: 0.0955613098145 not greater than or equal to 0.0999

ok

==
FAIL: test04_lock_timeout2 (bsddb.test.test_lock.LockingTestCase)
--
Traceback (most recent call last):
  File 
"D:\buildarea\2.7.ware-win81-release.refleak\build\lib\bsddb\test\test_lock.py",
 line 132, in test04_lock_timeout2
self.assertGreaterEqual(end_time-start_time, 0.0999)
AssertionError: 0.0955613098145 not greater than or equal to 0.0999

--

___
Python tracker 

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

[issue30916] Pre-build OpenSSL and Tcl/Tk for Windows

[Steve Dower]

Steve Dower added the comment:


New changeset 68d663cf85d1ac5eaf83482eed39c0a6f8093601 by Steve Dower in branch 
'master':
[bpo-30916] Pre-build OpenSSL and Tcl/Tk for Windows (#2688)
https://github.com/python/cpython/commit/68d663cf85d1ac5eaf83482eed39c0a6f8093601


--

___
Python tracker 

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

[issue30916] Pre-build OpenSSL and Tcl/Tk for Windows

[STINNER Victor]

STINNER Victor added the comment:

Failure:
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/750

--
nosy: +haypo

___
Python tracker 

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[Steve Dower]

Steve Dower added the comment:

The buildbot failures currently being blamed on issue30916 are actually due to 
this issue - we actually need Python 3.6 on these machines in order to download 
the new externals, and they don't have it and we can't get it via Powershell.

--

___
Python tracker 

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

[issue30916] Pre-build OpenSSL and Tcl/Tk for Windows

[Steve Dower]

Steve Dower added the comment:

The buildbot failure blamed on this issue is actually due to issue30450 - it's 
the first time we've added a new external, and so the inability to download 
Python via Powershell on Windows 7 is the problem, not this.

--

___
Python tracker 

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

[issue30916] Pre-build OpenSSL and Tcl/Tk for Windows

[Steve Dower]

Changes by Steve Dower :


--
stage:  -> commit review

___
Python tracker 

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[Steve Dower]

Changes by Steve Dower :


--
pull_requests: +2797

___
Python tracker 

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[Steve Dower]

Steve Dower added the comment:

My PR adds a small script to use requests.get/urlretrieve with any version of 
Python to get nuget.exe.

Theoretically, we *could* use this to download everything, but I'd rather 
minimize our exposure to insecure downloads for machines that don't already 
have Python 3.6 available.

--

___
Python tracker 

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

[issue30944] Python 32 bit install fails on Windows - BitDefender false positives

[Arie van Wingerden]

New submission from Arie van Wingerden:

I discovered that BitDefender somehow blocks part of the installation of Python 
3.x on Windows, resulting in a completely broken installation. I found this 
after having turned my system inside out ... @!#$%^&^%$#@

So solving it is either:
   deinstall BitDefender
   exclude files from being marked as a virus

Maybe this can be mentioned on the install page?

--
components: Windows
messages: 298472
nosy: Arie van Wingerden, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python 32 bit install fails on Windows - BitDefender false positives
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

[issue30944] Python 32 bit install fails on Windows - BitDefender false positives

[Louie Lu]

Louie Lu added the comment:

I think BitDefender has some option like "disable 10 mins"? You may disable 
your antivirus when you are install something you be sure that is trustworthy.

Or maybe BitDefender is right, you download a wrong .msi from other place that 
has been insert something bad, check about md5 about the installer

--
nosy: +louielu

___
Python tracker 

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

[issue30945] loop.create_server does not detect if the interface is IPv6 enabled

[Cecile Tonglet]

New submission from Cecile Tonglet:

The IPv6 detection in asyncio.base_events.create_server only detect if IPv6 is 
available instead of checking if the interface can actually support it.

I noticed that by using Python in a Docker container (example code to reproduce 
in attachment):


docker run -it --rm -v /tmp/test_ipv6.py:/src/test_ipv6.py python:3.6 python 
/src/test_ipv6.py


Will result in:


Traceback (most recent call last):
  File "/usr/local/lib/python3.6/asyncio/base_events.py", line 1043, in 
create_server
sock.bind(sa)
OSError: [Errno 99] Cannot assign requested address

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/src/test_ipv6.py", line 11, in 
server = loop.run_until_complete(server_creation)
  File "/usr/local/lib/python3.6/asyncio/base_events.py", line 466, in 
run_until_complete
return future.result()
  File "/usr/local/lib/python3.6/asyncio/base_events.py", line 1047, in 
create_server
% (sa, err.strerror.lower()))
OSError: [Errno 99] error while attempting to bind on address ('::1', 27015, 0, 
0): cannot assign requested address


By default Docker containers have only IPv4 enabled:


1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
38: eth0@if39:  mtu 1500 qdisc noqueue state 
UP group default 
link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.2/16 scope global eth0
   valid_lft forever preferred_lft forever


I believe this detection mechanism should rely on the interface requested. I 
found this on the web for Python 2 that manage to get the info per interface: 
https://pastebin.com/VEnhF1Ht but it's using an external library.

However if you change the hostname to 127.0.0.1 it works normally.

--
components: asyncio
files: test_ipv6.py
messages: 298474
nosy: cecton, yselivanov
priority: normal
severity: normal
status: open
title: loop.create_server does not detect if the interface is IPv6 enabled
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file47019/test_ipv6.py

___
Python tracker 

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

[issue9262] IDLE: Revise or replace tabbedpages for multi-editor window.

[Terry J. Reedy]

Terry J. Reedy added the comment:

I suspect that Edit with IDLE would open a new window as it does now, but I 
don't really know.  I don't think that IDLE would have any control.  I seldom 
start IDLE that way.

--

___
Python tracker 

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[STINNER Victor]

STINNER Victor added the comment:

Compilation failed on:

* http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/885
* 
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/750

--
nosy: +haypo

___
Python tracker 

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

[issue30944] Python 32 bit install fails on Windows - BitDefender false positives

[Arie van Wingerden]

Arie van Wingerden added the comment:

Hi Louie,

1) no, I definitely used the right installer

2) BitDefender also interferes often when I compile Go programs

So, in the end it is a real pain in the neck and I deinstalled it.
Maybe other people can live with it, but it has cost me a lot of time in
this case and also when developing / compiling other PL's.

Still it would be nice if a warning could be placed on the download page
(maybe in general to disable AV when installing).

Thx!
/Arie

2017-07-17 11:59 GMT+02:00 Louie Lu :

>
> Louie Lu added the comment:
>
> I think BitDefender has some option like "disable 10 mins"? You may
> disable your antivirus when you are install something you be sure that is
> trustworthy.
>
> Or maybe BitDefender is right, you download a wrong .msi from other place
> that has been insert something bad, check about md5 about the installer
>
> --
> nosy: +louielu
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue30808] Use _Py_atomic API for concurrency-sensitive signal state

[Antoine Pitrou]

Changes by Antoine Pitrou :


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

[issue30808] Use _Py_atomic API for concurrency-sensitive signal state

[Antoine Pitrou]

Antoine Pitrou added the comment:


New changeset 2c8a5e4c968217f9672340e520942c4ed788d8de by Antoine Pitrou in 
branch 'master':
bpo-30808: Use _Py_atomic API for concurrency-sensitive signal state (#2417)
https://github.com/python/cpython/commit/2c8a5e4c968217f9672340e520942c4ed788d8de


--

___
Python tracker 

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

[issue30946] readline module has obsolete code

[Antoine Pitrou]

New submission from Antoine Pitrou:

The readline module has obsolete code for platforms where GNU readline is older 
than 2.1 or where select() is not available.

--
components: Extension Modules
messages: 298479
nosy: pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: readline module has obsolete code
type: enhancement
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

[issue30946] readline module has obsolete code

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
pull_requests: +2798

___
Python tracker 

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

[issue30946] readline module has obsolete code

[Antoine Pitrou]

Changes by Antoine Pitrou :


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

[issue30946] readline module has obsolete code

[Antoine Pitrou]

Antoine Pitrou added the comment:

According to https://ftp.gnu.org/gnu/readline/, GNU readline 2.1 was released 
in 1997... We could probably even require 5.0 (released in 2004), but it raises 
the question of which functions are supported by third-party emulations such as 
libedit.

--

___
Python tracker 

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

[issue30943] printf-style Bytes Formatting sometimes do not worked.

[Gareth Rees]

Gareth Rees added the comment:

Test case minimization:

Python 3.6.1 (default, Apr 24 2017, 06:18:27) 
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> b'a\x00%(a)s' % {b'a': b'a'}
b'a\x00%(a)s'

It seems that all formatting operations after a zero byte are ignored. This is 
because the code for parsing the format string (in _PyBytes_FormatEx in 
Objects/bytesobject.c) uses the following approach to find the next % character:

while (--fmtcnt >= 0) {
if (*fmt != '%') {
Py_ssize_t len;
char *pos;
pos = strchr(fmt + 1, '%');

But strchr uses the C notion of strings, which are terminated by a zero byte.

--
nosy: +g...@garethrees.org

___
Python tracker 

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

[issue28638] Optimize namedtuple creation

[Antoine Pitrou]

Antoine Pitrou added the comment:

I disagree with the rejection of this request.  The idea that "_source is an 
essential feature" should be backed by usage statistics instead of being 
hand-waved as rejection cause.

--
nosy: +pitrou
resolution: rejected -> 
stage: resolved -> 
status: closed -> open

___
Python tracker 

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

[issue30943] printf-style Bytes Formatting sometimes do not worked.

[Gareth Rees]

Gareth Rees added the comment:

This was already noted in issue29714 and fixed by Xiang Zhang in commit 
b76ad5121e2.

--

___
Python tracker 

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

[issue9216] FIPS support for hashlib

[Charalampos Stratakis]

Charalampos Stratakis added the comment:

@Andrew

This has already been implemented downstream for RHEL and centos.

--

___
Python tracker 

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

[issue28638] Optimize namedtuple creation

[Nick Coghlan]

Nick Coghlan added the comment:

Folks, you're talking about removing a *public*, *documented* API from the 
standard library. The onus would thus be on you to prove *lack* of use, *and* 
provide adequate justification for the compatibility break, not on anyone else 
to prove that it's "sufficiently popular" to qualify for the standard backwards 
compatibility guarantees. Those guarantees apply by default and are only broken 
for compelling reasons - that's why we call them guarantees

Don't be fooled by the leading underscore - that's an artifact of how 
namedtuple avoids colliding with arbitrary field names, not an indicator that 
this is a private API: 
https://docs.python.org/3/library/collections.html#collections.somenamedtuple._source

"It would be faster" isn't adequate justification, since speed increases only 
matter in code that has been identified as a bottleneck, and startup time in 
general (let alone namedtuple definitions in particular) is rarely the 
bottleneck.

So please, just stop, and find a more productive way of expending your energy 
(such as by making PyStructSequence available via the "types" module, since 
that also allows for C level micro-optimizations when *used*, not just at 
definition time).

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

[issue28638] Optimize namedtuple creation

[Antoine Pitrou]

Antoine Pitrou added the comment:

Nick, can you stop closing an issue where the discussion hasn't been settled?  
This isn't civil.

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

___
Python tracker 

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

[issue28638] Optimize namedtuple creation

[Nick Coghlan]

Nick Coghlan added the comment:

So unless and until he gets overruled by Guido, Raymond's decision to reject 
the proposed change stands.

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

[issue28638] Optimize namedtuple creation

[Antoine Pitrou]

Antoine Pitrou added the comment:

Just because I disagree with you doesn't mean I'm pestering anyone.  Can you 
stop being so obnoxious?

--

___
Python tracker 

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

[issue28638] Optimize namedtuple creation

[Nick Coghlan]

Nick Coghlan added the comment:

There's a path for escalation when you disagree with the decision of a 
module/API maintainer (in this case, Raymond): bringing the issue closure up on 
python-dev for wider discussion.

It *isn't* repeatedly reopening the issue after they have already made their 
decision and attempting to pester them into changing their mind.

--

___
Python tracker 

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

[issue28638] Optimize namedtuple creation

[Nick Coghlan]

Nick Coghlan added the comment:

Check the issue history - the issue has been rejected by Raymond, and then 
reopened for further debate by other core developers multiple times.

That's not a reasonable approach to requesting reconsideration of a module/API 
maintainers design decision.

I acknowledge that those earlier reopenings weren't by you, but the issue 
should still remain closed until *Raymond* agrees to reconsider it (and given 
the alternative option of instead making the lower overhead PyStructSequence 
visible at the Python level, I'd be surprised if he does).

--

___
Python tracker 

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

[issue28638] Optimize namedtuple creation

[STINNER Victor]

STINNER Victor added the comment:

Sorry, I don't have much data at this point, but it's not the first time that I 
noticed that namedtuple is super slow. We have much more efficient code like 
structseq in C. Why not reusing it at least in our stdlib modules?

About the _source attribute, honestly, I'm not aware of anyone using it. I 
don't think that the fact that a *private* attribute is document should prevent 
it to make Python faster.

I already noticed the _source attribute when I studied the Python memory usage. 
See my old isuse #19640: "Drop _source attribute of namedtuple (waste memory)", 
I later changed the title to "Dynamically generate the _source attribute of 
namedtuple to save memory)".

About "Python startup time doesn't matter", this is just plain wrong. Multiple 
core developers spent a lot of time on optimizing exactly that. Tell me if you 
really need a long rationale to work on that.

While I'm not sure about Naoki's exact optimization, I agree about the issue 
title: "Optimize namedtuple creation", and I like the idea of keeping the issue 
open to find a solution.

--
nosy: +haypo

___
Python tracker 

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

[issue30942] Implement lwalk(levelwalk) function on os.py

[R. David Murray]

R. David Murray added the comment:

Thanks for being interested in improving Python.  Please join the discussion in 
the existing issue 26781, which proposes a max_depth parameter for walk.

--
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> os.walk max_depth

___
Python tracker 

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

[issue28638] Optimize namedtuple creation

[Nick Coghlan]

Nick Coghlan added the comment:

Yes, I'm saying you need a really long justification to explain why you want to 
break backwards compatibility solely for a speed increase.

For namedtuple instances, the leading underscore does *NOT* indicate a private 
attribute - it's just there to avoid colliding with field names.

Speed isn't everything, and it certainly isn't adequate justification for 
breaking public APIs that have been around for years.

Now, you can either escalate that argument to python-dev, and try to convince 
Guido to overrule Raymond on this point, *or* you can look at working out a 
Python level API to dynamically define PyStructSequence subclasses. That won't 
be entirely straightforward (as my recollection is that structseq is designed 
to build on static C structs), but if you're successful, it will give you 
something that should be faster than namedtuple in every way, not just at 
definition time.

--

___
Python tracker 

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

[issue30934] Document how to run coverage for repository idlelib files.

[Cheryl Sabella]

Cheryl Sabella added the comment:

I tried out the instructions.  I guess my first question is how stand alone 
these instructions are and how much you expect someone to already know about 
coverage.  What I mean is, I needed to go to the devguide to read more about 
coverage in order to run the steps here.

For example, the devguide suggests creating a venv before running pip install 
coverage.  If I do that and go into the venv, then I could do (with python 
instead of ./python):

python -m coverage run --source Lib/idlelib Lib/idlelib/idle_test/test_config.py
python -m coverage report
python -m coverage html

Those steps seem to work.

Without the venv, ./python -m coverage doesn't work without the pip install (I 
get the 'No module named coverage' error).  At some point (as per the 
devguide), I had also downloaded the in-development version, so I am able to 
run 
./python ../coveragepy run --source Lib/idlelib 
Lib/idlelib/idle_test/test_config.py

At the time, the devguide suggested the in development version because it was 
more recent for 3.7 than the released version was, but it seems that the 
version on pip is the most current now.

Just like everything else, it seems that there are a few ways to go with this, 
but the venv with pip install seems to be the most foolproof.  I don't know if 
you'd also want to include instructions for running coverage over all of 
idle_test instead of just one module.


(without the ./python)

--

___
Python tracker 

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

[issue18558] Iterable glossary entry needs clarification

[R. David Murray]

R. David Murray added the comment:

No, refusing to guess in this case is to believe the class's declaration that 
it is an iterable if (and only if) it defines __iter__, which is the modern 
definition of iterable.  If that doesn't work when the object is iterated, 
that's a bug in the class claiming to be an iterable when it isn't.

The confusion here is the existence of the older iteration protocol.  As you 
say, the documentation can use some improvement.  Eventually someone will 
submit a proposal in the form of a PR and we can hammer out the exact wording.

--

___
Python tracker 

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

[issue30944] Python 32 bit install fails on Windows - BitDefender false positives

[Steve Dower]

Steve Dower added the comment:

The best response is to notify Bitdefender so they can fix their signatures.

Python is commonly used in malware, and so some parts of it are often 
misidentified as unique to some detected virus. By reporting the name of the 
virus and providing the actual file to Bitdefender, they can fix their 
signatures and provide an update.

Most AV companies provide a specific email address for false positives. Feel 
free to email them, or provide enough information here (including their email 
address) and someone else can forward it.

--

___
Python tracker 

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[Steve Dower]

Steve Dower added the comment:


New changeset 588836d3e646c2bcb3473cda7c5f6a1e0ff2c2e9 by Steve Dower in branch 
'master':
bpo-30450: Adds alternate download approach for nuget.exe (#2737)
https://github.com/python/cpython/commit/588836d3e646c2bcb3473cda7c5f6a1e0ff2c2e9


--

___
Python tracker 

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

[issue30943] printf-style Bytes Formatting sometimes do not worked.

[R. David Murray]

Changes by R. David Murray :


--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
superseder:  -> can't interpolate byte string with \x00 before replacement 
identifier

___
Python tracker 

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[Steve Dower]

Steve Dower added the comment:

Compilation still fails, as some of the buildbots don't have py.exe either.

At this stage, our choices are either to fix the buildbots, most easily by 
copying py.exe into PATH, or to check nuget.exe (4MB) into the source 
repository. (I guess we can cover a few more % of cases by checking in py.exe, 
but that still won't get us 100%)

Any preferences?

--

___
Python tracker 

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

[issue19896] Exposing "q" and "Q" to multiprocessing.sharedctypes

[Gareth Rees]

Changes by Gareth Rees :


--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue28638] Optimize namedtuple creation

[STINNER Victor]

STINNER Victor added the comment:

Benchmark comparing collections.namedtuple to structseq, to get an attribute:

* Getting an attribute by name (obj.attr):
  Mean +- std dev: [name_structseq] 24.1 ns +- 0.5 ns -> [name_namedtuple] 45.7 
ns +- 1.9 ns: 1.90x slower (+90%)
* Getting an attribute by its integer index (obj[0]):
  (not significant)

So structseq is 1.9x faster than namedtuple to get an attribute by name.


haypo@speed-python$ ./bin/python3  -m perf timeit -s "from collections import 
namedtuple; Point=namedtuple('Point', 'x y'); p=Point(1,2)" "p.x" 
--duplicate=1024 -o name_namedtuple.json
Mean +- std dev: 45.7 ns +- 1.9 ns
haypo@speed-python$ ./bin/python3  -m perf timeit -s "from collections import 
namedtuple; Point=namedtuple('Point', 'x y'); p=Point(1,2)" "p[0]" 
--duplicate=1024 -o int_namedtuple.json
Mean +- std dev: 17.6 ns +- 0.0 ns


haypo@speed-python$ ./bin/python3  -m perf timeit -s "from sys import flags" 
"flags.debug" --duplicate=1024 -o name_structseq.json
Mean +- std dev: 24.1 ns +- 0.5 ns
haypo@speed-python$ ./bin/python3  -m perf timeit -s "from sys import flags" 
"flags[0]" --duplicate=1024 -o int_structseq.json
Mean +- std dev: 17.6 ns +- 0.2 ns

---

Getting an attribute by its integer index is as fast as tuple:

haypo@speed-python$ ./bin/python3  -m perf timeit --inherit=PYTHONPATH -s 
"p=(1,2)" "p[0]" --duplicate=1024 -o int_tuple.json
.
Mean +- std dev: 17.6 ns +- 0.0 ns

--

___
Python tracker 

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

[issue18558] Iterable glossary entry needs clarification

[Vedran Čačić]

Vedran Čačić added the comment:

Of course. The Deceptive class was just reductio ad absurdum. I'm all for 
believing the class through what attributes does it expose. We agree there.

Where we don't agree, is _what_ attributes constitute the iteration protocol. 
You, the source code and the documentation of the collections.abc.Iterable say 
one thing (__iter__), while I, the current version of Python (at least CPython, 
but I think other implementations do the same) and the glossary say another 
thing (__iter__ or __getitem__).

[It's not the only protocol consisting of two attributes... e.g. bool protocol 
also consists of two attributes, __bool__ and __len__ (though it is not 
optional, so we don't have collections.abc.Boolable).]

You seem to say that only the glossary needs fixing. But then we'll be in an 
even more weird position, where we must say some objects can be iterated, but 
are not iterables. I'm pretty sure you don't want that. The whole point of 
"Xable" words (e.g. "callable", as opposed to "function") is that it 
encompasses everything that can be Xed, not only the first thing that comes to 
mind (e.g. classes can also be called).

Or are you saying that after the glossary is fixed, then we should fix Python 
by (at least deprecating, if not) forbidding __getitem__ iteration? I'm not 
sure that this is the consensus. Are you?

--

___
Python tracker 

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[Antoine Pitrou]

Antoine Pitrou added the comment:

If the dependencies are in git, why don't you use "git clone" instead of trying 
a HTTP fetch?

--

___
Python tracker 

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

[issue28638] Optimize namedtuple creation

[STINNER Victor]

STINNER Victor added the comment:

> Speed isn't everything, and it certainly isn't adequate justification for 
> breaking public APIs that have been around for years.

What about the memory usage?

> See my old issue #19640 (...)

msg203271:

"""
I found this issue while using my tracemalloc module to analyze the memory 
consumption of Python. On the Python test suite, the _source attribute is the 
5th line allocating the most memory:

/usr/lib/python3.4/collections/__init__.py: 676.2 kB
"""

--

___
Python tracker 

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[Antoine Pitrou]

Antoine Pitrou added the comment:

For example "git clone --depth 1 https://github.com/python/cpython-bin-deps 
--branch openssl-bin-1.0.2k myopenssldir"

--

___
Python tracker 

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

[issue28638] Optimize namedtuple creation

[STINNER Victor]

STINNER Victor added the comment:

> So structseq is 1.9x faster than namedtuple to get an attribute by name.

Oops, I wrote it backward: So namedtuple is 1.9x slower than structseq to get 
an attribute by name.

(1.9x slower doesn't mean 1.9x faster, sorry.)

--

___
Python tracker 

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[Steve Dower]

Steve Dower added the comment:

We can't assume git.exe is available either (build from sdist/hggit/.zip), 
though I guess we can also use it as a fallback. At least on the buildbots 
it'll be there.

--

___
Python tracker 

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[Antoine Pitrou]

Antoine Pitrou added the comment:

I think it's reasonable to mandate the presence of a git install to fetch 
CPython externals.  After all we used to mandate the presence of a svn 
install...

--

___
Python tracker 

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[STINNER Victor]

STINNER Victor added the comment:

> We can't assume git.exe is available either

How do you get CPython source code if git is not available? Also using
HTTP to get a tarball? I think that it's ok to require git to build
CPython on Windows. Previously, we required: svn, perl and git :-)

--

___
Python tracker 

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[Steve Dower]

Steve Dower added the comment:

> we used to mandate the presence of a svn install

And we regretted that so much that we changed away from it :)

When discussing this changeover plan, Zach and I decided we needed a fallback 
requiring only OS dependencies. In this case, the Powershell dependency fails 
on Windows 7 since it does not have the Invoke-WebRequest command (unless 
you've been installing all your updates).

We decided against using git first because then the case that is more reliable 
(download and extract a .zip file from a URL) would go unused/untested in many 
cases.

We also use the potentially installed python.exe in other places in the build, 
so it's far from a waste to grab it, and we already required *any* Python 
dependency to do a full build (docs and/or installer), so it isn't really 
adding anything there. The bit that was overlooked was the PowerShell on old 
systems limitation, and the absence of py.exe when you don't have Python 3 
installed.

--

___
Python tracker 

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[Steve Dower]

Steve Dower added the comment:

> How do you get CPython source code if git is not available?

Go to GitHub and click the "Download" button, or select any sdist from our 
downloads page, or use Mercurial+hggit, or Dulwich directly, or a mirror/fork 
on any VCS you like. There are plenty of ways that don't require having git.exe 
on your PATH.

--

___
Python tracker 

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[Steve Dower]

Changes by Steve Dower :


--
pull_requests: +2799

___
Python tracker 

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

[issue26781] os.walk max_depth

[André Rossi Korol]

André Rossi Korol added the comment:

I proposed a new function called lwalk(level walk) that recurses only to a 
certain level of depth: http://bugs.python.org/issue30942
It is implemented in os.py and calls os.walk, but making sure it recurses only 
to a selected level of depth.
If it is accepted I could send a Pull Request with the lwalk function 
implemented in os.py.

--
hgrepos: +371
nosy: +andrekorol
Added file: http://bugs.python.org/file47020/os.py

___
Python tracker 

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

[issue30944] Python 32 bit install fails on Windows - BitDefender false positives

[Arie van Wingerden]

Arie van Wingerden added the comment:

OK. Will contact BitDefender.

2017-07-17 14:55 GMT+02:00 Steve Dower :

>
> Steve Dower added the comment:
>
> The best response is to notify Bitdefender so they can fix their
> signatures.
>
> Python is commonly used in malware, and so some parts of it are often
> misidentified as unique to some detected virus. By reporting the name of
> the virus and providing the actual file to Bitdefender, they can fix their
> signatures and provide an update.
>
> Most AV companies provide a specific email address for false positives.
> Feel free to email them, or provide enough information here (including
> their email address) and someone else can forward it.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[Antoine Pitrou]

Antoine Pitrou added the comment:

> And we regretted that so much that we changed away from it :)

I'm not sure what your reasons were but from my POV (as someone who used to 
build on Windows from time to time), the two problems were:

1) svn was only used for this while we had migrated to hg

2) svn is darn slow, which neither hg nor git (especially with shallow clones, 
see "git clone --depth 1") are

I don't think the annoyance itself of having to install git is much to worry 
about, since 1) it's a one time cost 2) it's quite easy 3) many developers or 
packagers are bound to already use git for other projects.

--

___
Python tracker 

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[STINNER Victor]

STINNER Victor added the comment:

Ah ok, I see, I was focused on buildbots and other CIs, sorry.

> Maybe we should consider just checking in nuget.exe?

Where? In Python source code? I don't want to how to maintain yet another 
dependencies :-( I prefer to try a few tools, or explain how to get them. And 
write good documentation how to build Python on Windows ;-)

--

___
Python tracker 

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

[issue28638] Optimize namedtuple creation

[INADA Naoki]

INADA Naoki added the comment:

I respect Raymond's rejection.  But I want to write down why I like Jelle's 
approach.

Currently, functools is the only module which is very popular.
But leaving this means every new namedtuple makes startup time about 0.6ms 
slower.

This is also problem for applications heavily depending on namedtuple.
Creating namedtuple is more than 15 times slower than normal class. It's not 
predictable or reasonable overhead.
It's not once I profiled application startup time and found namedtuple
account non-negligible percentage.

It's possible to keep `_source` with Jelle's approach. `_source` can be 
equivalent source rather than exact source eval()ed.
I admit it's not ideal. But all namedtuple user
and all Python implementation can benefit from it.

It's possible to expose StructSeq somewhere.  It can make it faster to
import `functools`.
But it's ugly too that applications and libraries tries it first
and falls back to namedtuple.
And when it is used widely, other Python implementations will be forced
to implement it.

That's why I'm willing collections.namedtuple overhead is reasonable and 
predictable.

--

___
Python tracker 

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

[issue19640] Dynamically generate the _source attribute of namedtuple to save memory)

[Giampaolo Rodola']

Changes by Giampaolo Rodola' :


--
nosy: +giampaolo.rodola

___
Python tracker 

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

[issue28638] Optimize namedtuple creation

[Giampaolo Rodola']

Changes by Giampaolo Rodola' :


--
nosy: +giampaolo.rodola

___
Python tracker 

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

[issue28638] Optimize namedtuple creation

[STINNER Victor]

STINNER Victor added the comment:

> It's possible to expose StructSeq somewhere.

Hum, when I mentioned structseq: my idea was more to reimplement
namedtuple using the existing structseq code, since structseq is well
tested and very fast.

--

___
Python tracker 

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[Steve Dower]

Steve Dower added the comment:

Unfortunately, "install " is often a blocking requirement for many 
developers (typically the ones who get paid well to do this), so I'd rather 
have no requirements.

Currently we achieve this if PowerShell is up to date or Python+py.exe are 
installed, both of which are likely even in the "I can't install anything" 
case. Soon we'll also succeed here if git is installed and on PATH, which 
likely covers a few more % of users (but especially our Win7 buildbots). I feel 
confident we've covered 99% of cases transparently without adding the need for 
more documentation - still just get_externals.bat && build.bat to build.

Once Travis has finished its build I'll merge and we'll see if the buildbots 
like it.

--

___
Python tracker 

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[Steve Dower]

Steve Dower added the comment:


New changeset efa26bcd5085279fc4e9ae96d052272a5214c2bd by Steve Dower in branch 
'master':
bpo-30450: Fall back to git.exe if no Python is found. (#2739)
https://github.com/python/cpython/commit/efa26bcd5085279fc4e9ae96d052272a5214c2bd


--

___
Python tracker 

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[Steve Dower]

Steve Dower added the comment:

The buildbots have already successfully built, so I'm declaring this and 
issue30916 resolved.

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[Jeremy Kloth]

Jeremy Kloth added the comment:

Or, use the preexisting convention of the HOST_PYTHON envvar that was used 
prior to the recent merged PRs

--
nosy: +jkloth

___
Python tracker 

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[Steve Dower]

Steve Dower added the comment:

> use the preexisting convention of the HOST_PYTHON envvar that was used prior 
> to the recent merged PRs

Is that an actual convention? I didn't see any other references, so I figured 
Zach had made it up.

--

___
Python tracker 

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

[issue30830] HTTPHandlerTest of test_logging leaks a "dangling" thread on AMD64 FreeBSD CURRENT Non-Debug 3.x

[STINNER Victor]

STINNER Victor added the comment:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.x%20Shared%203.x/builds/587/steps/test/logs/stdio

test_listen_config_10_ok (test.test_logging.ConfigDictTest) ... Warning -- 
threading_cleanup() failed to cleanup -1 threads after 3 sec (count: 0, 
dangling: 1)
ok

1 test altered the execution environment:
test_logging

Tests result: ENV CHANGED

--

___
Python tracker 

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[Antoine Pitrou]

Antoine Pitrou added the comment:

I think that's used on Unix when cross-compiling, but I don't know about 
Windows...

--

___
Python tracker 

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[Jeremy Kloth]

Jeremy Kloth added the comment:

> In this case, the Powershell dependency fails on Windows 7 since it does not 
> have the Invoke-WebRequest command (unless you've been installing all your 
> updates).

Just to note, PowerShell must be updated *manually* (at least on Win7).  Plus 
you need to know what to update to get it. In this case, the Windows Management 
Framework:

https://www.microsoft.com/en-us/download/details.aspx?id=40855

I've installed this on my buildbot apparently concurrently with this 
conversation.  Personally, I'd lean toward recommending this update with 
Windows 7 machines as it stays closer to "naked" OS + Python checkout for 
building a new Python. (Although the latest merge kinda makes this a mute 
point).

--

___
Python tracker 

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

[issue26781] os.walk max_depth

[Raymond Hettinger]

Raymond Hettinger added the comment:

> I think there is a little need in this feature.

I concur with Serhiy and think we're better-off without this proposal.
Marking this as closed.

--
nosy: +rhettinger
resolution:  -> rejected
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

[issue30947] Update embeded copy of libexpat to 2.2.2

[STINNER Victor]

New submission from STINNER Victor:

libexpat released a new version 2.2.2 which seems to contain 2 or 3 security 
fixes. I'm not sure that Python is affected by these bugs.

https://github.com/libexpat/libexpat/blob/R_2_2_2/expat/Changes#L5

Release 2.2.2 Wed July 12 2017
Security fixes:
 #43  Protect against compilation without any source of high
quality entropy enabled, e.g. with CMake build system;
commit ff0207e6076e9828e536b8d9cd45c9c92069b895
 #60  Windows with _UNICODE:
Unintended use of LoadLibraryW with a non-wide string
resulted in failure to load advapi32.dll and degradation
in quality of used entropy when compiled with _UNICODE for
Windows; you can launch existing binaries with
EXPAT_ENTROPY_DEBUG=1 in the environment to inspect the
quality of entropy used during runtime; commits
* 95b95032f907ef1cd17ee7a9a1768010a825d61d
* 73a5a2e9c081f49f2d775cf7ced864158b68dc80
   [MOX-006]  Fix non-NULL parser parameter validation in XML_Parse;
resulted in NULL dereference, previously;
commit ac256dafdffc9622ab0dc2c62fcecb0dfcfa71fe

Bug fixes:
 #69  Fix improper use of unsigned long long integer literals

Other changes:
 #73  Start requiring a C99 compiler
 #49  Fix "==" Bashism in configure script
 #50  Fix too eager getrandom detection for Debian GNU/kFreeBSD
 #52and macOS
 #51  Address lack of stdint.h in Visual Studio 2003 to 2008
 #58  Address compile warnings
 #68  Fix "./buildconf.sh && ./configure" for some versions
of Dash for /bin/sh
 #72  CMake: Ease use of Expat in context of a parent project
with multipe CMakeLists.txt files
 #72  CMake: Resolve mistaken executable permissions
 #76  Address compile warning with -DNDEBUG (not recommended!)
 #77  Address compile warning about macro redefinition

Special thanks to:
Alexander Bluhm
Ben Boeckel
Cătălin Răceanu
Kerin Millar
László Böszörményi
S. P. Zeidler
Segev Finer
Václav Slavík
Victor Stinner
Viktor Szakats
 and
Radically Open Security

--

Previous issue for expat 2.2.1: issue #30694.

--
messages: 298525
nosy: christian.heimes, gregory.p.smith, haypo, ned.deily
priority: normal
severity: normal
status: open
title: Update embeded copy of libexpat to 2.2.2
type: security
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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[Jeremy Kloth]

Jeremy Kloth added the comment:

> Is that an actual convention? I didn't see any other references, so I figured 
> Zach had made it up.

It has existed in the Windows build files since 2.5, when x64
supported was initially added by MvL.

--
nosy: +jeremy.kloth

___
Python tracker 

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

[issue30948] Docs for __subclasses__(): Add hint that Python imports are lazy

[Thomas Guettler]

New submission from Thomas Guettler:

AFAIK cls.__subclasses__() only returns the classes which the interpreter has 
already loaded.

This means there can be more subclasses in modules where not imported by the 
current interpreter up to now.

https://docs.python.org/3.7/library/stdtypes.html?highlight=subclasses#class.__subclasses__

I think it would be nice to add a hint to the docs that python imports are lazy.

What do you think?

--
messages: 298527
nosy: guettli
priority: normal
severity: normal
status: open
title: Docs for __subclasses__(): Add hint that Python imports are lazy

___
Python tracker 

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

[issue30947] Update embeded copy of libexpat to 2.2.2

[STINNER Victor]

STINNER Victor added the comment:

> #51  Address lack of stdint.h in Visual Studio 2003 to 2008

FYI this change only impacts Python 2.7, since Python 3.3 and newer requires 
Visual Studio 2010 or newer, and I already backported (cherry-picked) this 
specific commit in Python 2.7:
https://github.com/python/cpython/pull/2312/commits

> #58  Address compile warnings

That's my small contribution, so coming from CPython :-)
https://github.com/libexpat/libexpat/pull/58

> #76  Address compile warning with -DNDEBUG (not recommended!)

Nice contributions from Segev Finer, coming from CPython ;-)
https://github.com/libexpat/libexpat/issues/76

> #77  Address compile warning about macro redefinition

Another contribution of Segev Finer, already fixed downstream (in Python):
https://github.com/libexpat/libexpat/pull/77

--

___
Python tracker 

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

[issue30947] Update embeded copy of libexpat to 2.2.2

[STINNER Victor]

STINNER Victor added the comment:

About the 3 security fixes (is the last change a security fix?).

"""
 #43  Protect against compilation without any source of high
quality entropy enabled, e.g. with CMake build system;
commit ff0207e6076e9828e536b8d9cd45c9c92069b895
"""

Since Python uses its own entropy source, I don't think that this change 
impacts us.

https://github.com/libexpat/libexpat/commit/ff0207e6076e9828e536b8d9cd45c9c92069b895


"""
 #60  Windows with _UNICODE:
Unintended use of LoadLibraryW with a non-wide string
resulted in failure to load advapi32.dll and degradation
in quality of used entropy when compiled with _UNICODE for
Windows; you can launch existing binaries with
EXPAT_ENTROPY_DEBUG=1 in the environment to inspect the
quality of entropy used during runtime; commits
* 95b95032f907ef1cd17ee7a9a1768010a825d61d
* 73a5a2e9c081f49f2d775cf7ced864158b68dc80
"""

I don't understand the consequence of this specific bug.

https://github.com/libexpat/libexpat/commit/95b95032f907ef1cd17ee7a9a1768010a825d61d
https://github.com/libexpat/libexpat/commit/73a5a2e9c081f49f2d775cf7ced864158b68dc80


"""
   [MOX-006]  Fix non-NULL parser parameter validation in XML_Parse;
resulted in NULL dereference, previously;
commit ac256dafdffc9622ab0dc2c62fcecb0dfcfa71fe
"""

I'm not sure that it's possible to call XML_Parse() with NULL in Python.

https://github.com/libexpat/libexpat/commit/ac256dafdffc9622ab0dc2c62fcecb0dfcfa71fe

--

___
Python tracker 

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

[issue18558] Iterable glossary entry needs clarification

[Raymond Hettinger]

Raymond Hettinger added the comment:

The wold "iterable" just means "can be looped over".  There are many ways to 
implement this capability (two-arg form of iter(), the __iter__ method, 
generators, __getitem__ with integer indexing, etc).

collections.abc.Iterable is more limited and that is okay.  There is nothing 
that compels us to break an API has been around and successful for 26+ years.  
That clearly wasn't Guido's intention when he added  collections.abc.Iterable 
which is just a building block for more complex ABCs.

I recommend closing this.  We're not going to kill a useful API and break tons 
of code because of an overly pedantic reading of what is allowed to be iterable.

However we can make a minor amendment to the glossary entry to mention that 
there are multiple ways of becoming iterable.

Stephen, the try/except is a reasonable way to recognize an iterable.  The ABCs 
are intended to recognize only things that implement a particular 
implementation or that are registered.  It is not more encompassing or 
normative than that.

--
assignee: docs@python -> rhettinger
nosy: +rhettinger
versions: +Python 3.7 -Python 3.3, Python 3.4

___
Python tracker 

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

[issue30940] Documentation for round() is incorrect.

[Raymond Hettinger]

Raymond Hettinger added the comment:

> Wasn't this change a mistake? 

Now that it is deployed, it should probably be left alone (it is has to take 
back an API change), but this should be a cautionary note for arg-clinic 
enthusiasts to not change existing APIs.  When Argument Clinic is too limited 
to express what Python does for an exiting API, that particular function needs 
to be skipped.

--

___
Python tracker 

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

[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

[pfreixes]

pfreixes added the comment:

The following links point to three different implementations of the same 
scenario using a Twisted, Node and Python blocking clients that try to 
reproduce the same scenario.

- Twisted https://gist.github.com/pfreixes/0d8b24b98567e557d6059b3308aa07ca
- Node https://gist.github.com/pfreixes/b62c199e62ae09d1a5b9e13652c7a273
- Python blocking 
https://gist.github.com/pfreixes/7a85e43642782eb7e7d0669eadd0216a

All of them are able to give you the buffer when the RST package was already 
processed by the OS.

I'm still trying to get a Java client, but TBH I won't expect a different 
behavior.

--

___
Python tracker 

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

[issue30949] Provide assertion functions in unittest.mock

[Daniel Watkins]

New submission from Daniel Watkins:

The convenience assertion methods on mock objects can be easily mistyped and if 
they are mistyped, they will silently pass.  This can be quite user-hostile.  
Consider the following:

>>> example = Mock()
>>> example.assert_called_once()
>>> example.assert_caled_once_with(...)

This will not raise any exceptions, though the first feels natural and the 
latter is misspelt.  To avoid using the methods, one can type:

>>> example = Mock()
>>> assert example.call_count == 1
>>> assert example.call_args_list == [call(...)]

but the meaning of that latter statement is particularly non-obvious.  Instead, 
it would be great if I could import the assertions from mock as functions, and 
call them with mock as the first argument:

>>> from unittest.mock import assert_called_once  # This will be an ImportError
>>> example = Mock()
>>> assert_caled_once_with(example, ...)  # A NameError
>>> assert_called_once_with(example, ...)  # Great success!

--
components: Tests
messages: 298533
nosy: odd_bloke
priority: normal
severity: normal
status: open
title: Provide assertion functions in unittest.mock
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

[issue18558] Iterable glossary entry needs clarification

[Vedran Čačić]

Vedran Čačić added the comment:

Raymond, I think you didn't understand the issue. Glossary already _has_ the 
ammendment you mention (at least for the __getitem__ - I'm not sure any of 
other examples you mention are counterexamples to that interpretation: 
callable_iterators and generators _do_ have an __iter__ attribute, and they are 
correctly detected as instances of collections.abc.Iterable).

I wanted to push in the _opposite_ direction, to fully bless __getitem__ as a 
way to declare iterability, so it could be recognized by Iterable's 
instancecheck. Because it seems to me that whoever wrote that instancecheck, 
didn't have the _intention_ to exclude __getitem__ iteration.

Or at least, if we cannot do that because of backward compatibility:-(, to 
explicitly document that Iterable ABC _does not_ fully encompass what we mean 
by "being iterable".

--

___
Python tracker 

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

[issue30949] Provide assertion functions in unittest.mock

[tribaal]

Changes by tribaal :


--
nosy: +tribaal

___
Python tracker 

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

[issue18558] Iterable glossary entry needs clarification

[Raymond Hettinger]

Raymond Hettinger added the comment:

> Or at least, if we cannot do that because of backward
> compatibility:-(, to explicitly document that Iterable ABC
> _does not_ fully encompass what we mean by "being iterable".

That would be a reasonable amendment to collections.abc.Iterable docs.

I don't think it is either desirable or possible for collections.abc.Iterable 
to recognize iterables with __getitem__.  We cannot know it advance whether 
__getitem__ is a mapping or a sequence.  IIRC, that particular problem was the 
motivation for creating the ABCs. Without a user registering a class as 
Iterable or without inheriting from Iterable, there is really no way to know.

--

___
Python tracker 

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

[issue30948] Docs for __subclasses__(): Add hint that Python imports are lazy

[R. David Murray]

R. David Murray added the comment:

Thanks for the suggestion, but I don't think so.

Python imports are not lazy.  They are ordered.  Python is an *interpreted* 
language, so __subclasses__ is only going to hold those subclasses whose class 
definitions have been executed. This is fundamental to how the language works, 
and does not warrant a special note here.  Note that the entry already includes 
something that should give a strong hint about this even if you hadn't 
previously thought about it: the statement that it only includes subclasses 
that are "still alive".  This implies they aren't in the list until they become 
alive.

--
nosy: +r.david.murray
resolution:  -> rejected
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

[issue30940] Documentation for round() is incorrect.

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

round() was not converted to Argument Clinic. There is a special comment about 
this:

/* AC: cannot convert yet, as needs PEP 457 group support in inspect
 * or a semantic change to accept None for "ndigits"
 */

*Now* round() can be converted to Argument Clinic. I prepared a patch for this 
but wanted to make sure this is a desirable behavior.

--

___
Python tracker 

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

[issue30940] Documentation for round() is incorrect.

[Raymond Hettinger]

Raymond Hettinger added the comment:

> I prepared a patch for this but wanted to make sure this is a desirable 
> behavior.

That seems reasonable to me.  Mark, what do you think?

--

___
Python tracker 

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

[issue30950] Convert round() to Arument Clinic

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

When the builtins module was converted to Argument Clinic, round() was omitted 
because existing signature of round() wasn't supported with the inspect module. 
Now round() supports None as the value for the ndigits arguments, and this is 
the default value. round() now has the signature round(number, ndigits=None).

Proposed PR converts round() to Argument Clinic. This has two benefits:

1. inspect.signature() now works with round.

2. Faster parsing keyword arguments.

--
components: Interpreter Core
messages: 298539
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Convert round() to Arument Clinic
type: enhancement
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

[issue18558] Iterable glossary entry needs clarification

[Vedran Čačić]

Vedran Čačić added the comment:

Yes, the mapping/sequence distinction was (at least declaratively) the reason 
the ABCs were introduced, but that isn't an obstacle here: whether a mapping or 
a sequence, it _is_ iterable, right?

---

In case anybody is interested, here's how I came to this problem: at a 
programming competition, I set a problem where contestants had to write some 
function, and I declared that "the function must work for arbitrary iterable 
(with some properties that currently don't matter)".

Then a big discussion ensued, with a big group of people thinking that classes 
with __getitem__ but no __iter__ don't quality (giving collections.abc.Iterable 
as an argument), and another big group of people thinking they do (giving EAFP 
as an argument: "look, I tried iterating, and succeeded").

Of course, it's an incredibly technical detail, but I don't like such gray 
areas. To me, things with __getitem__ are clearly iterable - the glossary says 
so:-). Iterable's instancecheck is simply buggy ("incomplete", if you want). 
There might be valid reasons for keeping it buggy, but they should be 
documented.

--

___
Python tracker 

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

[issue30950] Convert round() to Arument Clinic

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +2800

___
Python tracker 

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

[issue27640] add the '--disable-test-suite' option to configure

[Ed Morley]

Changes by Ed Morley :


--
nosy: +edmorley

___
Python tracker 

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

[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

[Guido van Rossum]

Guido van Rossum added the comment:

There's no need. You seem to have accidentally shown a use case for getting the 
buffered data -- it can contain an error message explaining why the connection 
was closed.

--

___
Python tracker 

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

[issue30950] Convert round() to Arument Clinic

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
dependencies: +Documentation for round() is incorrect.
nosy: +mark.dickinson, rhettinger

___
Python tracker 

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

[issue30940] Documentation for round() is incorrect.

[Mark Dickinson]

Mark Dickinson added the comment:

Sure, fine with me to add AC support for round.

--

___
Python tracker 

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

[issue19896] Exposing "q" and "Q" to multiprocessing.sharedctypes

[Antoine Pitrou]

Antoine Pitrou added the comment:

Uh, it's a pity this patch has been overlooked.
Gareth, would you want to make a Github PR out of this?

--
nosy: +pitrou
type:  -> enhancement
versions: +Python 3.7 -Python 3.4

___
Python tracker 

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

[issue18558] Iterable glossary entry needs clarification

[R. David Murray]

R. David Murray added the comment:

"things with __getitem__ are clearly iterable"

This is false.  IMO it should be fixed in the glossary.  It should say "or 
__getitem__ method implementing sequence semantics".  That plus the addition to 
the Iterable docs will close this issue.

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

[issue30951] Documentation error in inspect module

[Alex Vig]

New submission from Alex Vig:

The documentation for co_names in the inspect module is:

"tuple of names of local variables"

Local variable names are however in co_varnames while co_names contains global 
variable names. This description should read:

"tuple of names of global variables"

Relevant StackOverflow post here:

https://stackoverflow.com/q/45147260/1953800

--
assignee: docs@python
components: Documentation
messages: 298545
nosy: Alex Vig, docs@python
priority: normal
severity: normal
status: open
title: Documentation error in inspect module
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

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

[issue19896] Exposing "q" and "Q" to multiprocessing.sharedctypes

[Gareth Rees]

Gareth Rees added the comment:

Has Antony Lee has made a copyright assignment?

--

___
Python tracker 

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

[issue19896] Exposing "q" and "Q" to multiprocessing.sharedctypes

[Antoine Pitrou]

Antoine Pitrou added the comment:

According to the asterisk displayed right of his name, he has, yes.

--

___
Python tracker 

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