[issue30119] (ftplib) A remote attacker could possibly attack by containing the newline characters

[Dong-hee Na]

Changes by Dong-hee Na :


--
pull_requests: +2939

___
Python tracker 

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

[issue30119] (ftplib) A remote attacker could possibly attack by containing the newline characters

[Dong-hee Na]

Changes by Dong-hee Na :


--
pull_requests: +2938

___
Python tracker 

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

[issue30119] (ftplib) A remote attacker could possibly attack by containing the newline characters

[Ned Deily]

Ned Deily added the comment:


New changeset a4e774f86224cd8c997deaa4e71312cf1a7b023c by Ned Deily (Dong-hee 
Na) in branch '3.3':
[3.3] bpo-30119: fix ftplib.FTP.putline() to throw an error for a illegal 
command (#1214) (#2885)
https://github.com/python/cpython/commit/a4e774f86224cd8c997deaa4e71312cf1a7b023c


--

___
Python tracker 

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

[issue30841] A shadowing variable naming emitted for Python-ast.c

[Benjamin Peterson]

Benjamin Peterson added the comment:

What actually omits warnings about this?

--

___
Python tracker 

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

[issue30119] (ftplib) A remote attacker could possibly attack by containing the newline characters

[Dong-hee Na]

Changes by Dong-hee Na :


--
pull_requests: +2937

___
Python tracker 

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

[issue29505] Submit the re, json, & csv modules to oss-fuzz testing

[Devin Jeanpierre]

Devin Jeanpierre added the comment:

I think they misspoke, it's normal with fuzzing to test against master. The 
current draft of the code runs this git pull before building/launching any 
tests:

git clone --depth 1 https://github.com/python/cpython.git cpython

Speaking of which, I forgot to update this bug thread with the followup PR to 
actually run CPython's fuzz tests (when they exist): 
https://github.com/google/oss-fuzz/pull/731. That's where I grabbed the git 
clone statement from. I think that will be merged after some version of PR 2878 
lands in CPython (still in code review / broken).



For Python 2 I guess it's different, and we will test against the 2.7 branch, 
right?

--

___
Python tracker 

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

[issue1732367] Document the constants in the socket module

[Ammar Askar]

Ammar Askar added the comment:

Gonna take this and its dependencies on, eta 2-4 days.

--
nosy: +ammar2

___
Python tracker 

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

[issue30119] (ftplib) A remote attacker could possibly attack by containing the newline characters

[Dong-hee Na]

Dong-hee Na added the comment:

Okay, I will send backport today.

--

___
Python tracker 

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

[issue30119] (ftplib) A remote attacker could possibly attack by containing the newline characters

[Ned Deily]

Ned Deily added the comment:

Just FYI, if the backports to 3.5, 3.4, and 3.3 happen *really* fast, we 
*might* be able to get them into the current round of releases, if Larry 
approves for 3.5.4 final and 3.4.7 final.  If the 3.3 backport doesn't happen 
soon, 3.3 will reach end of life without it.

--
keywords: +security_issue
nosy: +benjamin.peterson, georg.brandl, larry, ned.deily
priority: normal -> release blocker

___
Python tracker 

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

[issue26657] Directory traversal with http.server and SimpleHTTPServer on windows

[Ned Deily]

Changes by Ned Deily :


--
versions: +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

[issue26657] Directory traversal with http.server and SimpleHTTPServer on windows

[Ned Deily]

Ned Deily added the comment:


New changeset 7b92f9fa47df754b50c64aac84cf1c09693571af by Ned Deily (Victor 
Stinner) in branch '3.3':
bpo-26657: Fix Windows directory traversal vulnerability with http.server 
(#782) (#2860)
https://github.com/python/cpython/commit/7b92f9fa47df754b50c64aac84cf1c09693571af


--
nosy: +ned.deily

___
Python tracker 

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

[issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client (CVE-2016-5699)

[Ned Deily]

Changes by Ned Deily :


--
assignee: georg.brandl -> 
priority: release blocker -> 
resolution:  -> fixed
stage: backport needed -> resolved
status: open -> closed

___
Python tracker 

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

[issue31040] mimetypes.add_type should complain when you give it an undotted ext

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python
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

[issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client (CVE-2016-5699)

[Ned Deily]

Ned Deily added the comment:


New changeset 8e88f6b5e2a35ee458c161aa3f2b7f1f17fb45d1 by Ned Deily (Serhiy 
Storchaka) in branch '3.3':
[3.3] bpo-22928: Disabled HTTP header injections in http.client. (#2817)
https://github.com/python/cpython/commit/8e88f6b5e2a35ee458c161aa3f2b7f1f17fb45d1


--

___
Python tracker 

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

[issue30595] test_queue_feeder_donot_stop_onexc() of test_multiprocessing_spawn fails randomly on x86 Windows7 3.x

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +2935

___
Python tracker 

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

[issue30595] test_queue_feeder_donot_stop_onexc() of test_multiprocessing_spawn fails randomly on x86 Windows7 3.x

[STINNER Victor]

STINNER Victor added the comment:


New changeset e42339d3a08a8fde3349722def85d7a8e49899be by Victor Stinner in 
branch '3.6':
[3.6] bpo-30595: Fix multiprocessing.Queue.get(timeout) (#2027) (#2881)
https://github.com/python/cpython/commit/e42339d3a08a8fde3349722def85d7a8e49899be


--

___
Python tracker 

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

[issue28777] Add asyncio.Queue __aiter__, __anext__ methods

[Guido van Rossum]

Guido van Rossum added the comment:

> > there's no way to end the loop on the producing side.

> I might be missing something, but can't something similar be said of 
> queue.get()?

That's my point, actually. If you are wrapping the Queue protocol with 
__aiter__/__anext__ the caller would expect there's a way to signal to the 
latter that the loop is over (so it can raise StopAsyncIteration). But since 
.get() doesn't have a way to signal this, an async for-loop would not be able 
to terminate (other than through break).

--

___
Python tracker 

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

[issue30119] (ftplib) A remote attacker could possibly attack by containing the newline characters

[STINNER Victor]

STINNER Victor added the comment:

I closed bpo-29606 as a duplicate of this bug.

--
superseder: urllib FTP protocol stream injection -> 

___
Python tracker 

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

[issue29606] urllib FTP protocol stream injection

[STINNER Victor]

STINNER Victor added the comment:

Hum, bpo-30119 is really the same bug. So I closed this one as a duplicate of 
bpo-30119.

--
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> (ftplib) A remote attacker could possibly attack by containing 
the newline characters

___
Python tracker 

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

[issue27945] Various segfaults with dict

[Ned Deily]

Changes by Ned Deily :


--
priority: release blocker -> 
resolution:  -> fixed
stage: commit 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

[issue27945] Various segfaults with dict

[Ned Deily]

Ned Deily added the comment:


New changeset 8fbdab50fc8f2b71f19b54f3a0208cfbf2be7713 by Ned Deily (Serhiy 
Storchaka) in branch '3.3':
[3.3] [3.5] bpo-27945: Fixed various segfaults with dict. (GH-1657) (GH-1678) 
(#2396)
https://github.com/python/cpython/commit/8fbdab50fc8f2b71f19b54f3a0208cfbf2be7713


--

___
Python tracker 

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

[issue30845] [3.5] test_first_completed_some_already_completed() of test_concurrent_futures.ProcessPoolWaitTests: time.sleep() fails with "sleep length must be non-negative" in setUp() on x86 Tiger 3.

[STINNER Victor]

STINNER Victor added the comment:


New changeset a6f045224a03f9b5f940c80ee142a2a4b4a9c9d8 by Victor Stinner in 
branch '3.6':
bpo-30845: Enhance test_concurrent_futures cleanup (#2564) (#2880)
https://github.com/python/cpython/commit/a6f045224a03f9b5f940c80ee142a2a4b4a9c9d8


--

___
Python tracker 

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

[issue31042] Inconsistency in documentation of operator.index

[Joseph Fox-Rabinovitz]

New submission from Joseph Fox-Rabinovitz:

The docs for [`operator.index`][1] and `operator.__index__` state that

> Return *a* converted to an integer. Equivalent to `a.__index__()`.

The first sentence is correct, but the second is not. First of all, we have the 
data model [docs][2]:

> For custom classes, implicit invocations of special methods are only 
> guaranteed to work correctly if defined on an object’s type, not in the 
> object’s instance dictionary.

Secondly, we can make a simple counter-example in code:

```
import operator

class A:
def __index__(self): return 0

a = A()
a.__index__ = (lambda self: 1).__get__(a, type(a))
operator.index(a)
```

The result is of course zero and not one.

I believe that the docs should read something more like one of the following to 
avoid being misleading:

> Return *a* converted to an integer, if it is already an integral type.

> Return *a* converted to an integer. Equivalent to `type(a).__index__(a)`.

Or a combination of both:

> Return *a* converted to an integer, if it is already an integral type. 
> Equivalent to `type(a).__index__(a)`.

  [1]: https://docs.python.org/3/library/operator.html#operator.index
  [2]: https://docs.python.org/3/reference/datamodel.html#special-method-lookup

--
assignee: docs@python
components: Documentation
messages: 299195
nosy: docs@python, madphysicist
priority: normal
severity: normal
status: open
title: Inconsistency in documentation of operator.index
type: behavior
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

[issue31042] Inconsistency in documentation of operator.index

[Joseph Fox-Rabinovitz]

Changes by Joseph Fox-Rabinovitz :


--
type: behavior -> 

___
Python tracker 

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

[issue20657] OpenBSD: Merge patches

[STINNER Victor]

STINNER Victor added the comment:

I'm sorry but there is no more OpenBSD buildbot. I have no more OpenBSD VM. I 
just close this old issue :-(

--
resolution:  -> out of date
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

[issue25287] test_crypt fails on OpenBSD

[STINNER Victor]

STINNER Victor added the comment:

There is no more OpenBSD buildbot. I have no OpenBSD VM. I just close this old 
issue.

--
resolution:  -> out of date
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

[issue26642] Replace stdout and stderr with simple standard printers at Python exit

[STINNER Victor]

STINNER Victor added the comment:

I'm not sure that it's correct to replace sys.stdout with a simple object which 
can use a different encoding. I prefer to just close this old issue (idea).

--
resolution:  -> out of date
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

[issue29972] Skip tests known to fail on AIX

[STINNER Victor]

STINNER Victor added the comment:

The issue title is very generic. I skipped some tests. I may reopen a new issue 
if I see other tests that can be skipped on AIX.

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

[issue26762] test_multiprocessing_spawn leaves processes running in background

[STINNER Victor]

STINNER Victor added the comment:

Ok, now test_multiprocessing_spawn should not "leak" processes nor threads 
anymore. I fixed Python 3.6 and master. I close the issue.

I don't think that it's worth it to fix tests in 2.7, and 3.5 is entering 
security-only mode.

Note: I will backport bpo-31019 to Python 2.7, since this issue changes the 
code, not tests.

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

[issue30500] [security] urllib connects to a wrong host

[Ned Deily]

Changes by Ned Deily :


--
assignee:  -> haypo
resolution:  -> fixed
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

[issue31019] multiprocessing.Pool should join "dead" processes

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +2934

___
Python tracker 

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

[issue31019] multiprocessing.Pool should join "dead" processes

[STINNER Victor]

STINNER Victor added the comment:


New changeset d0adfb25c5082046133a18fd185375508c1c334f by Victor Stinner in 
branch '3.6':
[3.6] bpo-26762, bpo-31019: Backport multiprocessing fixes from master to 3.6 
(#2879)
https://github.com/python/cpython/commit/d0adfb25c5082046133a18fd185375508c1c334f


--

___
Python tracker 

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

[issue26762] test_multiprocessing_spawn leaves processes running in background

[STINNER Victor]

STINNER Victor added the comment:


New changeset d0adfb25c5082046133a18fd185375508c1c334f by Victor Stinner in 
branch '3.6':
[3.6] bpo-26762, bpo-31019: Backport multiprocessing fixes from master to 3.6 
(#2879)
https://github.com/python/cpython/commit/d0adfb25c5082046133a18fd185375508c1c334f


--

___
Python tracker 

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

[issue30595] test_queue_feeder_donot_stop_onexc() of test_multiprocessing_spawn fails randomly on x86 Windows7 3.x

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +2933

___
Python tracker 

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

[issue30713] Reject newline character (U+000A) in URLs in urllib.parse

[STINNER Victor]

STINNER Victor added the comment:

https://bugs.python.org/issue29606 was fixed in ftplib. urllib is not the right 
place to reject invalid inputs.

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

[issue30500] [security] urllib connects to a wrong host

[Ned Deily]

Ned Deily added the comment:


New changeset 052f9d6860c48c5abcff8e16212e77cf4249d66c by Ned Deily (Victor 
Stinner) in branch '3.3':
[3.3] bpo-30500: urllib: Simplify splithost by calling into urlparse. (#1849) 
(#2292)
https://github.com/python/cpython/commit/052f9d6860c48c5abcff8e16212e77cf4249d66c


--

___
Python tracker 

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

[issue30845] [3.5] test_first_completed_some_already_completed() of test_concurrent_futures.ProcessPoolWaitTests: time.sleep() fails with "sleep length must be non-negative" in setUp() on x86 Tiger 3.

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +2932

___
Python tracker 

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

[issue17560] problem using multiprocessing with really big objects?

[Daniel Liu]

Daniel Liu added the comment:

There's also the other multiprocessing limitation Antoine mentioned early on, 
where queues/pipes used a 32-bit signed integer to encode object length.

Is there a way or plan to get around this limitation?

--
nosy: +Daniel Liu

___
Python tracker 

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

[issue30891] importlib: _find_and_load() race condition on sys.modules[name] check

[STINNER Victor]

STINNER Victor added the comment:

With Python 3.5.4rc1 released (3.5.4 will be the last 3.5 release accepting bug 
fixes), I'm not sure that it's still worth it to try to backport such changes 
to Python 3.5. The importlib is very important, any regression can be very 
important.

I'm not sure that backporting the unit test is interesting. If the test fails, 
we will be unable to fix it.

--

___
Python tracker 

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

[issue26762] test_multiprocessing_spawn leaves processes running in background

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +2930

___
Python tracker 

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

[issue31019] multiprocessing.Pool should join "dead" processes

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +2931

___
Python tracker 

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

[issue29505] Submit the re, json, & csv modules to oss-fuzz testing

[Terry J. Reedy]

Terry J. Reedy added the comment:

As I read 583, they are planning to fuzz 3.6.  Why not branch master?  I think 
it more likely that we accidentally add a vulnerability to master then that we 
accidentally close one.

--

___
Python tracker 

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

[issue30119] (ftplib) A remote attacker could possibly attack by containing the newline characters

[STINNER Victor]

STINNER Victor added the comment:

What about rejecting also NUL byte?

--
status: pending -> open

___
Python tracker 

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

[issue1732367] Document the constants in the socket module

[Ned Deily]

Changes by Ned Deily :


--
assignee: georg.brandl -> 
versions: +Python 3.7 -Python 2.6

___
Python tracker 

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

[issue23404] 'make touch' does not work with git clones of the source repository

[Ned Deily]

Ned Deily added the comment:

There still might be time to get this into 3.5.4 final, if Larry agrees.

--

___
Python tracker 

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

[issue30119] (ftplib) A remote attacker could possibly attack by containing the newline characters

[Ned Deily]

Changes by Ned Deily :


--
status: open -> pending

___
Python tracker 

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

[issue30119] (ftplib) A remote attacker could possibly attack by containing the newline characters

[Ned Deily]

Changes by Ned Deily :


--
nosy: +haypo
status: pending -> open

___
Python tracker 

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

[issue31041] test_handle_called_with_mp_queue() of test_logging: threading_cleanup() failed to cleanup, on AMD64 FreeBSD 10.x Shared 3.x

[STINNER Victor]

Changes by STINNER Victor :


--
title: test_handle_called_with_mp_queue() of test_logging: threading_cleanup() 
failed to cleanup -> test_handle_called_with_mp_queue() of test_logging: 
threading_cleanup() failed to cleanup, on AMD64 FreeBSD 10.x Shared 3.x

___
Python tracker 

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

[issue31041] test_handle_called_with_mp_queue() of test_logging: threading_cleanup() failed to cleanup

[STINNER Victor]

New submission from STINNER Victor:

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

(...)
test_output (test.test_logging.UnixSocketHandlerTest) ... ok
test_output (test.test_logging.UnixDatagramHandlerTest) ... ok
test_output (test.test_logging.UnixSysLogHandlerTest) ... ok
test__all__ (test.test_logging.MiscTestCase) ... ok
test_handle_called_with_mp_queue (test.test_logging.QueueListenerTest) ... 
Warning -- threading_cleanup() failed to cleanup -1 threads after 4 sec (count: 
0, dangling: 1)
ok
test_handle_called_with_queue_queue (test.test_logging.QueueListenerTest) ... ok
test_no_messages_in_queue_after_stop (test.test_logging.QueueListenerTest) ... 
ok
(...)

See also bpo-30830: "HTTPHandlerTest of test_logging leaks a "dangling" thread 
on AMD64 FreeBSD CURRENT Non-Debug 3.x".

Previously fixed warnings: bpo-30131.

--
components: Tests
keywords: buildbot
messages: 299180
nosy: haypo
priority: normal
severity: normal
status: open
title: test_handle_called_with_mp_queue() of test_logging: threading_cleanup() 
failed to cleanup
type: resource usage
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

[issue31034] test_subprocess_send_signal() of test_asyncio hangs if SIGHUP is ignored

[STINNER Victor]

STINNER Victor added the comment:

Ok, I fixed Python 3.6 and master (future 3.7). Python 3.5 is slowly entering 
security-only fixes. I don't think that this corner case is improtant enough to 
justify a backport.

--

___
Python tracker 

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

[issue31034] test_subprocess_send_signal() of test_asyncio hangs if SIGHUP is ignored

[STINNER Victor]

Changes by STINNER Victor :


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

[issue31034] test_subprocess_send_signal() of test_asyncio hangs if SIGHUP is ignored

[STINNER Victor]

STINNER Victor added the comment:


New changeset efe9fcbd2ca85ba9d6af6d95cc530a9c332f37c5 by Victor Stinner in 
branch '3.6':
bpo-31034: Reliable signal handler for test_asyncio (#2867) (#2876)
https://github.com/python/cpython/commit/efe9fcbd2ca85ba9d6af6d95cc530a9c332f37c5


--

___
Python tracker 

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

[issue31019] multiprocessing.Pool should join "dead" processes

[STINNER Victor]

STINNER Victor added the comment:


New changeset 2db64823c20538a6cfc6033661fab5711d2d4585 by Victor Stinner in 
branch 'master':
bpo-31019: Fix multiprocessing.Process.is_alive() (#2875)
https://github.com/python/cpython/commit/2db64823c20538a6cfc6033661fab5711d2d4585


--

___
Python tracker 

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

[issue29505] Submit the re, json, & csv modules to oss-fuzz testing

[Devin Jeanpierre]

Changes by Devin Jeanpierre :


--
pull_requests: +2929

___
Python tracker 

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

[issue30778] test_bsddb3 crash on x86 Windows XP 2.7

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +2928

___
Python tracker 

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

[issue30778] test_bsddb3 crash on x86 Windows XP 2.7

[STINNER Victor]

STINNER Victor added the comment:

I opened a thread on python-dev and it was decided to skip test_bsddb3 on 
Windows XP:
https://mail.python.org/pipermail/python-dev/2017-July/148745.html

--

___
Python tracker 

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

[issue30885] test_subprocess hangs on AMD64 Windows8.1 Refleaks 3.x

[STINNER Victor]

STINNER Victor added the comment:

test_subprocess passed on the last builds 56 (Jul 20) and 57 (Jul 25).

--

___
Python tracker 

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

[issue30908] test_os.TestSendfile.test_keywords() leaks dangling threads

[STINNER Victor]

Changes by STINNER Victor :


--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.5, Python 3.6

___
Python tracker 

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

[issue26732] multiprocessing sentinel resource leak

[STINNER Victor]

STINNER Victor added the comment:

Antoine: Do you want to backport your change 
896145d9d266ee2758cfcd7691238cbc1f9e1ab8 to Python 3.6? If yes, don't forget to 
include my fix 302bbbe9ba5c72559913e2ea006c921f698a729d for Windows (bpo-31009).

If you prefer, I can handle the backport.

--

___
Python tracker 

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

[issue31009] test_multiprocessing_spawn hangs randomly on AMD64 Windows10 3.x and AMD64 Windows8 3.x

[STINNER Victor]

STINNER Victor added the comment:

Windows buildbots are green again, I close the issue.

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

[issue31034] test_subprocess_send_signal() of test_asyncio hangs if SIGHUP is ignored

[STINNER Victor]

STINNER Victor added the comment:

Patch to test manually the fix:

diff --git a/Lib/test/test_asyncio/__init__.py 
b/Lib/test/test_asyncio/__init__.py
index 80a9eea..1418952 100644
--- a/Lib/test/test_asyncio/__init__.py
+++ b/Lib/test/test_asyncio/__init__.py
@@ -1,3 +1,4 @@
+import signal; signal.signal(signal.SIGHUP, signal.SIG_IGN)
 import os
 from test.support import load_package_tests, import_module

--

___
Python tracker 

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

[issue31034] test_subprocess_send_signal() of test_asyncio hangs if SIGHUP is ignored

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +2927

___
Python tracker 

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

[issue30985] Set closing variable in asyncore at close

[Giampaolo Rodola']

Giampaolo Rodola' added the comment:

I would probably feel safer to use "__closed" for all python versions and adopt 
the same naming convention for any attribute we may want to add in the future. 
Kinda weird, but asyncore is probably the only case of deprecated module with 
bad API design which makes it risky to make any change to the class namespace. 
As such I consider using the ugly "__" prefix justifiable.

--

___
Python tracker 

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

[issue31019] multiprocessing.Pool should join "dead" processes

[STINNER Victor]

STINNER Victor added the comment:

Hum, I don't think that https://github.com/python/cpython/pull/2849 fixes the 
root issue.

The root issue is that calling Process.is_alive() doesn't update the _children 
list if the process completes. I wrote a fix for that:
https://github.com/python/cpython/pull/2875

--

___
Python tracker 

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

[issue31019] multiprocessing.Pool should join "dead" processes

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +2926

___
Python tracker 

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

[issue31036] building the python docs requires the blurb module

[Larry Hastings]

Larry Hastings added the comment:

What you're missing is that Misc/NEWS.d is removed from tarballs.  We ship 
Misc/NEWS in tarballs but *not* Misc/NEWS.d.

If you start with a CPython tarball (e.g. 3.5.4rc1), and then apply 
vendor-specific patches on top of that, and those patches include news entries 
in Misc/NEWS.d, and you want to ship a unified Misc/NEWS file that contains 
those entries, then you'll have to use "blurb split" to repopulate Misc/NEWS.d 
from Misc/NEWS followed by "blurb merge" to reconstitute Misc/NEWS from 
Misc/NEWS.d.

FWIW, right now any entries under "Misc/NEWS.d/next" would appear in Misc/NEWS 
under the heading "What's new in Python next?", rather than e.g. "What's new in 
Python 3.5.4 release candidate 1?".  This would be a little curious.  blurb is 
only set up to understand "next" and CPython version numbers there; convincing 
it to put something else there would be a non-trivial amount of work.

On a related subject, I should mention something about blurb aggregated version 
files, e.g. "Misc/NEWS.d/3.5.4rc1.rst".  blurb doesn't know how to append / 
prepend to those, nor does it know how to combine two of them together.  It 
just isn't a feature I needed for CPython.  My guess is adding support for this 
wouldn't be too bad, and it may yet be helpful for doko's use case.  Something 
to keep in mind.

--

___
Python tracker 

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

[issue31036] building the python docs requires the blurb module

[Ned Deily]

Ned Deily added the comment:

> I expect that in a tarball, Misc/NEWS and Misc/NEWS.d contain exactly the 
> same entries.

They don't.  See for yourself :)

https://www.python.org/ftp/python/3.5.4/Python-3.5.4rc1.tgz

--

___
Python tracker 

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

[issue31036] building the python docs requires the blurb module

[STINNER Victor]

STINNER Victor added the comment:

If we provide a prebuilt Misc/NEWS in tarball, if Makefile doesn't need blurb 
if Misc/NEWS already exists, doko's issue is fixed: Debian package builder will 
not need blurb anymore (PR 2874).


> If the upstream patches are extracted from GitHub PRs, then they'd presumably 
> have files in Misc/NEWS.d.  You could just ignore them.

If a vendor don't want to rely on blurb, I think that it's acceptable tradeoff.

Usually, each backported change is documented in a vendor specific changelog 
anyway.

Maybe tomorrow, some Linux vendors will start using blurb, but I suggest to 
work step by step, and first focus on the Python 3.5 "regression" fixed by PR 
2874.

--

> But you could run "blurb split", breaking Misc/NEWS into constituent files in 
> Misc/NEWS.d, and then "blurb merge", rebuilding Misc/NEWS from those 
> constituent files in Misc/NEWS.d.

I'm not following you. If you want to rebuild Misc/NEWS, why not just removing 
Misc/NEWS and then run blurb merge?

I expect that in a tarball, Misc/NEWS and Misc/NEWS.d contain exactly the same 
entries.

--

___
Python tracker 

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

[issue31036] building the python docs requires the blurb module

[Ned Deily]

Ned Deily added the comment:

I just pushed PR 2874 (for 3.5) for review.  I think it will solve the tarball 
problem.  Review comments welcome.  I'm still thinking about how to make blurb 
more easily "discoverable".  That would be a separate PR.

--

___
Python tracker 

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

[issue30985] Set closing variable in asyncore at close

[STINNER Victor]

STINNER Victor added the comment:

It seems like the closing attribute is not *required* to fix bpo-30931, 
asyncore race condition:
http://bugs.python.org/issue30931#msg299162

Another approach doesn't rely on close() "implementation", but more on close() 
"expected behaviour" (remove the dispatcher file descriptor from map). IMHO 
this approach would reduce the risk of backward incompatibility.

--

I'm still in favor of rejecting this feature request, *but* I would prefer to 
first wait until we agree how to fix bpo-30931 race condition.

--

___
Python tracker 

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

[issue31036] building the python docs requires the blurb module

[Ned Deily]

Changes by Ned Deily :


--
pull_requests: +2925

___
Python tracker 

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

[issue30931] Race condition in asyncore may access the wrong dispatcher

[STINNER Victor]

STINNER Victor added the comment:

> There's an alternative fix which follows a similar approach to the one you 
> mention: https://github.com/python/cpython/pull/2707/.

Sorry, I'm slow to understand. Now that the bug and expected behaviour is 
better explained, I can now review correctly your PR and I like it :-)

While you wrote you previous comment, I updated my PR to implement a similar 
idea:
https://github.com/python/cpython/pull/2854

My code now detects if a dispatcher was closed, but also if it's file 
descriptor was reused by a newly registered dispatcher.

Our PR are similar:

* create a copy before starting to run handler
* check if our copy is still consistent to the current map: if not, skip the 
dispatcher handler

My PR is different:

* It only creates a list of ready objects: it might be cheaper if only few file 
descriptors are ready, whereas the map is large... I don't think that it's a 
real performance bottleneck in practice, but well, I'm just trying to compare 
our implementations :-) ... To be honest, my PR is a copy of your other PR, not 
you wrote both versions in fact ;-) (that's why I credited you as co-author in 
my PR)

* My PR has a simpler and more specific unit test: only testing the poll() 
function, no server, no client: just handlers.

* My PR also tests when a dispatcher was only closed, not replaced.

--

Good! It seems like slowly we converge to a solution, no? Now, it's more 
bikeshedding on the exact implementation ;-)

--

___
Python tracker 

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

[issue25910] Fixing links in documentation

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
pull_requests: +2924

___
Python tracker 

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

[issue31036] building the python docs requires the blurb module

[Larry Hastings]

Larry Hastings added the comment:

I guess it depends on what the upstream patches look like.  If they're always 
coded against release tarballs and not against git repos, then they'll assume 
(correctly) that Misc/NEWS exists.  In that case you shouldn't have to do 
anything.

If the upstream patches are extracted from GitHub PRs, then they'd presumably 
have files in Misc/NEWS.d.  You could just ignore them.

blurb doesn't support combining Misc/NEWS.d files with an existing Misc/NEWS 
file in a single operation.  But you could run "blurb split", breaking 
Misc/NEWS into constituent files in Misc/NEWS.d, and then "blurb merge", 
rebuilding Misc/NEWS from those constituent files in Misc/NEWS.d.  Naturally 
this would pick up the new files from Misc/NEWS.d too.

Currently blurb is designed for the CPython developer workflow, so operations 
like "blurb split" and "blurb merge" also automatically stage the files in git. 
 I can add a flag to suppress this feature, if it's going to become common that 
"blurb split" and "blurb merge" are run on tarballs.

--

___
Python tracker 

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

[issue30931] Race condition in asyncore may access the wrong dispatcher

[Jaume]

Jaume added the comment:

There's an alternative fix which follows a similar approach to the one you 
mention: https://github.com/python/cpython/pull/2707/.

I personally don't like too much to reuse again again an old variable as it's 
true that we don't know how people are using it (although I take they use it as 
a boolean since it's assigned to False).

On the other side this approach copies the map when it's not strictly necessary 
to do use just because we can't do it the proper way by using closing, as shown 
in the PR using it: https://github.com/python/cpython/pull/2764/files

--

___
Python tracker 

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

[issue31036] building the python docs requires the blurb module

[Ned Deily]

Ned Deily added the comment:

(Of course the above also applies to installed copies of Misc/NEWS, like 
Debian's /usr/share/doc/pythonx.x/NEWS.gz.  The vanilla main Python Makefile 
doesn't install NEWS.)

--

___
Python tracker 

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

[issue31036] building the python docs requires the blurb module

[Ned Deily]

Ned Deily added the comment:

The good news is that the released tarballs starting now and going forward will 
already have a generated Misc/NEWS just like they always have had.  So blurb is 
not needed if you are building docs from such tarballs (like 3.5.4rc1).  We did 
forget about building docs directly from the tarball so we'll fix the Doc 
Makefile to use an existing Misc/NEWS file and not use blurb at all in that 
case. I think that should cover your first use case.

(If you are building from a git repo, you will need to use blurb as Misc/NEWS 
is no longer a checked-in file.  As I've tried to explain before, just running 
"make venv" and "make html" currently isn't sufficient; one needs to either 
activate the virtual env or fiddle with Doc Makefile variables PYTHON, 
SPHINXBUILD, and/or now BLURB.  I'm trying to see if I can make that smarter.)

Your second use case is more complicated, if I understand it correctly.  If you 
are generating the diff from a repo, going forward there won't be a unified 
Misc/NEWS file in the repo, rather there will be individual files added to 
Misc/NEWS.d for each checkin with a NEWS entry and those individual files have 
metadata meaningful to blurb.  When the release tarball is made, Misc/NEWS.d/* 
is removed and replaced by a blurb-generated Misc/NEWS file.  So if you are 
adding upstream pre-release diffs, you would have to run blurb as part of the 
process of building the docs. But I don't think blurb currently is designed to 
to handle the case of combining an existing generated Misc/NEWS file (from the 
tarball) with additional NEWS.d files. So I guess one solution would be you 
need to build the docs from the Git repo or at least copy the Misc/NEWS.d from 
the repo at the release tag and add the NEWS.d files for the cherrypicked 
pre-release fixes to it and then run blurb on it.  But I may have mi
 sunderstand and I should let Larry speak for blurb.

--

___
Python tracker 

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

[issue31036] building the python docs requires the blurb module

[Larry Hastings]

Larry Hastings added the comment:

>  Sorry to say, but the assumption that pip should be used to be able to build 
> core python seems to be the wrong direction.

I'm not sure I understand your position.  External tools are only permissible 
if Debian packages exist for them?

And, it's not "core python", it's the Python documentation, which has always 
depended on external tools.  The dependencies for CPython itself (the "python" 
executable) have not changed.

--

___
Python tracker 

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

[issue30853] IDLE: configdialog -- factor out Tracer subclass

[Cheryl Sabella]

Changes by Cheryl Sabella :


--
pull_requests: +2923

___
Python tracker 

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

[issue30931] Race condition in asyncore may access the wrong dispatcher

[STINNER Victor]

STINNER Victor added the comment:

If I understood correctly, to fix this race condition, there are two main 
constraints:

(A) We must call handlers of dispatcher registered before calling 
select()/poll(): dispatchers can be closed and their file descriptor can be 
reused while we execute other dispatchers

(B) Don't call closed dispatcher

--

For (A), I only see one option: copy somehow the map, for example using: ready 
= [(map[fd], flags) for fd, flags in r]

--

For (B), it's more tricky.

The bpo-30985 proposes to start using the closing: I'm not sure that it's 
doable in a stable version like 3.6, or worse in 2.7, since existing code may 
use closing differently.
http://bugs.python.org/issue30985#msg299154

I'm also concerned about subclassing: if a subclass overrides *completely* 
close(), we would fail to detect that the dispatcher was closed. Maybe this 
corner doesn't occur in the wild?

I see a different approach: while iterating on "ready" objects, check again if 
map.get(fd) still is the expected dispatcher. If the file descriptor is no more 
registered in map: it was closed. If we get a new dispatcher: not only the 
previous dispatcher was closed, but a new dispatcher also got the same file 
descriptor and was registered in the map.

Do you think that this approach would work? Would it be safer in term of 
backward compatibility?

--

___
Python tracker 

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

[issue26732] multiprocessing sentinel resource leak

[Kevin Quick]

Kevin Quick added the comment:

Thank you for the fix, pitrou!

Regarding your comment regarding the behavior being expected with the "fork" 
method, I would suggest a documentation modification in the description of the 
fork method to add something to the effect of "All resources of the parent are 
inherited by the child process; this includes the ability of later children to 
act as the parent of earlier children via the various functions in this 
package."

--

___
Python tracker 

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

[issue30931] Race condition in asyncore may access the wrong dispatcher

[STINNER Victor]

STINNER Victor added the comment:

I'm not sure that it's a good idea to compare asyncore and asyncio. While their 
name are similar, their design are *very* different. I'm only talking about the 
kernel, the core event loop checking for file descriptors.

In asyncio, when you close a transport, the transport is not *closed* 
immediately. It is scheduled to be closed as soon as possible: usually in the 
next loop iteration, but it can longer to complex transports like subprocesses 
or TLS connections.

Thanks to this design, asyncio doesn't have the race condition described in 
this issue.

--

___
Python tracker 

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

[issue31036] building the python docs requires the blurb module

[Matthias Klose]

Matthias Klose added the comment:

> so why didn't blurb get installed for doko?

it's not packaged, and I'm (and I think any other provider of distro packages) 
not using network access during the build.  Sorry to say, but the assumption 
that pip should be used to be able to build core python seems to be the wrong 
direction. Packaging blurb sure is an option, but what kind of value has this 
as a distro package? only used for building cpython, so why not include it in 
cpython itself?

I have two use cases:

 - building a distro package from a (pre)release tarball with a
   included NEWS file.  I can handle that by just not calling
   blurb.

 - building a distro package from a release tarball + a diff
   for a branch. I haven't looked yet how I could do that,
   including a current NEWS file.

For the included external C libraries we do have the option to either use the 
included version, or an external one.  Why not do the same for blurb?

--

___
Python tracker 

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

[issue30985] Set closing variable in asyncore at close

[STINNER Victor]

STINNER Victor added the comment:

"Giampaolo, people using only 3.7 should probably use asyncio. Fixing
asyncore is more important to those that can use only 2.7 (e.g.Centos/RHEL) or 
have to support both python 3 and 2."

IMHO starting to use closing in asyncore *is* a backward incompatible change. 
We don't know how applications use this existing attribute. Maybe it's not set 
to a boolean. Maybe it uses a different policy.

I would be ok to start using closing in Python 3.7, but I'm not confortable 
with backporting such change.

I would be if would be add a new private attribute, as the proposed "_closed" 
name.

Maybe nobody uses closing. Maybe people using closing have a similar usage. The 
thing is that we don't know, and according to what you wrote Nir, closing *is* 
used.

What I dislike in asyncore is that subclassing is not prohibed, it seems wanted 
by design. Ok, but what if a subclass overrides completely a method and doesn't 
set "closing/_closed" anymore? That's another reason why I dislike the idea of 
making any change in asyncore *especially* in Python 2.7 which is now 
considered as "very stable".

--

___
Python tracker 

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

[issue30985] Set closing variable in asyncore at close

[Guido van Rossum]

Changes by Guido van Rossum :


--
nosy:  -gvanrossum

___
Python tracker 

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

[issue27099] IDLE: turn builting extensions into regular modules

[Terry J. Reedy]

Terry J. Reedy added the comment:

There is a reason that I said, in msg266221, that I would experiment with 
moving 1 feature ;-). I knew from past experience that changing anything that 
affected user configuration would have to consider the effect on previous 
releases.  A total 'clean break' now would mean not a Py2 versus Py3 set of 
files but a Py3.6.2- versus a Py3.6.3+ set of files and I will not do this.

But it is OK with me that you plunged ahead to learn for yourself.  I expect to 
use most of what you have done.  I would like to get this into 3.6.3, whose 
release candidate is scheduled for late September.  But see below. That I one 
reason why I have focused for the last month on getting config and configdialog 
ready for changes.

When I said, in msg298982, that the extensions tab has 'a separate system for 
handling user changes', I meant for putting user changes into idleConf.  
IdleConf itself handles the 2 sets of 4 files (or the 4 pairs) uniformly.  I 
intend to remove that separate system *before* working on this.  The changes 
instance of the new config.OptionChanges is already initialized with an 
'extensions' dictionary that corresponds to the idleConf.userCfg['extensions'] 
instance of IdleUserConfigParser.

So, *do not change your patch to use the separate system*! I expect that we 
should just need to replace 'main' with 'extensions' in something like 
"changes.add_option('main', 'AutoComplete', 'popupwait', value)".

Changes that impact users should have a net user benefit, either directly or 
indirectly.  Moving menu entries, making the menu different in different 
releases, will bother some people, but I think a few changes will be justified.

Moving the tab where non-key options are displayed and changed also makes 
successive releases different.  The (potential) benefit is that it will be 
easier to select and check entries.  I just discovered that one can currently 
set editor width, for instance, to the string "nonsense"!. So the other tabs 
are also deficient. The benefit needs to be that entries, both existing and 
added, *are* checked.  Moving the file where non-key options are *stored* has 
no user benefit to counter the severe incompatibility problem.  Satisfying my 
aesthetic sensibilities is not good enough to justify the breakage.

Extension key-binding options are already displayed on the keys tab.  The issue 
is saving *all* key changes to the key file.  The user benefit is to make it 
easier to design a new custom keyset.  Some people do this by copying a section 
into config-keys.cfg or a separate file and editing it in an editor with enough 
lines to see everything.  This seems easier than laboriously scanning the box 
showing 10 bindings at a time and changing one at a time with the popup.  But 
the editor method misses the extension binding.  In any case, even after adding 
an error check from a 2009 submission, there are 9 remaining keys issues and as 
many potential issues on my list.  Improving the keys tab for all bindings is 
as important as moving the storage of some.

Changing existing non-buggy behavior is much more problemmatical than fixing 
buggy behavior or adding new behavior.  So we could defer the above changes to 
3.7.  But I don't like that either.  It deprives 3.6 users, which there will be 
for several years, of the benefits.  Diverging the files would make backing 
other improvements to 3.6 harder and less likely.

This issue is worse for the big change to tabbed windows.  Proposed solution: 
make tabbed windows a 'beta preview' option for the 3.6.x release after a 
minimal version is ready.  (There would be the option of leaving the option in 
3.7, though perhaps as opt-out.) 

The same could be done with the changes in this issue.  Make them opt-in in 
3.6.  Add 'Preview' before 'Help' with two items on the drop down: 
'Explanation', and 'Selected'.  Explanation would popup a text view window.  
Selected would set a variable.

I am working on removing from ConfigDialog a class for each tab.  When that is 
done, we put the opt-in changes for this issue in a subclass of each.  Then 
ConfigDialog

--
nosy: +louielu

___
Python tracker 

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

[issue30302] Improve .__repr__ implementation for datetime.timedelta

[STINNER Victor]

STINNER Victor added the comment:

Do you think that repr(datetime.timedelta) should be documented in the Porting 
section of What's New in Python 3.7?

https://docs.python.org/dev/whatsnew/3.7.html#porting-to-python-3-7

It was proposed in the middle of the python-dev thread. I have no opinion on 
that... or just a little -0 vote, if someone is impacted, it should be easy to 
notice it anymore, no?

--

While we don't have an obvious consensus, I took the responsability of merging 
Utkarsh Upadhyay's contribution. He wrote that he is interested to pursue the 
effort by also enhancing the docstring: please, go ahead, write a new PR, I 
will help you!

It was discussed to rewrite datetime.timedelta: only accept keywords in its 
constructor, store seconds=60 as minutes=1, etc. The problem is that it's too 
late to change the design. So I suggest to not waste time on discussing that, 
but focus the energy on making tiny changes to enhance the implemenatation 
without risking of breaking the world.

While developers using regulary timedelta knows what means the 3 numbers, it 
seems clear that the other developers have to check for the documentation. IMHO 
having to check the documentation is an issue: adding keywords to repr() 
reduces the need of documentation, and so makes Python more usable.

Sorry about the longer repr(): use str() or write your own formater?

By the way, if you need a formatter working on Python 2.7-3.7:

>>> def format_td(td): return 'timedelta(%s, %s, %s)' % (td.days, td.seconds, 
>>> td.microseconds)
... 
>>> format_td(datetime.timedelta(seconds=1))
'timedelta(0, 1, 0)'


If someone disagree with my merge, I suggest to reopen a thread on python-dev.

--

___
Python tracker 

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

[issue30985] Set closing variable in asyncore at close

[Nir Soffer]

Nir Soffer added the comment:

Giampaolo, people using only 3.7 should probably use asyncio. Fixing
asyncore is more important to those that can use only 2.7 (e.g.Centos/RHEL)
or have to support both python 3 and 2.

Do you think using _closed is safer for backport? This can also clash with
existing code.

--

___
Python tracker 

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

[issue30931] Race condition in asyncore may access the wrong dispatcher

[Nir Soffer]

Nir Soffer added the comment:

> I use the same trick all over the place in pyftpdlib:
> https://github.com/giampaolo/pyftpdlib/blob/1268bb185cd63c657d78bc33309041628e62360a/pyftpdlib/handlers.py#L537

This allow detection of closed sockets, but does not fix the issue of
accessing the wrong dispatcher.

> In practical terms, does this bug report aim to fix this issue?

Yes, see the attached PR's.

--

___
Python tracker 

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

[issue30302] Improve .__repr__ implementation for datetime.timedelta

[STINNER Victor]

STINNER Victor added the comment:


New changeset cc5a65cd9025280ea67ef4bbc2a8bfe31ced6c30 by Victor Stinner 
(Utkarsh Upadhyay) in branch 'master':
bpo-30302 Make timedelta.__repr__ more informative. (#1493)
https://github.com/python/cpython/commit/cc5a65cd9025280ea67ef4bbc2a8bfe31ced6c30


--

___
Python tracker 

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

[issue30302] Improve .__repr__ implementation for datetime.timedelta

[STINNER Victor]

STINNER Victor added the comment:

This issue has a long history starting in 2015 with a thread on python-dev. 
Many messages were written on python-dev and on this issue. I will try to 
summarize. (I hate doing that, summarizing is a risk of missing important 
information or misunderstand someone.)

The issue opens multiple questions:

* Should we change repr?
** YES, Guido: "I still think the repr change to use keywords has a good chance 
for 3.6." and "Still, I can't be the only one to ever have been fooled by this, 
and it is definitely pretty arcane knowledge what the positional arguments to 
timedelta()."
** YES, Martin Panter: "I disagree that the positional timedelta parameters are 
well-known."
** YES, Victor Stinner
** NO, Tim Peter: "But I wouldn't change repr() - the internal representation 
is fully documented, and it's appropriate for repr() to reflect documented 
internals as directly as possible."
** NO, Serhiy: "The drawback is that this change increases the length of the 
repr. Users of datetime.timedelta know what arguments mean. If they don't know 
they always can look in the documentation or builtin help."
** NO, Alexander Belopolsky: msg297521 

* Can changing repr break code?
** Guido: when we randomized hash, a lot of tests failed

* Add a "-" prefix for negative result: -timedelta(seconds=1)?
* (Related) Should repr(timedelta(seconds=60)) returns 'timedelta(minutes=1)'?
** NO, Guido: "I'm sure that one often catches people by surprise. However, I 
don't think we can fix that one without also fixing the values of the 
attributes -- in that example days is -1 and seconds is 86340 (which will 
*also* catch people by surprise). And changing that would be much, much harder 
for backwards compatibility reasons-- we'd have to set days to 0 and seconds to 
-60, and suddenly we have a much murkier invariant, instead of the crisp"
** NO, Guido: "Then please just trust me. If the repr() shows different numbers 
than the attributes things are worse than now. People will casually look at the 
repr() and assume they've seen what the attributes will return, and spend hours 
debugging code that relies on that incorrect assumption."
** NO, R. David Murray : "I'm with Haypo: the repr should show the *actual* 
value of the attributes."
** NO, Victor Stinner: "Don't make repr() implementation overcomplicated (...) 
use str()"

Another remark of Alexander Belopolsky:

* "Furthermore, "seconds=28747" is not that user-friendly. A friendlier 
representation would be "hours=7, minutes=59, seconds=7" and similar 
information is displayed when you print a timedelta: (...)"
** IHMO you should use str() and not repr() to format a value for humans. 
repr() is more designed for developers, to debug.

Another interesting remark: the documentation of the constructor is incomplete 
and should be document parameters.

--

___
Python tracker 

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

[issue30985] Set closing variable in asyncore at close

[Giampaolo Rodola']

Giampaolo Rodola' added the comment:

On the other hand, due to the poor asyncore API, I think it's safer if we land 
this in 3.7 only. "closing" attribute was never documented so if there's code 
out there setting it to True that'll crash their app pretty quickly as sockets 
won't close.

--

___
Python tracker 

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

[issue30304] TestCase.assertMultiLineEqual only registered for Unicode strings in 2.7

[Mariatta Wijaya]

Mariatta Wijaya added the comment:

Thanks!

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

[issue30985] Set closing variable in asyncore at close

[Giampaolo Rodola']

Giampaolo Rodola' added the comment:

I welcome this change as it avoids tricks like this one: 
https://github.com/giampaolo/pyftpdlib/blob/1268bb185cd63c657d78bc33309041628e62360a/pyftpdlib/handlers.py#L537
Any app using asyncore for anything other than an echo server eventually ends 
up doing the same.

--

___
Python tracker 

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

[issue30931] Race condition in asyncore may access the wrong dispatcher

[Giampaolo Rodola']

Giampaolo Rodola' added the comment:

> Yes, this is a typical issue in asyncore if you don't protect your
> subclass to handle double close.

I use the same trick all over the place in pyftpdlib:
https://github.com/giampaolo/pyftpdlib/blob/1268bb185cd63c657d78bc33309041628e62360a/pyftpdlib/handlers.py#L537
In practical terms, does this bug report aim to fix this issue?

--
nosy: +giampaolo.rodola

___
Python tracker 

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

[issue31036] building the python docs requires the blurb module

[Ned Deily]

Ned Deily added the comment:

Working on it.

--

___
Python tracker 

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

[issue31036] building the python docs requires the blurb module

[Larry Hastings]

Larry Hastings added the comment:

* I was told that blurb needed to be in the core-workflow repo, that this was 
better than checking it in to CPython itself.  Okay.  If you want to debate the 
point, loop in Brett Cannon, he's the one with the strong opinions.

* Ned has taken over the 3.3 branch, and he's asked that we not bother to 
blurbify it (convert it to use blurb).  My expectation is that we will blurbify 
all other active branches: 2.7 3.4 3.5 3.6 master.

* As part of the release process this weekend, I blurbified the 3.4 and 3.5 
branches.  There were already NEWS items stored in the Misc/NEWS.d/next 
directory, so I had to do *something*, and Brett has been encouraging me to 
move a little faster, so... I figured it was best to start there, as people 
don't care so much about 3.4 and 3.5 anymore, and they're "my" branches (as RM) 
so I wouldn't be inconveniencing anyone else.  I assume we'll get all the 
problems ironed out before the next 3.6 release.

* When a branch is converted over to blurb, you'll have to use blurb to build 
the docs from a git checkout of that branch.  

* When a branch is converted over to blurb, Misc/NEWS will no longer be a 
checked-in file.  It will only be generated, by the release manager when making 
a release, or for fun whenever somebody feels like generating it I guess.  It's 
important to remove it, because it's an output file, and if we leave it checked 
in people will modify it by hand, and then those changes will be lost the next 
time it's generated.  In the 3.4 and 3.5 branches Misc/NEWS has been deleted.

* As Ned points out, blurb isn't necessary for tarballs released by the RM.  My 
makefile-fu isn't up to the task, but essentially Doc/Makefile should run this 
logic (assuming cwd is Doc):

if os.path.exists("../Misc/NEWS"):
shutil.copy("../Misc/NEWS", "build/NEWS")
else:
os.system("blurb merge build/NEWS")

* I honestly don't understand the disposition of the venv in Doc/Makefile.  Is 
it used automatically?  Isn't it?  It seems to be used under 3.5--when I do a 
docs build it installs a bunch of packages--so why didn't blurb get installed 
for doko?  What about 3.4, which predates the venv in Doc/Makefile?  TBH I'm a 
big dummy when it comes to venv stuff.  I'm hoping someone smart like Ned will 
figure it all out and make it sane, regular, and predictable.  (Hint hint!)

* Building the docs already requires a dozen packages (Sphinx, which in turn 
depends on markupsafe et al).  I assumed requiring one more package, also 
installed from pip, was not the worst thing in the world.  Is it?

--

___
Python tracker 

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

[issue30119] (ftplib) A remote attacker could possibly attack by containing the newline characters

[Giampaolo Rodola']

Giampaolo Rodola' added the comment:

Reopening as it needs backports for 2.7, 3.3, 3.4, 3.5 and 3.6.

--
resolution: duplicate -> 
stage: resolved -> backport needed
status: closed -> pending
versions: +Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

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

[issue30190] unittest's assertAlmostEqual improved error message

[Giampaolo Rodola']

Giampaolo Rodola' added the comment:

Sorry, I accidentally picked up the wrong thread.

--
resolution:  -> fixed
stage: backport needed -> resolved
status: pending -> closed
versions:  -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

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

[issue30721] Show expected input for right shift operator usage in custom "print" error message

[Steve Dower]

Steve Dower added the comment:

The "op_slot == 96" looks suspicious - how is this value actually supposed to 
be calculated?

--

___
Python tracker 

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