From report at bugs.python.org  Fri Dec  1 00:22:05 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 01 Dec 2017 05:22:05 +0000
Subject: [New-bugs-announce] [issue32190] Separate out legacy introspection
 APIs in the inspect docs
Message-ID: <1512105725.63.0.213398074469.issue32190@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

(Follow up to https://bugs.python.org/issue27172)

The deprecation notice on inspect.getfullargspec has been removed, since we want folks porting from Python 2 to rely on it as part of the porting process, rather than feeling they need to upgrade to using inspect.signature() immediately.

At the same time, we really don't want folks relying on it for *new* code, since it has some inherent limitations (like failing to distinguish positional-only args from positional-and-keyword ones), and some odd historical quirks (like reporting the bound arg as part of the signature for already bound methods).

The subprocess modules clearly separates out the "Older high-level API" https://docs.python.org/3/library/subprocess.html#older-high-level-api to help make it clear that new code should use "subprocess.run" instead.

We could potentially add a similar final section to the inspect documentation for "Legacy introspection APIs".

That would also be useful if https://bugs.python.org/issue31230 is eventually implemented - the current generator and coroutine specific APIs could be moved down to the legacy section for backwards compatibility maintenance, with the type independent API being preferred for new code.

----------
assignee: docs at python
components: Documentation
messages: 307362
nosy: brett.cannon, docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Separate out legacy introspection APIs in the inspect docs
type: enhancement
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32190>
_______________________________________

From report at bugs.python.org  Fri Dec  1 02:18:25 2017
From: report at bugs.python.org (Kyeongpil)
Date: Fri, 01 Dec 2017 07:18:25 +0000
Subject: [New-bugs-announce] [issue32191] TypeError does not work when
 function with type hint
Message-ID: <1512112705.37.0.213398074469.issue32191@psf.upfronthosting.co.za>


New submission from Kyeongpil <rudvlf0413 at korea.ac.kr>:

TypeError does not work when I input float variable into function that I give type hint.

example code is like this:
def a(b: int) -> int:
    return b+1

a(1.1)

and the result is 1.1.
However, I think it should throw TypeError Exception because type of input is float, not int.

----------
components: ctypes
messages: 307367
nosy: Kang
priority: normal
severity: normal
status: open
title: TypeError does not work when function with type hint
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32191>
_______________________________________

From report at bugs.python.org  Fri Dec  1 03:50:41 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 01 Dec 2017 08:50:41 +0000
Subject: [New-bugs-announce] [issue32192] Provide importlib.util.lazy_import
 helper function
Message-ID: <1512118241.83.0.213398074469.issue32192@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

While importlib provides all the *pieces* to implement lazy imports, we don't actually provide a clear way of chaining them together into a lazy import operation. Without any error checking, that looks like:

    import sys
    import importlib.util
    def lazy_import(name):
        spec = importlib.util.find_spec(name)
        loader = importlib.util.LazyLoader(spec.loader)
        spec.loader = loader
        module = importlib.util.module_from_spec(spec)
        sys.modules[name] = module
        loader.exec_module(module)
        return module

    >>> lazy_typing = lazy_import("typing")
    >>> lazy_typing.TYPE_CHECKING
    False

I'm thinking it may make sense to just provide a robust implementation of that, and accept that it may lead to some bug reports that are closed with "You need to fix the module you're loading to be compatible with lazy imports"

----------
messages: 307370
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Provide importlib.util.lazy_import helper function

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32192>
_______________________________________

From report at bugs.python.org  Fri Dec  1 04:44:32 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 01 Dec 2017 09:44:32 +0000
Subject: [New-bugs-announce] [issue32193] Convert asyncio to async/await
Message-ID: <1512121472.71.0.213398074469.issue32193@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

As discussed several times before we need to convert `@coroutine` / `yield from` to async/await.

All existing functionality should keep working (like yielding from new style coroutine and `with (yield from lock)`.

We could deprecate the later though.

The change should be huge but there is no alternative, keeping `yield from` in stdlib looks uglier and uglier every year.

Unittests should be changed as well (keeping several `yield from` for checking backward compatibility is Ok).


Opinions?

----------
assignee: asvetlov
components: Library (Lib), asyncio
messages: 307375
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Convert asyncio to async/await
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32193>
_______________________________________

From report at bugs.python.org  Fri Dec  1 06:05:58 2017
From: report at bugs.python.org (=?utf-8?q?Joona_M=C3=B6rsky?=)
Date: Fri, 01 Dec 2017 11:05:58 +0000
Subject: [New-bugs-announce] [issue32194] When creating list of dictionaries
 and updating datetime objects one by one,
 all values are set to last one of the list.
Message-ID: <1512126358.41.0.213398074469.issue32194@psf.upfronthosting.co.za>


New submission from Joona M?rsky <joonamorskyer at gmail.com>:

When creating list of dictionaries and updating datetime objects one by one, all values are set to last one of the list.

Ubuntu Linux 4.10.0-40-generic #44~16.04.1-Ubuntu SMP Thu Nov 9 15:37:44 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Python 3.5.2



>>>import datetime

>>>b = datetime.datetime.utcnow()
>>>b = b.replace(hour=0,minute=0,second=0,microsecond=0,tzinfo=datetime.timezone.utc)

>>>a = [{}] * 3

>>>for inx in range(3):

...    a[inx]['time'] = b + datetime.timedelta(minutes=inx*10)


[{'time': datetime.datetime(2017, 12, 1, 0, 20, tzinfo=datetime.timezone.utc)}, {'time': datetime.datetime(2017, 12, 1, 0, 20, tzinfo=datetime.timezone.utc)}, {'time': datetime.datetime(2017, 12, 1, 0, 20, tzinfo=datetime.timezone.utc)}]

>>>import datetime

>>>b = datetime.datetime.utcnow()
>>>b = b.replace(hour=0,minute=0,second=0,microsecond=0,tzinfo=datetime.timezone.utc)

>>>a = [ ]

>>>for inx in range(3):

...    a.append({"time": b + datetime.timedelta(minutes=inx*10)})

[{'time': datetime.datetime(2017, 12, 1, 0, 0, tzinfo=datetime.timezone.utc)}, {'time': datetime.datetime(2017, 12, 1, 0, 10, tzinfo=datetime.timezone.utc)}, {'time': datetime.datetime(2017, 12, 1, 0, 20, tzinfo=datetime.timezone.utc)}]

----------
components: Interpreter Core
messages: 307382
nosy: Joona M?rsky
priority: normal
severity: normal
status: open
title: When creating list of dictionaries and updating datetime objects one by one, all values are set to last one of the list.
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32194>
_______________________________________

From report at bugs.python.org  Fri Dec  1 09:39:29 2017
From: report at bugs.python.org (Dave Challis)
Date: Fri, 01 Dec 2017 14:39:29 +0000
Subject: [New-bugs-announce] [issue32195] datetime.strftime with %Y no
 longer outputs leading zeros
Message-ID: <1512139169.39.0.213398074469.issue32195@psf.upfronthosting.co.za>


New submission from Dave Challis <suicas at gmail.com>:

Tested in python 3.6.2:

    >>> import datetime
    >>> datetime.datetime.min.strftime('%Y')
    '1'

Expected output:

    '0001'

This means that strftime and strptime aren't necessarily symmetric, e.g.:

    >>> datetime.datetime.strptime(datetime.datetime.min.strftime('%Y'), '%Y')
    ValueError: time data '1' does not match format '%Y'

----------
components: Library (Lib)
messages: 307389
nosy: davechallis
priority: normal
severity: normal
status: open
title: datetime.strftime with %Y no longer outputs leading zeros
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32195>
_______________________________________

From report at bugs.python.org  Fri Dec  1 14:28:36 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 01 Dec 2017 19:28:36 +0000
Subject: [New-bugs-announce] [issue32196] Rewrite plistlib with functional
 style
Message-ID: <1512156516.89.0.213398074469.issue32196@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The proposed PR rewrites the plistlib module using a functional style. This speeds up loading and saving plist files at least by 10%. Saving plist files in XML format have sped up almost twice.


$ ./python -m timeit -s 'import plistlib; a = list(range(100))' -- 'plistlib.dumps(a, fmt=plistlib.FMT_XML)'
Unpatched:  1000 loops, best of 5: 228 usec per loop
Patched:    1000 loops, best of 5: 204 usec per loop

$ ./python -m timeit -s 'import plistlib; a = list(range(100))' -- 'plistlib.dumps(a, fmt=plistlib.FMT_BINARY)'
Unpatched:  1000 loops, best of 5: 234 usec per loop
Patched:    1000 loops, best of 5: 203 usec per loop

$ ./python -m timeit -s 'import plistlib; a = list(range(100)); p = plistlib.dumps(a, fmt=plistlib.FMT_XML)' -- 'plistlib.loads(p)'
Unpatched:  1000 loops, best of 5: 308 usec per loop
Patched:    2000 loops, best of 5: 155 usec per loop

$ ./python -m timeit -s 'import plistlib; a = list(range(100)); p = plistlib.dumps(a, fmt=plistlib.FMT_BINARY)' -- 'plistlib.loads(p)'
Unpatched:  2000 loops, best of 5: 116 usec per loop
Patched:    5000 loops, best of 5: 94.6 usec per loop


$ ./python -m timeit -s 'import plistlib; a = {"a%d" % i: i for i in range(100)}' -- 'plistlib.dumps(a, fmt=plistlib.FMT_XML)'
Unpatched:  500 loops, best of 5: 433 usec per loop
Patched:    1000 loops, best of 5: 384 usec per loop

$ ./python -m timeit -s 'import plistlib; a = {"a%d" % i: i for i in range(100)}' -- 'plistlib.dumps(a, fmt=plistlib.FMT_BINARY)'
Unpatched:  500 loops, best of 5: 616 usec per loop
Patched:    500 loops, best of 5: 560 usec per loop

$ ./python -m timeit -s 'import plistlib; a = {"a%d" % i: i for i in range(100)}; p = plistlib.dumps(a, fmt=plistlib.FMT_XML)' -- 'plistlib.loads(p)'
Unpatched:  500 loops, best of 5: 578 usec per loop
Patched:    1000 loops, best of 5: 308 usec per loop

$ ./python -m timeit -s 'import plistlib; a = {"a%d" % i: i for i in range(100)}; p = plistlib.dumps(a, fmt=plistlib.FMT_BINARY)' -- 'plistlib.loads(p)'
Unpatched:  1000 loops, best of 5: 257 usec per loop
Patched:    1000 loops, best of 5: 208 usec per loop

----------
components: Library (Lib)
messages: 307404
nosy: ronaldoussoren, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Rewrite plistlib with functional style
type: performance
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32196>
_______________________________________

From report at bugs.python.org  Sat Dec  2 07:50:00 2017
From: report at bugs.python.org (Sanyam Khurana)
Date: Sat, 02 Dec 2017 12:50:00 +0000
Subject: [New-bugs-announce] [issue32197] Compiling against master branch
 fails; error: expected expression SET_DECODE_ERROR
Message-ID: <1512219000.84.0.213398074469.issue32197@psf.upfronthosting.co.za>


New submission from Sanyam Khurana <sanyam.khurana01 at gmail.com>:

The current master branch at commit af5a895073c24637c094772b27526b94a12ec897

fails while building the interpreter.

The following is the traceback while running `make` after `./configure --with-pydebug`

gcc -c -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes    -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration   -I. -I./Include    -DPy_BUILD_CORE -o Modules/main.o Modules/main.c
Modules/main.c:904:20: error: expected expression
            return SET_DECODE_ERROR("PYTHONEXECUTABLE environment "
                   ^
Modules/main.c:46:5: note: expanded from macro 'SET_DECODE_ERROR'
    do { \
    ^
1 error generated.
make: *** [Modules/main.o] Error 1

----------
messages: 307427
nosy: CuriousLearner
priority: normal
severity: normal
status: open
title: Compiling against master branch fails; error: expected expression SET_DECODE_ERROR
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32197>
_______________________________________

From report at bugs.python.org  Sat Dec  2 08:28:09 2017
From: report at bugs.python.org (Shriramana Sharma)
Date: Sat, 02 Dec 2017 13:28:09 +0000
Subject: [New-bugs-announce] [issue32198] \b reports false-positives in
 Indic strings involving combining marks
Message-ID: <1512221289.58.0.213398074469.issue32198@psf.upfronthosting.co.za>


New submission from Shriramana Sharma <samjnaa at gmail.com>:

Code:

import re
cons_taml = "[??????????????????]"
print(re.findall("\\b" + cons_taml + "?|?", "???? ????? ??? ?????? ????? ????"))
cons_deva = "[?????????????????????????????????]"
print(re.findall("\\b" + cons_deva + "?|?", "???? ????? ??? ????? ????? ????"))

Specs:
Kubuntu Xenial 64 bit
Python 3.5.2 (default, Nov 23 2017, 16:37:01) 
[GCC 5.4.0 20160609] on linux

Actual Output:
['?', '??', '??', '??', '?']
['?', '??', '??', '??', '?']

Expected Output:
['?', '??']
['?', '??']

Rationale:

The formulated RE desires to identify words *starting* with the vowel /ai/ (\u0BC8 ? in Tamil script and \u0948 ? in Devanagari as vowel sign or \u0B90 ? \u0910 ? as independent vowel). ???? ????? and ???? ????? are the only words fitting this criterion. \b is defined to mark a word boundary and is here applied at the beginning of the RE.

Observation:

There seems to be some assumption that only GC=Lo characters constitute words. Hence the false positives at ? ? ? ? (? ?) and ? ? ? (? ?) where the ? and ? are vowel signs, and ? ? ? (? ?) and ? ? ? (? ?) where the ? and ? are virama characters or vowel cancelling signs.

In Indic, such GC=Mc and GC=Mn characters are inalienable parts of words. They should be properly identified as parts of words and no word boundary answering to \b should be generated at their positions.

----------
components: Regular Expressions
messages: 307430
nosy: ezio.melotti, jamadagni, mrabarnett
priority: normal
severity: normal
status: open
title: \b reports false-positives in Indic strings involving combining marks
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32198>
_______________________________________

From report at bugs.python.org  Sat Dec  2 09:29:39 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 02 Dec 2017 14:29:39 +0000
Subject: [New-bugs-announce] [issue32199] uuid.getnode() should return the
 MAC address on Android
Message-ID: <1512224979.48.0.213398074469.issue32199@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

Currently uuid.getnode() returns a random 48-bit number and so the UUIDs are not persistent across time. The reason is that on Android the 'ip link list' command fails.

uuid._ip_getnode() should invoke the 'ip link' command instead.

----------
components: Library (Lib)
messages: 307432
nosy: xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: uuid.getnode() should return the MAC address on Android
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32199>
_______________________________________

From report at bugs.python.org  Sat Dec  2 10:25:56 2017
From: report at bugs.python.org (Carol Willing)
Date: Sat, 02 Dec 2017 15:25:56 +0000
Subject: [New-bugs-announce] [issue32200] Download of 3.7.0a2 docs giving a
 404 error
Message-ID: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za>


New submission from Carol Willing <willingc at gmail.com>:

Currently, the 3.7.0a2 doc links are giving 404 errors. 3.6 docs are working just fine.

https://docs.python.org/3.7/archives/python-3.7.0a2-docs-pdf-letter.tar.bz2 results in a 404.

I wasn't sure if I should report here or in python.org issue tracker.

----------
assignee: docs at python
components: Documentation
messages: 307433
nosy: docs at python, willingc
priority: normal
severity: normal
status: open
title: Download of 3.7.0a2 docs giving a 404 error
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32200>
_______________________________________

From report at bugs.python.org  Sat Dec  2 10:44:11 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 02 Dec 2017 15:44:11 +0000
Subject: [New-bugs-announce] [issue32201] Python uuids may not be persistent
 across time
Message-ID: <1512229451.68.0.213398074469.issue32201@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

UUIDs are unique and persistent across time and space.

UUIDs generated using the getnode() function of the uuid module on a plaform where getnode() cannot use the MAC address are based on a random number created for that purpose and are therefore transient and only valid during the life time of the python process. This seems to be a bug.

My understanding of RFC 4122 is that in that case, the random number is generated only once, otherwise the usefulness of this method is not obvious. In any case the user should be made aware of the transientness of the result of getnode() since persistency is a key feature of UUIDs.

----------
components: Library (Lib)
messages: 307435
nosy: barry, ned.deily, serhiy.storchaka, vstinner, xdegaye
priority: normal
severity: normal
status: open
title: Python uuids may not be persistent across time
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32201>
_______________________________________

From report at bugs.python.org  Sat Dec  2 12:09:53 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 02 Dec 2017 17:09:53 +0000
Subject: [New-bugs-announce] [issue32202] [ctypes] all long double tests
 fail on android-24-x86_64
Message-ID: <1512234593.69.0.213398074469.issue32202@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

These tests are ok on Android API 24 on the armv7, x86 and arm64 architectures.

======================================================================
FAIL: test_longdouble (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.python/lib/python3.7/ctypes/test/test_callbacks.py", line 83, in test_longdouble
    self.check_type(c_longdouble, 3.14)
  File "/sdcard/org.python/lib/python3.7/ctypes/test/test_callbacks.py", line 25, in check_type
    self.assertEqual(result, arg)
AssertionError: 0.0 != 3.14

======================================================================
FAIL: test_longdouble (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.python/lib/python3.7/ctypes/test/test_cfuncs.py", line 165, in test_longdouble
    self.assertEqual(self._dll.tf_D(42.), 14.)
AssertionError: 0.0 != 14.0

======================================================================
FAIL: test_longdouble_plus (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.python/lib/python3.7/ctypes/test/test_cfuncs.py", line 171, in test_longdouble_p
lus
    self.assertEqual(self._dll.tf_bD(0, 42.), 14.)
AssertionError: 0.0 != 14.0

======================================================================
FAIL: test_longdoubleresult (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.python/lib/python3.7/ctypes/test/test_functions.py", line 146, in test_longdoubl
eresult
    self.assertEqual(result, 21)
AssertionError: 0.0 != 21

----------------------------------------------------------------------
Ran 468 tests in 1.815s

FAILED (failures=4, skipped=92)
test test_ctypes failed
test_ctypes failed

1 test failed:
    test_ctypes

----------
components: Extension Modules, Tests
messages: 307439
nosy: xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: [ctypes] all long double tests fail on android-24-x86_64
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32202>
_______________________________________

From report at bugs.python.org  Sat Dec  2 12:26:14 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 02 Dec 2017 17:26:14 +0000
Subject: [New-bugs-announce] [issue32203] [ctypes] test_struct_by_value
 fails on android-24-arm64
Message-ID: <1512235574.32.0.213398074469.issue32203@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

test_struct_by_value is ok on Android API 24 on the armv7, x86 and x86_64 architectures.

======================================================================
FAIL: test_struct_by_value (ctypes.test.test_win32.Structures)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.python/lib/python3.7/ctypes/test/test_win32.py", line 137, in test_struct_by_value
    self.assertEqual(ret.left, left.value)
AssertionError: -200 != 10

----------------------------------------------------------------------
Ran 1 test in 0.204s

----------
components: Extension Modules, Tests
messages: 307440
nosy: xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: [ctypes] test_struct_by_value fails on android-24-arm64
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32203>
_______________________________________

From report at bugs.python.org  Sun Dec  3 04:09:09 2017
From: report at bugs.python.org (Liran Nuna)
Date: Sun, 03 Dec 2017 09:09:09 +0000
Subject: [New-bugs-announce] [issue32204] async/await performance is very low
Message-ID: <1512292149.52.0.213398074469.issue32204@psf.upfronthosting.co.za>


New submission from Liran Nuna <liranuna at gmail.com>:

The performance of async/await is very low when compared to similar code that implements similar functionality via iterators, such as Quora's asynq library (https://github.com/quora/asynq/tree/master/asynq).

Based on my benchmarks, asynq is almost twice as fast as async/await. 

I have found some performance hanging fruit when benchmarking (See attached GitHub PR).


$ time python batch_asyncio.py 

real	0m5.851s
user	0m5.760s
sys	0m0.088s
$ time python batch_asynq.py 

real	0m2.999s
user	0m2.900s
sys	0m0.076s

----------
components: asyncio
files: batch_asyncio.py
messages: 307492
nosy: Liran Nuna, yselivanov
priority: normal
pull_requests: 4599
severity: normal
status: open
title: async/await performance is very low
type: performance
versions: Python 3.6
Added file: https://bugs.python.org/file47313/batch_asyncio.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32204>
_______________________________________

From report at bugs.python.org  Sun Dec  3 08:28:10 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 03 Dec 2017 13:28:10 +0000
Subject: [New-bugs-announce] [issue32205] test.pythoninfo does not print the
 cross-built sysconfig data
Message-ID: <1512307690.33.0.213398074469.issue32205@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

When cross-compiling the only useful information printed by pythoninfo is the cross-built sysconfig data since everything else is related to the native python process used during the cross-build.

Currently pythoninfo prints the native sysconfig data instead.

----------
components: Cross-Build
messages: 307510
nosy: Alex.Willmer, vstinner, xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: test.pythoninfo does not print the cross-built sysconfig data
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32205>
_______________________________________

From report at bugs.python.org  Sun Dec  3 08:36:40 2017
From: report at bugs.python.org (Mario Corchero)
Date: Sun, 03 Dec 2017 13:36:40 +0000
Subject: [New-bugs-announce] [issue32206] Run modules with pdb
Message-ID: <1512308200.99.0.213398074469.issue32206@psf.upfronthosting.co.za>


New submission from Mario Corchero <mariocj89 at gmail.com>:

Since PEP 338 we can run python modules as a script via `python -m module_name` but there is no way to run pdb on those (AFAIK).

The proposal is to add a new argument "-m" to the pdb module to allow users to run `python -m pdb -m my_module_name`

This is especially useful when working on cli tools that use entrypoints in setup.py, as there is no other way to run them.


I have a WIP here: https://github.com/mariocj89/cpython/commit/f47d1b779333657d7d87b21db841d5d3ad6cfa5c

Haven't sent the PR as I am still polishing some issues. If it sounds like a good idea I'll clean it up and open the PR.

----------
components: Library (Lib)
messages: 307513
nosy: mariocj89
priority: normal
severity: normal
status: open
title: Run modules with pdb
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32206>
_______________________________________

From report at bugs.python.org  Sun Dec  3 20:47:09 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 04 Dec 2017 01:47:09 +0000
Subject: [New-bugs-announce] [issue32207] IDLE: run's tk update adds extra
 traceback on callback error
Message-ID: <1512352029.95.0.213398074469.issue32207@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

import tkinter as tk
root = tk.Tk()

def bad(): print(a, 'bad')
def good(): print('good')

root.after(1000, bad)
root.after(1500, good)
root.mainloop()


# Correctly gives this traceback and output:

Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Programs\Python37\lib\tkinter\__init__.py", line 1699, in __call__
    return self.func(*args)
  File "C:\Programs\Python37\lib\tkinter\__init__.py", line 745, in callit
    func(*args)
  File "F:\Python\a\tem2.py", line 13, in bad
    def bad(): print(a, 'bad')
NameError: name 'a' is not defined
good
>>> 
====================================

Remove or comment-out the blocking 'root.mainloop()' call and run the result from an IDLE editor.  The callbacks are still called because after user code is run, run.py calls tcl.update in a loop nominally 20 x per second.  This allows developers to interact with a 'live' gui by entering statements in the shell at '>>>' prompts.  The result is this.
-------------
>>> Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Programs\Python37\lib\idlelib\run.py", line 137, in main
    seq, request = rpc.request_queue.get(block=True, timeout=0.05)
  File "C:\Programs\Python37\lib\queue.py", line 169, in get
    raise Empty
queue.Empty

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
<The NameError traceback and message, as before.>
--------------

The relevant code in run.py was written before callback chaining.

            try:
                seq, request = rpc.request_queue.get(block=True, timeout=0.05)
            except queue.Empty:
                handle_tk_events()
                continue

Experiments with normal exceptions in a shell suggest that wrapping handle_tk_events in try:except and re-raising any exception 'from None' should work.
                try:
                    handle_tk_events()
                except BaseException as e:
                    raise e from None

However, it appears that callback errors resulting from handle_tk_events() are not being caught here.  (print('message') and 1/0 before 'raise' have no visible effect.)  I will investigate more later.

----------
assignee: terry.reedy
components: IDLE
messages: 307534
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: run's tk update adds extra traceback on callback error
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32207>
_______________________________________

From report at bugs.python.org  Sun Dec  3 22:18:00 2017
From: report at bugs.python.org (Garrett Berg)
Date: Mon, 04 Dec 2017 03:18:00 +0000
Subject: [New-bugs-announce] [issue32208] Improve semaphore docmentation
Message-ID: <1512357480.91.0.213398074469.issue32208@psf.upfronthosting.co.za>


New submission from Garrett Berg <googberg at gmail.com>:

The definition of threading.Semaphore is confusing (for all versions of python docs)

https://docs.python.org/2/library/threading.html#semaphore-objects

 acquire([blocking])

It currently states the following:

> When invoked without arguments: if the internal counter is larger than zero on entry, decrement it by one and return immediately. If it is zero on entry, block, waiting until some other thread has called release() to make it larger than zero. This is done with proper interlocking so that if multiple acquire() calls are blocked, release() will wake exactly one of them up. The implementation may pick one at random, so the order in which blocked threads are awakened should not be relied on. There is no return value in this case.

However, after testing it myself I found that is missing a crutial detail. Let's step through the docs:

> If the internal counter is larger than zero on entry, decrement it by one and return immediately.

This is exactly accurate and should stay the same

> If it is zero on entry, block, waiting until some other thread has called release() to make it larger than zero. This is done with proper interlocking so that if multiple acquire() calls are blocked, release() will wake exactly one of them up. The implementation may pick one at random, so the order in which blocked threads are awakened should not be relied on. There is no return value in this case.

This is extremely confusing and I would like to rewrite it as follows:

> If it is zero on entry block until awoken by a call to ``release()``. Once awoken, decrement the counter by 1. Exactly one thread will be awoken by a call to ``release()``. The order in which threads are awoken should not be relied on. ``None`` is returned in this case.

The major thing that was missing was that the **counter is decremented after the thread is awoken**. For instance, this code *generally* passes assertions:

```
#!/usr/bin/python2
import time
from threading import Thread, Semaphore

s = Semaphore(1)

def doit():
    s.acquire()
    print("did it")

th1 = Thread(target=doit)
th1.start()

th2 = Thread(target=doit)
th2.start()

time.sleep(0.2)

assert not th1.is_alive()
assert th2.is_alive()

s.release()
assert s._value == 1, "The value is increased to 1 MOMENTARILY"
start = time.time()
while sum([th2.is_alive(), th3.is_alive()]) > 1:
    assert time.time() - start < 0.5
    time.sleep(0.1)

assert s._value == 0, "when an aquire is awoken, THEN _value is decremented"
```

Obviously this behavior should not be relied on, but it gives a picture of what seems to be happening under the hood.

I came across this while trying to work through "The Little Book of Semaphores". After reading these docs I mistakingly thought that they didn't match Djestra's original semaphore since the values could not be negative. I now realize that while they may not match that implementation under the hood, they match it perfectly in practice since if you (for instance) ``acquire()`` 5 times and then ``release()`` 5 times the value of Semaphore._value will be the same when all is said and done.

----------
components: Library (Lib)
messages: 307536
nosy: Garrett Berg
priority: normal
severity: normal
status: open
title: Improve semaphore docmentation
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32208>
_______________________________________

From report at bugs.python.org  Sun Dec  3 22:37:11 2017
From: report at bugs.python.org (Connor W Fitzgerald)
Date: Mon, 04 Dec 2017 03:37:11 +0000
Subject: [New-bugs-announce] [issue32209] Crash in set_traverse Within the
 Garbage Collector's collect_generations()
Message-ID: <1512358631.67.0.213398074469.issue32209@psf.upfronthosting.co.za>


New submission from Connor W Fitzgerald <connorwadefitzgerald at gmail.com>:

This is my first time submitting a bug report, so forgive me if I miss on important information. I am writing code that makes heavy use of sets (8GB+ of them). It segfaults semi-randomly during the processing of them. I've used versions 3.5.3, 3.6.3, and 3.7.0rc2. I debugged the process and came across the error in object/setobject.c:742. I don't really know what information to provide here but this is the best I can do.

Error:
Unhandled exception thrown: read access violation.
entry->**key** was 0x8000.

Stack Trace:
python37.dll!set_traverse(PySetObject * so, int(*)(_object *, void *) visit, void * arg) Line 742
python37.dll!subtract_refs(_gc_head * containers) Line 295
python37.dll!collect(int generation, __int64 * n_collected, __int64 * n_uncollectable, int nofail) Line 862
python37.dll!collect_with_callback(int generation) Line 1027
python37.dll!collect_generations() Line 1049
python37.dll!PyType_GenericAlloc(_typeobject * type, __int64 nitems) Line 969
[Inline Frame] python37.dll!make_new_set(_typeobject *) Line 1055
python37.dll!set_new(_typeobject * type, _object * args, _object * kwds) Line 1127
python37.dll!type_call(_typeobject * type, _object * args, _object * kwds) Line 928
python37.dll!_PyObject_FastCallKeywords(_object * callable, _object * * stack, __int64 nargs, _object * kwnames) Line 199
python37.dll!call_function(_object * * * pp_stack, __int64 oparg, _object * kwnames) Line 4705
python37.dll!_PyEval_EvalFrameDefault(_frame * f, int throwflag) Line 3182
[Inline Frame] python37.dll!PyEval_EvalFrameEx(_frame *) Line 549
python37.dll!_PyEval_EvalCodeWithName(_object * _co, _object * globals, _object * locals, _object * * args, __int64 argcount, _object * * kwnames, _object * * kwargs, __int64 kwcount, int kwstep, _object * * defs, __int64 defcount, _object * kwdefs, _object * closure, _object * name, _object * qualname) Line 4011
python37.dll!_PyFunction_FastCallDict(_object * func, _object * * args, __int64 nargs, _object * kwargs) Line 376
[Inline Frame] python37.dll!PyEval_CallObjectWithKeywords(_object *) Line 819
python37.dll!defdict_missing(defdictobject * dd, _object * key) Line 1993
python37.dll!_PyMethodDef_RawFastCallDict(PyMethodDef * method, _object * self, _object * * args, __int64 nargs, _object * kwargs) Line 496
[Inline Frame] python37.dll!_PyCFunction_FastCallDict(_object *) Line 580
python37.dll!_PyObject_FastCallDict(_object * callable, _object * * args, __int64 nargs, _object * kwargs) Line 101
[Inline Frame] python37.dll!object_vacall(_object * callable, char *) Line 1194
python37.dll!PyObject_CallFunctionObjArgs(_object * callable, ...) Line 1259
python37.dll!dict_subscript(PyDictObject * mp, _object * key) Line 1984
python37.dll!_PyEval_EvalFrameDefault(_frame * f, int throwflag) Line 1316
[Inline Frame] python37.dll!PyEval_EvalFrameEx(_frame *) Line 549
python37.dll!_PyEval_EvalCodeWithName(_object * _co, _object * globals, _object * locals, _object * * args, __int64 argcount, _object * * kwnames, _object * * kwargs, __int64 kwcount, int kwstep, _object * * defs, __int64 defcount, _object * kwdefs, _object * closure, _object * name, _object * qualname) Line 4011
[Inline Frame] python37.dll!_PyFunction_FastCallKeywords(_object * stack, _object * *) Line 433
python37.dll!call_function(_object * * * pp_stack, __int64 oparg, _object * kwnames) Line 4703
python37.dll!_PyEval_EvalFrameDefault(_frame * f, int throwflag) Line 3182
[Inline Frame] python37.dll!PyEval_EvalFrameEx(_frame *) Line 549
python37.dll!_PyEval_EvalCodeWithName(_object * _co, _object * globals, _object * locals, _object * * args, __int64 argcount, _object * * kwnames, _object * * kwargs, __int64 kwcount, int kwstep, _object * * defs, __int64 defcount, _object * kwdefs, _object * closure, _object * name, _object * qualname) Line 4011
python37.dll!PyEval_EvalCodeEx(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure) Line 4045
python37.dll!PyEval_EvalCode(_object * co, _object * globals, _object * locals) Line 532
python37.dll!run_mod(_mod * mod, _object * filename, _object * globals, _object * locals, PyCompilerFlags * flags, _arena * arena) Line 987
python37.dll!PyRun_FileExFlags(_iobuf * fp, const char * filename_str, int start, _object * globals, _object * locals, int closeit, PyCompilerFlags * flags) Line 939
python37.dll!PyRun_SimpleFileExFlags(_iobuf * fp, const char * filename, int closeit, PyCompilerFlags * flags) Line 402
python37.dll!PyRun_AnyFileExFlags(_iobuf * fp, const char * filename, int closeit, PyCompilerFlags * flags) Line 84
python37.dll!run_file(_iobuf * fp, const wchar_t * filename, PyCompilerFlags * p_cf) Line 340
python37.dll!Py_Main(int argc, wchar_t * * argv) Line 894
[Inline Frame] python.exe!invoke_main() Line 79
python.exe!__scrt_common_main_seh() Line 253
kernel32.dll!0000000077a959cd()
ntdll.dll!0000000077bca561()

I'm not sure what I can do to reproduce this because I don't even know what line of code my program was running before it segfaulted. I'm using sqlite3, json, and pickle as my main extensions. Nothing outside of what is provided in the standard library is used. If you need any more information, I'll gladly provide it.

----------
components: Interpreter Core
messages: 307539
nosy: connorwfitzgerald
priority: normal
severity: normal
status: open
title: Crash in set_traverse Within the Garbage Collector's collect_generations()
type: crash
versions: Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32209>
_______________________________________

From report at bugs.python.org  Mon Dec  4 04:39:35 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 04 Dec 2017 09:39:35 +0000
Subject: [New-bugs-announce] [issue32210] Add the versions of the Android
 SDK and NDK to test.pythoninfo
Message-ID: <1512380375.09.0.213398074469.issue32210@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

* The NDK version can be obtained by parsing the file $ANDROID_NDK_ROOT/source.properties.
* The versions of the SDK build-tools, emulator and platform-tools packages as well as those of the system images can be obtained by parsing the output of "$ANDROID_SDK_ROOT/tools/bin/sdkmanager --list".

----------
components: Cross-Build
messages: 307544
nosy: Alex.Willmer, vstinner, xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: Add the versions of the Android SDK and NDK to test.pythoninfo
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32210>
_______________________________________

From report at bugs.python.org  Mon Dec  4 05:08:06 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Dec 2017 10:08:06 +0000
Subject: [New-bugs-announce] [issue32211] Document the bug in re.findall()
 and re.finditer() in 2.7 and 3.6
Message-ID: <1512382086.34.0.213398074469.issue32211@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

>>> re.findall(r'^|\w+', 'two words')
['', 'wo', 'words']

Seems the current behavior was documented incorrectly in issue732120.

It will be fixed in 3.7 (see issue1647489, issue25054), but I hesitate to backport the fix to 3.6 and 2.7 because this can break the user code. For example:

In Python 3.6:

>>> list(re.finditer(r'(?m)^\s*?$', 'foo\n\n\nbar'))
[<_sre.SRE_Match object; span=(4, 4), match=''>, <_sre.SRE_Match object; span=(5, 5), match=''>]

In Python 3.7:

>>> list(re.finditer(r'(?m)^\s*?$', 'foo\n\n\nbar'))
[<re.Match object; span=(4, 4), match=''>, <re.Match object; span=(4, 5), match='\n'>, <re.Match object; span=(5, 5), match=''>]

(This is a real pattern used in the docstring module, but with re.sub()).

The proposed PR documents the current weird behavior in 2.7 and 3.6.

----------
assignee: docs at python
components: Documentation, Regular Expressions
messages: 307546
nosy: docs at python, ezio.melotti, mrabarnett, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Document the bug in re.findall() and re.finditer() in 2.7 and 3.6
type: enhancement
versions: Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32211>
_______________________________________

From report at bugs.python.org  Mon Dec  4 05:12:27 2017
From: report at bugs.python.org (Michal Plichta)
Date: Mon, 04 Dec 2017 10:12:27 +0000
Subject: [New-bugs-announce] [issue32212] few discrepancy between source and
 docs in logging
Message-ID: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za>


New submission from Michal Plichta <mplichta at gmail.com>:

my code:

logger = logging.getLogger(name)
logger.setLevel(level=logging.DEBUG)
...
stream_handler = logging.StreamHandler(stream=stdout)
stream_handler.setLevel(logging_level)
stream_handler.setFormatter(fmt=formatter)

and mypy-0.550 complains about fmt vs. form parameter in setFormatter method and level vs. lvl in setLevel method.

ta_cc/cc_logger.py: note: In function "_get_stream_handler":
ta_cc/cc_logger.py:34: error: Unexpected keyword argument "fmt" for "setFormatter" of "Handler"
/usr/local/lib/mypy/typeshed/stdlib/2and3/logging/__init__.pyi:147: note: "setFormatter" of "Handler" defined here
ta_cc/cc_logger.py:109: error: Unexpected keyword argument "level" for "setLevel" of "Logger"
/usr/local/lib/mypy/typeshed/stdlib/2and3/logging/__init__.pyi:46: note: "setLevel" of "Logger" defined here

I see in online documentation that indeed there are lvl and form parameters for all 2.7, 3.5 and 3.6 python version. However my Pycharm suggest level and fmt for all my installed python interpreters.

I use:
Pycharm-2017.3
Python 2.7.12
Python 3.5.2
Python 3.6.3

This is copy of my issue of: https://github.com/python/typeshed/issues/1619

----------
assignee: docs at python
components: Documentation
messages: 307547
nosy: Michal Plichta, docs at python
priority: normal
severity: normal
status: open
title: few discrepancy between source and docs in logging
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32212>
_______________________________________

From report at bugs.python.org  Mon Dec  4 09:44:28 2017
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 04 Dec 2017 14:44:28 +0000
Subject: [New-bugs-announce] [issue32213] assertRaises and subTest context
 managers cannot be nested
Message-ID: <1512398668.79.0.213398074469.issue32213@psf.upfronthosting.co.za>


New submission from Paul Ganssle <p.ganssle at gmail.com>:

The TestCase.assertRaises and TestCase.subTest macros apparently don't interact with each other well. To demonstrate, consider the following code:

    from unittest import TestCase

    class SubTestRaisesTest(TestCase):
        def test_assert_outer(self):
            for to_raise in [True, False]:
                with self.assertRaises(Exception):
                    with self.subTest(to_raise=to_raise):
                        if to_raise:
                            raise Exception()

        def test_assert_inner(self):
            for to_raise in [True, False]:
                with self.subTest(to_raise=to_raise):
                    with self.assertRaises(Exception):
                        if to_raise:
                            raise Exception()

This actually fails in two different ways.

For test_assert_outer:
  
-with subtest `to_raise=True`, the test (correctly) passes.
-with subtest `to_raise=False`, the test (correctly) fails, but the subtest is not actually assigned (no indication of which subtest it was that failed):



    ======================================================================
    FAIL: test_assert_outer (test_bug.SubTestRaisesTest)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File ".../assert_demo/test_bug.py", line 9, in test_assert_outer
        raise Exception()
    AssertionError: Exception not raised


For test_assert_inner:
- with subtest `to_raise=False`, the test (corrrectly) fails, *and* the subtest is set correctly:


    ======================================================================
    FAIL: test_assert_inner (test_bug.SubTestRaisesTest) (to_raise=False)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "..../assert_demo/test_bug.py", line 16, in test_assert_inner
        raise Exception()
    AssertionError: Exception not raised


- with subtest `to_raise=False` the test (incorrectly) fails as an error, because the exception is never caught:


    ======================================================================
    ERROR: test_assert_outer (test_bug.SubTestRaisesTest) (to_raise=True)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "..../assert_demo/test_bug.py", line 9, in test_assert_outer
        raise Exception()
    Exception


So, to sum up, the behavior that needs to be fixed:

1. When assertRaises is the outer context, the subtest value needs to be set for the failing tests.

2. When assertRaises is the *inner* context, the exception needs to be caught properly and cleared on exit from the assertRaises context.

----------
components: Tests
messages: 307569
nosy: p-ganssle
priority: normal
severity: normal
status: open
title: assertRaises and subTest context managers cannot be nested
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32213>
_______________________________________

From report at bugs.python.org  Mon Dec  4 15:24:49 2017
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 04 Dec 2017 20:24:49 +0000
Subject: [New-bugs-announce] [issue32214] Implement PEP 557: Data Classes
Message-ID: <1512419089.03.0.213398074469.issue32214@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

PR to follow. Development was at https://github.com/ericvsmith/dataclasses

----------
assignee: eric.smith
components: Library (Lib)
messages: 307596
nosy: eric.smith, ned.deily
priority: normal
severity: normal
status: open
title: Implement PEP 557: Data Classes
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32214>
_______________________________________

From report at bugs.python.org  Mon Dec  4 19:40:53 2017
From: report at bugs.python.org (Brian Forst)
Date: Tue, 05 Dec 2017 00:40:53 +0000
Subject: [New-bugs-announce] [issue32215] sqlite3 400x-600x slower depending
 on formatting of an UPDATE statement in a string
Message-ID: <1512434453.0.0.213398074469.issue32215@psf.upfronthosting.co.za>


New submission from Brian Forst <bforst at gmail.com>:

We're moving some code from Python 2.7 to 3.6 and found a weird performance issue using SQLite in-memory and on-disk DBs with the built-in sqlite3 library. In Python 2.7, the two update statements below (excerpted from the attached file) run in the same amount of time. In Python 3.6 the update statement with the table name on a separate line runs 400x-600x slower with the example data provided in the file.

"""
UPDATE tbl
SET col2 = NULL
WHERE col1 = ?
"""

"""
UPDATE
  tbl
SET col2 = NULL
WHERE col1 = ?
"""

We have verified this using Python installs from python.org on macOS Sierra and Windows 7 for Python 2.7 and 3.6.

We have tried formatting the SQL strings in different ways and it appears that the speed change only occurs when the table name is on a different line than the "UPDATE".

This also appears to be hitting some type of quadratic behaviour as with 10x less records, it only takes 10-15x as long. With the demo in the file we are seeing it take 1.6s on the fast string and ~1000s on the slow string.

----------
components: Interpreter Core, Library (Lib)
files: sqlite3_27_36_performance_bug.py
messages: 307609
nosy: bforst
priority: normal
severity: normal
status: open
title: sqlite3 400x-600x slower depending on formatting of an UPDATE statement in a string
type: performance
versions: Python 2.7, Python 3.6
Added file: https://bugs.python.org/file47315/sqlite3_27_36_performance_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32215>
_______________________________________

From report at bugs.python.org  Mon Dec  4 21:05:11 2017
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 05 Dec 2017 02:05:11 +0000
Subject: [New-bugs-announce] [issue32216] Document PEP 557 Data Classes
Message-ID: <1512439511.23.0.213398074469.issue32216@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

The documentation needs to be added.

----------
assignee: docs at python
components: Documentation
messages: 307614
nosy: docs at python, eric.smith
priority: high
severity: normal
status: open
title: Document PEP 557 Data Classes
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32216>
_______________________________________

From report at bugs.python.org  Mon Dec  4 21:15:01 2017
From: report at bugs.python.org (Decorater)
Date: Tue, 05 Dec 2017 02:15:01 +0000
Subject: [New-bugs-announce] [issue32217] freeze.py fails to work.
Message-ID: <1512440101.88.0.213398074469.issue32217@psf.upfronthosting.co.za>


New submission from Decorater <seandhunt_7 at yahoo.com>:

It seems on my system installed python 3.6.0 when invoking python 3.6.3's freeze.py it seems to fail with this traceback:

python ..\externals\cpython\Tools\freeze\freeze.py pyeimport.py
Traceback (most recent call last):
  File "..\externals\cpython\Tools\freeze\freeze.py", line 491, in <module>
    main()
  File "..\externals\cpython\Tools\freeze\freeze.py", line 220, in main
    flagged_version = version + sys.abiflags
AttributeError: module 'sys' has no attribute 'abiflags'

----------
components: Demos and Tools, Windows
messages: 307615
nosy: Decorater, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: freeze.py fails to work.
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32217>
_______________________________________

From report at bugs.python.org  Mon Dec  4 22:44:12 2017
From: report at bugs.python.org (Guy Gangemi)
Date: Tue, 05 Dec 2017 03:44:12 +0000
Subject: [New-bugs-announce] [issue32218] add __iter__ to enum.Flag members
Message-ID: <1512445452.31.0.213398074469.issue32218@psf.upfronthosting.co.za>


New submission from Guy Gangemi <guy.gangemi at gmail.com>:

I'm proposing to extend enum.Flag member functionality so it is iterable in a manner similar to enum.Flag subclasses.

from enum import Flag, auto


class FlagIter(Flag):
    def __iter__(self):
        for memeber in self._member_map_.values():
            if member in self:
                yield member


class Colour(FlagIter):
    RED = auto()
    GREEN = auto()
    BLUE = auto()
    YELLOW = RED | GREEN

cyan = Colour.GREEN | Colour.Blue

print(*Colour)  # Colour.RED Colour.GREEN Colour.BLUE Colour.YELLOW

# Without the enhancement, 'not iterable' is thrown for these
print(*cyan)  # Colour.GREEN Colour.BLUE
print(*Colour.YELLOW)  # Colour.RED Colour.GREEN Colour.YELLOW
print(*~Colour.RED)  # Colour.GREEN Colour.BLUE

----------
messages: 307629
nosy: Guy Gangemi
priority: normal
severity: normal
status: open
title: add __iter__ to enum.Flag members
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32218>
_______________________________________

From report at bugs.python.org  Mon Dec  4 23:01:08 2017
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 05 Dec 2017 04:01:08 +0000
Subject: [New-bugs-announce] [issue32219] SSLWantWriteError being raised by
 blocking SSL socket
Message-ID: <1512446468.03.0.213398074469.issue32219@psf.upfronthosting.co.za>


New submission from Nathaniel Smith <njs at pobox.com>:

I have a test case that sets up a blocking SSLSocket, and eventually calls unwrap() to do a proper SSL shutdown.

Every once in a while, the test blows up, because unwrap() unexpectedly raises SSLWantWriteError. This is very unexpected for a blocking socket.

Unfortunately, since this is intermittent, I don't have a reliable reproducer.

Both of the times I've seen this so far, it was on MacOS with CPython 3.6 (the official python.org build, so whichever openssl it uses), and it was specifically in unwrap():

    https://travis-ci.org/python-trio/trio/jobs/298164123
    https://travis-ci.org/python-trio/trio/jobs/311618077

Here's the code that fails -- as you can see it's just a straightforward blocking echo server using SSLContext.wrap_socket:

    https://github.com/python-trio/trio/blob/3e62bf64946b1dcbf42c2d03e39435d4b1ba00ac/trio/tests/test_ssl.py#L92

----------
assignee: christian.heimes
components: SSL
messages: 307634
nosy: alex, christian.heimes, dstufft, janssen, njs
priority: normal
severity: normal
status: open
title: SSLWantWriteError being raised by blocking SSL socket
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32219>
_______________________________________

From report at bugs.python.org  Tue Dec  5 03:56:06 2017
From: report at bugs.python.org (Nate)
Date: Tue, 05 Dec 2017 08:56:06 +0000
Subject: [New-bugs-announce] [issue32220] multiprocessing: passing file
 descriptor using reduction breaks duplex pipes on darwin
Message-ID: <1512464166.7.0.213398074469.issue32220@psf.upfronthosting.co.za>


New submission from Nate <pm62j9t at nate.sh>:

In multiprocessing/reduction.py, there is a hack workaround in the sendfds() and recvfds() methods for darwin, as determined by the "ACKNOWLEDGE" constant. There is a reference to issue #14669 in the code related to why this was added in the first place. This bug exists in both 3.6.3 and the latest 3.7.0a2.

When a file descriptor is received, this workaround/hack sends an acknowledgement message to the sender. The problem is that this completely breaks Duplex pipes depending on the timing of the acknowledgement messages, as your "sock.send(b'A')" and "sock.recv(1) != b'A'" calls are being interwoven with my own messages.

Specifically, I have a parent process with child processes. I send socket file descriptors from the parent to the children, and am also duplexing messages from the child processes to the parent. If I am in the process of sending/receiving a message around the same time as your workaround is performing this acknowledge step, then your workaround corrupts the pipe. 

In a multi-process program, each end of a pipe must only be read or written to by a single process, but this workaround breaks this requirement. A different workaround must be found for the original bug that prompted this "acknowledge" step to be added, because library code must not be interfering with the duplex pipe.

----------
components: Library (Lib)
messages: 307649
nosy: frickenate
priority: normal
severity: normal
status: open
title: multiprocessing: passing file descriptor using reduction breaks duplex pipes on darwin
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32220>
_______________________________________

From report at bugs.python.org  Tue Dec  5 04:54:54 2017
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 05 Dec 2017 09:54:54 +0000
Subject: [New-bugs-announce] [issue32221] Converting ipv6 address to string
 representation using getnameinfo() is wrong.
Message-ID: <1512467694.45.0.213398074469.issue32221@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

https://github.com/python/cpython/pull/4724


`recvfrom` from multicast socket is painfull slow. In fact, it returns sender address in form:

`('fe80::941f:f6ff:fe04:c560%qwe', 42133, 0, 78)`
which is superfluous, since interface-name part (`%qwe`) is not actually used. Actually, scopeid (`78`) signify interface/scope/zone_id. This tuple can be used for `.sendto()` either with this interface-name-part or without.

The problem is in the performance. For each `recvrfom()`, `getnameinfo()` internally converts interface index to interface name using three syscalls, i.e. `socket(), getsockopt()?, close()` , which slows down receiving (I have not measured result, but see additional syscalls in `strace`).

In order to convert from tuple to string-based full address one may use `getnameinfo()`:
As you can see, initial interface is ignored (but without my patch it is also validated uselessly):
```
In[1]: socket.getnameinfo(('fe80::941f:f6ff:fe04:c560%qwe', 42133, 0, 78), socket.NI_NUMERICHOST)
Out[1]: ('fe80::941f:f6ff:fe04:c560%qwe', '42133')
In[2]: socket.getnameinfo(('fe80::941f:f6ff:fe04:c560', 42133, 0, 78), socket.NI_NUMERICHOST)
Out[2]: ('fe80::941f:f6ff:fe04:c560%qwe', '42133')
```

----------
components: Library (Lib)
messages: 307651
nosy: socketpair
priority: normal
severity: normal
status: open
title: Converting ipv6 address to string representation using getnameinfo() is wrong.
type: performance
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32221>
_______________________________________

From report at bugs.python.org  Tue Dec  5 05:36:15 2017
From: report at bugs.python.org (Toby Harradine)
Date: Tue, 05 Dec 2017 10:36:15 +0000
Subject: [New-bugs-announce] [issue32222] pygettext doesn't extract
 docstrings for functions with type annotated params
Message-ID: <1512470175.69.0.213398074469.issue32222@psf.upfronthosting.co.za>


New submission from Toby Harradine <tobyharradine at gmail.com>:

### Expected Behaviour
When running pygettext with the -D CLI flag, all module, class, method and function docstrings should be extracted and outputted to the .pot file.

### Actual Behaviour
In the case of functions whose parameters have PEP 484 type annotations, their docstrings are not being extracted. I have attached two files, one .py file and its corresponding .pot file, as examples of this behaviour.

----------
components: Demos and Tools
files: test_typehinted_funcs.py
messages: 307652
nosy: Toby Harradine
priority: normal
severity: normal
status: open
title: pygettext doesn't extract docstrings for functions with type annotated params
type: behavior
versions: Python 3.5, Python 3.6
Added file: https://bugs.python.org/file47316/test_typehinted_funcs.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32222>
_______________________________________

From report at bugs.python.org  Tue Dec  5 11:46:26 2017
From: report at bugs.python.org (Dan)
Date: Tue, 05 Dec 2017 16:46:26 +0000
Subject: [New-bugs-announce] [issue32223] distutils doesn't correctly read
 UTF-8 content from config files
Message-ID: <1512492386.04.0.213398074469.issue32223@psf.upfronthosting.co.za>


New submission from Dan <malantrinu at gmail.com>:

On Windows, distutils doesn't correctly read UTF-8 content from config files (setup.cfg).

Seems like the issue is located on the line reading the files via the ConfigParser; simply adding 'encoding="UTF-8"' as argument fixes the problem for me: https://github.com/python/cpython/pull/4727

On Linux it seems to be working fine.

----------
components: Distutils, Library (Lib), Windows
messages: 307668
nosy: delivrance, dstufft, eric.araujo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
pull_requests: 4633
severity: normal
status: open
title: distutils doesn't correctly read UTF-8 content from config files
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32223>
_______________________________________

From report at bugs.python.org  Tue Dec  5 13:44:36 2017
From: report at bugs.python.org (Matthew Stoltenberg)
Date: Tue, 05 Dec 2017 18:44:36 +0000
Subject: [New-bugs-announce] [issue32224] socket.creaet_connection needs to
 support full IPv6 argument
Message-ID: <1512499476.97.0.213398074469.issue32224@psf.upfronthosting.co.za>


New submission from Matthew Stoltenberg <d3matt at gmail.com>:

The following causes a ValueError in the create_connection convenience function

import socket

sock1 = socket.create_connection(('::1', '80'))
sock2 = socket.create_connection(sock1.getpeername())

----------
components: Library (Lib)
messages: 307674
nosy: Matthew Stoltenberg
priority: normal
severity: normal
status: open
title: socket.creaet_connection needs to support full IPv6 argument
type: behavior
versions: Python 3.4, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32224>
_______________________________________

From report at bugs.python.org  Tue Dec  5 15:30:14 2017
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 05 Dec 2017 20:30:14 +0000
Subject: [New-bugs-announce] [issue32225] Implement PEP 562: module
 __getattr__ and __dir__
Message-ID: <1512505814.96.0.213398074469.issue32225@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
assignee: levkivskyi
components: Interpreter Core
nosy: levkivskyi
priority: normal
severity: normal
stage: patch review
status: open
title: Implement PEP 562: module __getattr__ and __dir__
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32225>
_______________________________________

From report at bugs.python.org  Tue Dec  5 15:36:48 2017
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 05 Dec 2017 20:36:48 +0000
Subject: [New-bugs-announce] [issue32226] Implement PEP 560: Core support
 for typing module and generic types
Message-ID: <1512506208.45.0.213398074469.issue32226@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
assignee: levkivskyi
components: Interpreter Core, Library (Lib)
nosy: levkivskyi
priority: normal
severity: normal
stage: needs patch
status: open
title: Implement PEP 560: Core support for typing module and generic types
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32226>
_______________________________________

From report at bugs.python.org  Tue Dec  5 16:24:12 2017
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 05 Dec 2017 21:24:12 +0000
Subject: [New-bugs-announce] [issue32227] singledispatch support for type
 annotations
Message-ID: <1512509052.55.0.213398074469.issue32227@psf.upfronthosting.co.za>


New submission from ?ukasz Langa <lukasz at langa.pl>:

With the patch attached to this issue, @singledispatch gains support for passing the type in @register via annotations.

This looks more natural and enables more thorough type checking without repeating yourself:


@singledispatch
def generic(arg): ...

@generic.register
def _(arg: str): ...

@generic.register
def _(arg: int): ...


The previous API is still available for backwards compatibility, as well as stacking, and use with classes (sic, I was surprised to learn it's used that way, too).

The patch should be uncontroversial, maybe except for the fact that it's importing the `typing` module if annotations are used. This is necessary because of forward references, usage of None as a type, and so on. More importantly, with PEP 563 it's mandatory.

----------
assignee: lukasz.langa
components: Library (Lib)
messages: 307686
nosy: lukasz.langa, rhettinger, yselivanov
priority: normal
severity: normal
status: open
title: singledispatch support for type annotations
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32227>
_______________________________________

From report at bugs.python.org  Tue Dec  5 18:19:14 2017
From: report at bugs.python.org (andreymal)
Date: Tue, 05 Dec 2017 23:19:14 +0000
Subject: [New-bugs-announce] [issue32228] truncate() changes tell() result
Message-ID: <1512515954.76.0.213398074469.issue32228@psf.upfronthosting.co.za>


New submission from andreymal <andriyano-31 at mail.ru>:

See attached file.

As documentation about "truncate" says, "The current stream position isn?t changed." This is true for most cases. But this is not true for "wtf1.py" example. If you run it with Linux (Tested Debian 8 and Arch; Windows was not tested by me) and Python 3.3+ (or with Python 2.7 using backported "io" module), then these lines:

print('tell:', fp.tell())
print('truncate:', fp.truncate())
print('tell again:', fp.tell())

prints this:

tell: 4098
truncate: 4098
tell again: 4

As you can see, "tell" before truncate and "tell" after truncate are different. Looks like bug.

This bug will not reproduce with Python 2.7 and builtin "open" function; it affects only "io.open".

----------
components: IO
files: wtf1.py
messages: 307698
nosy: andreymal
priority: normal
severity: normal
status: open
title: truncate() changes tell() result
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: https://bugs.python.org/file47321/wtf1.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32228>
_______________________________________

From report at bugs.python.org  Tue Dec  5 23:33:06 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 06 Dec 2017 04:33:06 +0000
Subject: [New-bugs-announce] [issue32229] Simplify hiding developer warnings
 in user facing applications
Message-ID: <1512534786.28.0.213398074469.issue32229@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

One of the observations coming out of the PEP 565 discussions is that it's surprisingly tricky to opt-in to getting all warnings from a particular package and its subpackages, while opting out of warnings in general.

The simplest approximation is to do the following:

    if not sys.warnoptions:
        warnings.simplefilter("ignore")
        warnings.filterwarnings("default", module="app_pkg.*")

That shows warnings for any module or package starting with `app_pkg`. A stricter filter that avoided warnings from top-level packages that merely shared the prefix would look like:

    if not sys.warnoptions:
        warnings.simplefilter("ignore")
        warnings.filterwarnings("default", module="^app_pkg(\..*)?$")

It could be helpful to encapsulate that logic in a more declarative utility API, such that applications could do the following:

    import warnings.
    warnings.hide_warnings()

Or:

    import warnings.
    warnings.hide_warnings(override_warnoptions=True)

Or:

    import warnings.
    warnings.hide_warnings(show=["app_pkg"])

Proposed API:

    def hide_warnings(*, show=(), override_warnoptions=False):
        if override_warnoptions or not sys.warnoptions:
            simplefilter("ignore")
            for pkg_name in show:
                pkg_filter =  _make_regex_for_pkg(pkg_name)
                filterwarnings("default", module=pkg_filter)

----------
messages: 307701
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Simplify hiding developer warnings in user facing applications
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32229>
_______________________________________

From report at bugs.python.org  Wed Dec  6 03:41:00 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 06 Dec 2017 08:41:00 +0000
Subject: [New-bugs-announce] [issue32230] -X dev doesn't set sys.warnoptions
Message-ID: <1512549660.05.0.213398074469.issue32230@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The `-X dev` option is currently integrated directly with the warnings module, rather than working indirectly through `sys.warnoptions`.

This means that any third party code that currently checks sys.warnoptions will need to be updated to check sys.flags.dev_mode as well.

Rather than doing that, I propose that we instead change the way dev mode works to *literally* be equivalent to `-Wdefault`, and remove the direct integration with the warnings machinery.

(PR for that coming shortly)

----------
assignee: ncoghlan
messages: 307709
nosy: ncoghlan, vstinner
priority: normal
severity: normal
stage: test needed
status: open
title: -X dev doesn't set sys.warnoptions
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32230>
_______________________________________

From report at bugs.python.org  Wed Dec  6 05:43:15 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 06 Dec 2017 10:43:15 +0000
Subject: [New-bugs-announce] [issue32231] -bb option should override -W
 options
Message-ID: <1512556995.36.0.213398074469.issue32231@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

When implementing the "-X dev" mode, Victor was asked to make it behave differently from "-Wd", such that "python -bb -X dev" would still raise errors for bytes comparisons.

I don't think making "-X dev" and "-Wd" inconsistent with each other is the right way to address that request. Instead, I think we should find a way to make "-bb" *always* take precedence over any supplied "-W" options.

One way to do that would be to adopt an approach similar to what I've proposed for "-X dev" in https://bugs.python.org/issue32230: instead of making the warnings module aware of the "-bb" setting, we'd instead adjust the initialisation code to inject "error::BytesWarning" into sys.warnoptions *after* all of the entries from environment variables and the command line.

----------
messages: 307717
nosy: ncoghlan, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: -bb option should override -W options
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32231>
_______________________________________

From report at bugs.python.org  Wed Dec  6 08:03:40 2017
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 06 Dec 2017 13:03:40 +0000
Subject: [New-bugs-announce] [issue32232] building extensions as builtins is
 broken in 3.7
Message-ID: <1512565420.17.0.213398074469.issue32232@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

building extensions statically in linking these into the python binary is currently broken on 3.7.

I'm attaching the change that worked for me in 3.7alpha2, but doesn't work anymore with alpha3. Currently investigating.  When building extensions as builtins, these should benefit from the knowledge about the core interpreter.

x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -g -fdebug-prefix-map=/home/packages/python/3.7/python3.7-3.7.0~a3=. -fstack-protector-strong -Wformat -Werror=format-security    -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration  -IObjects -IInclude -IPython -I. -I../Include -Wdate-time -D_FORTIFY_SOURCE=2   -DPy_BUILD_CORE  -c ../Modules/_elementtree.c -o Modules/_elementtree.o
In file included from ../Include/pyatomic.h:10:0,
                 from ../Include/Python.h:53,
                 from ../Modules/_elementtree.c:16:
../Modules/_elementtree.c: In function 'element_dealloc':
../Include/pystate.h:314:34: error: '_PyRuntime' undeclared (first use in this function); did you mean 'PyRun_File'?
 #  define _PyThreadState_Current _PyRuntime.gilstate.tstate_current
                                  ^
../Include/pyatomic.h:533:5: note: in expansion of macro '_Py_atomic_load_explicit'
     _Py_atomic_load_explicit(ATOMIC_VAL, _Py_memory_order_relaxed)
     ^~~~~~~~~~~~~~~~~~~~~~~~
../Include/pystate.h:316:31: note: in expansion of macro '_Py_atomic_load_relaxed'
              ((PyThreadState*)_Py_atomic_load_relaxed(&_PyThreadState_Current))
                               ^~~~~~~~~~~~~~~~~~~~~~~
../Include/pystate.h:316:56: note: in expansion of macro '_PyThreadState_Current'
              ((PyThreadState*)_Py_atomic_load_relaxed(&_PyThreadState_Current))
                                                        ^~~~~~~~~~~~~~~~~~~~~~
../Include/object.h:1069:34: note: in expansion of macro 'PyThreadState_GET'
         PyThreadState *_tstate = PyThreadState_GET(); \
                                  ^~~~~~~~~~~~~~~~~
../Modules/_elementtree.c:634:5: note: in expansion of macro 'Py_TRASHCAN_SAFE_BEGIN'
     Py_TRASHCAN_SAFE_BEGIN(self)
     ^~~~~~~~~~~~~~~~~~~~~~
../Include/pystate.h:314:34: note: each undeclared identifier is reported only once for each function it appears in
 #  define _PyThreadState_Current _PyRuntime.gilstate.tstate_current
                                  ^
../Include/pyatomic.h:533:5: note: in expansion of macro '_Py_atomic_load_explicit'
     _Py_atomic_load_explicit(ATOMIC_VAL, _Py_memory_order_relaxed)
     ^~~~~~~~~~~~~~~~~~~~~~~~
../Include/pystate.h:316:31: note: in expansion of macro '_Py_atomic_load_relaxed'
              ((PyThreadState*)_Py_atomic_load_relaxed(&_PyThreadState_Current))
                               ^~~~~~~~~~~~~~~~~~~~~~~
../Include/pystate.h:316:56: note: in expansion of macro '_PyThreadState_Current'
              ((PyThreadState*)_Py_atomic_load_relaxed(&_PyThreadState_Current))
                                                        ^~~~~~~~~~~~~~~~~~~~~~
../Include/object.h:1069:34: note: in expansion of macro 'PyThreadState_GET'
         PyThreadState *_tstate = PyThreadState_GET(); \
                                  ^~~~~~~~~~~~~~~~~
../Modules/_elementtree.c:634:5: note: in expansion of macro 'Py_TRASHCAN_SAFE_BEGIN'
     Py_TRASHCAN_SAFE_BEGIN(self)
     ^~~~~~~~~~~~~~~~~~~~~~
../Include/pyatomic.h:56:5: error: '__atomic_load_ptr' undeclared (first use in this function); did you mean '__atomic_load_n'?
     atomic_load_explicit(&(ATOMIC_VAL)->_value, ORDER)
     ^
../Include/pyatomic.h:533:5: note: in expansion of macro '_Py_atomic_load_explicit'
     _Py_atomic_load_explicit(ATOMIC_VAL, _Py_memory_order_relaxed)
     ^~~~~~~~~~~~~~~~~~~~~~~~
../Include/pystate.h:316:31: note: in expansion of macro '_Py_atomic_load_relaxed'
              ((PyThreadState*)_Py_atomic_load_relaxed(&_PyThreadState_Current))
                               ^~~~~~~~~~~~~~~~~~~~~~~

----------
components: Build
messages: 307735
nosy: doko
priority: normal
severity: normal
status: open
title: building extensions as builtins is broken in 3.7
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32232>
_______________________________________

From report at bugs.python.org  Wed Dec  6 08:50:32 2017
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 06 Dec 2017 13:50:32 +0000
Subject: [New-bugs-announce] [issue32233] [3.7 Regression] build with
 --with-system-libmpdec is broken
Message-ID: <1512568232.66.0.213398074469.issue32233@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

in setup.py, for the _decimal module the libararies are now set exclusively to ['m'], without checking if this is really needed, and overriding the external mpdec library, breaking the build.  Is there any reason to override that?

----------
components: Build
messages: 307738
nosy: doko
priority: normal
severity: normal
status: open
title: [3.7 Regression] build with --with-system-libmpdec is broken
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32233>
_______________________________________

From report at bugs.python.org  Wed Dec  6 10:28:26 2017
From: report at bugs.python.org (sblondon)
Date: Wed, 06 Dec 2017 15:28:26 +0000
Subject: [New-bugs-announce] [issue32234] Add context management to
 mailbox.Mailbox
Message-ID: <1512574106.47.0.213398074469.issue32234@psf.upfronthosting.co.za>


New submission from sblondon <stephane.blondon at gmail.com>:

mailbox.Mailbox has a .close() method that should be called at the end of Mailbox use.
I think it would be nice to use Mailbox instances with a 'with' statement so .close() will be called it automatically. So there is no need to check for which format it's required (yes for mbox, no for Maildir, etc.)

So the source code:
mbox = mailbox.mbox("/path/to/mbox")
...
mbox.close()

could become:
with mailbox.mbox("/path/to/mbox") as mbox:
    ...

----------
components: Library (Lib)
messages: 307744
nosy: sblondon
priority: normal
severity: normal
status: open
title: Add context management to mailbox.Mailbox
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32234>
_______________________________________

From report at bugs.python.org  Wed Dec  6 11:37:53 2017
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 06 Dec 2017 16:37:53 +0000
Subject: [New-bugs-announce] [issue32235] [2.7 regression] test_xml_etree
 test_xml_etree_c failures with 2.7 and 3.6 branches 20171205
Message-ID: <1512578273.44.0.213398074469.issue32235@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

Seen with recent Debian and Ubuntu builds, 

builds configured with --with-system-expat, expat version 2.2.3.

======================================================================
ERROR: test_expat224_utf8_bug (test.test_xml_etree.BugsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/test/test_xml_etree.py", line 1513, in test_expat224_utf8_bug
    self.check_expat224_utf8_bug(text)
  File "/usr/lib/python2.7/test/test_xml_etree.py", line 1500, in check_expat224_utf8_bug
    root = ET.XML(xml)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1311, in XML
    parser.feed(text)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1657, in feed
    self._parser.Parse(data, 0)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xc3 in position 2047: unexpected end of data

======================================================================
ERROR: test_expat224_utf8_bug_file (test.test_xml_etree.BugsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/test/test_xml_etree.py", line 1518, in test_expat224_utf8_bug_file
    root = ET.fromstring(raw)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1311, in XML
    parser.feed(text)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1657, in feed
    self._parser.Parse(data, 0)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1020-1021: unexpected end of data

----------
messages: 307749
nosy: doko
priority: normal
severity: normal
status: open
title: [2.7 regression] test_xml_etree test_xml_etree_c failures with 2.7 and 3.6 branches 20171205

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32235>
_______________________________________

From report at bugs.python.org  Wed Dec  6 18:46:49 2017
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 06 Dec 2017 23:46:49 +0000
Subject: [New-bugs-announce] [issue32236] open() shouldn't silently ignore
 buffering=1 in binary mode
Message-ID: <1512604009.3.0.213398074469.issue32236@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

The fact that "buffering=1" is usable only in text mode is documented for open(). In binary mode, setting buffering to 1 is silently ignored and equivalent to using default buffer size. I argue that such behavior is:

1. Inconsistent
For example, attempts to use buffering=0 in text mode or to specify encoding in binary mode raise ValueError.

2. Dangerous
Consider the following code fragment running on *nix (inspired by real-world code):

with open("fifo", "wb", buffering=1) as out:
    for line in lines:
        out.write(line)

"fifo" refers to a FIFO (named pipe). For each line, len(line) <= PIPE_BUF. Because of line buffering, such code must be able to safely assume that each write() is atomic, so that even in case of multiple writers no line read by a FIFO reader will ever get intermixed with another line. And it's so in Python 2. After migration to Python 3 (assuming that line is now bytes), this code still works on Linux because of two factors:
a) PIPE_BUF is 4096, and so is the default IO buffer size (usually)
b) When a write() is going to overflow the buffer, BufferedWriter first flushes and then processes the new write() (based on my experiment). So, each OS write() is called with complete lines only and is atomic per (a).

But PIPE_BUF is 512 on Mac OS X (I don't know about default buffer size). So, we are likely to have a subtle 2-to-3 migration issue.

I suggest to raise a ValueError if buffering=1 is used for binary mode. Note that issue 10344 (msg244354) and issue 21332 would have been uncovered earlier if it was done from the beginning.

----------
components: IO
messages: 307775
nosy: izbyshev, pitrou
priority: normal
severity: normal
status: open
title: open() shouldn't silently ignore buffering=1 in binary mode
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32236>
_______________________________________

From report at bugs.python.org  Wed Dec  6 19:02:30 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Dec 2017 00:02:30 +0000
Subject: [New-bugs-announce] [issue32237] test_xml_etree leaked [1, 1,
 1] references, sum=3
Message-ID: <1512604950.09.0.213398074469.issue32237@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

The commit eea3cc1ef0dec0af193eedb4c1164263fbdfd8cc introduced the following regression:

vstinner at apu$ make && ./python -m test -R 3:3 test_xml_etree
(...)
test_xml_etree leaked [1, 1, 1] references, sum=3

----------
messages: 307777
nosy: nascheme, vstinner
priority: normal
severity: normal
status: open
title: test_xml_etree leaked [1, 1, 1] references, sum=3
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32237>
_______________________________________

From report at bugs.python.org  Wed Dec  6 19:28:35 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 07 Dec 2017 00:28:35 +0000
Subject: [New-bugs-announce] [issue32238] Handle "POSIX" in the legacy
 locale detection
Message-ID: <1512606515.62.0.213398074469.issue32238@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Right now, the legacy locale detection introduced in PEP 538 doesn't trigger for "LANG=POSIX" and "LC_CTYPE=POSIX" on macOS and other *BSD systems.

This is because we're looking specifically for "C" as the response from "setlocale(LC_CTYPE, NULL)", which works on Linux (where glibc reports "C" if you configured "POSIX"), but not on *BSD systems (where POSIX and C behave the same way, but are still reported as distinct locales).

As per Jakub Wilk's comments at https://mail.python.org/pipermail/python-dev/2017-December/151105.html, this isn't right: we should allow either string to be returned from setlocale, and consider both of them as indicating a legacy locale to be coerced to an explicitly UTF-8 based one if possible.

----------
components: FreeBSD, Interpreter Core, Unicode, macOS
messages: 307781
nosy: ezio.melotti, koobs, ncoghlan, ned.deily, ronaldoussoren, vstinner
priority: normal
severity: normal
stage: test needed
status: open
title: Handle "POSIX" in the legacy locale detection
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32238>
_______________________________________

From report at bugs.python.org  Wed Dec  6 22:54:39 2017
From: report at bugs.python.org (Joshua Ringer)
Date: Thu, 07 Dec 2017 03:54:39 +0000
Subject: [New-bugs-announce] [issue32239] decimal module exception args
 incorrect for c module
Message-ID: <1512618879.8.0.213398074469.issue32239@psf.upfronthosting.co.za>


New submission from Joshua Ringer <i.atent.dead at gmail.com>:

Exception instance args for decimal errors are supposed to be a descriptive string. However, in the c module, they are currently a list of one containing the underlying exception class. The pure python module is correct.

See the following interpreter output for further detail:

Python 3.6.3 (default, Oct  4 2017, 06:09:15)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from _pydecimal import Decimal
>>> Decimal('badstring')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/Cellar/python3/3.6.3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/_pydecimal.py", line 597, in __new__
    "Invalid literal for Decimal: %r" % value)
  File "/usr/local/Cellar/python3/3.6.3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/_pydecimal.py", line 4081, in _raise_error
    raise error(explanation)
decimal.InvalidOperation: Invalid literal for Decimal: 'badstring'
>>> from _decimal import Decimal
>>> Decimal('badstring')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
decimal.InvalidOperation: [<class 'decimal.ConversionSyntax'>]

----------
components: Library (Lib)
messages: 307788
nosy: joshringer
priority: normal
severity: normal
status: open
title: decimal module exception args incorrect for c module
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32239>
_______________________________________

From report at bugs.python.org  Thu Dec  7 06:21:41 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Dec 2017 11:21:41 +0000
Subject: [New-bugs-announce] [issue32240] Add the const qualifier for
 PyObject* array arguments
Message-ID: <1512645701.53.0.213398074469.issue32240@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The proposed PR replaces argument declarations "PyObject **args" with "PyObject * const *args". In many cases this can be a pointer to the internal array of the tuple object. It is not safe to change it.

PyEval_EvalCodeEx() is the only public function affected by this change, but this change is backward compatible. All other affected code is a private C API.

----------
messages: 307795
nosy: serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Add the const qualifier for PyObject* array arguments
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32240>
_______________________________________

From report at bugs.python.org  Thu Dec  7 08:54:04 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Dec 2017 13:54:04 +0000
Subject: [New-bugs-announce] [issue32241] Add the const qualifier for char
 and wchar_t pointers to unmodifiable strings
Message-ID: <1512654844.82.0.213398074469.issue32241@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Py_SetProgramName() and Py_SetPythonHome() take a pointer to a string that shouldn't be changed for the duration of the program's execution. But the type of their arguments is "wchar_t *", therefore passing just a pointer to a constant static string will cause a compiler warning. The proposed PR changes the type to "const wchar_t *". This is backward compatible change.

The PR also adds the const qualifier to internal pointers that point on to unmodifiable strings. This could help to distinguish them from pointers on modifiable strings and can prevent unintentional modifications.

----------
components: Interpreter Core
messages: 307802
nosy: serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Add the const qualifier for char and wchar_t pointers to unmodifiable strings
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32241>
_______________________________________

From report at bugs.python.org  Thu Dec  7 09:15:53 2017
From: report at bugs.python.org (Vishu Viswanathan)
Date: Thu, 07 Dec 2017 14:15:53 +0000
Subject: [New-bugs-announce] [issue32242] loop in loop with with 'zip'ped
 object misbehaves in py3.6
Message-ID: <1512656153.71.0.213398074469.issue32242@psf.upfronthosting.co.za>


New submission from Vishu Viswanathan <viswanathan.m at gmail.com>:

The file shows the results by running in Py3.6 and 2.7
In my opinion Py2.7 results matches what I expected.

In this bug or the zip function behaviour is changed with some purpose

----------
files: py3.6_vs_py2.7.ipynb
messages: 307803
nosy: Vishu Viswanathan
priority: normal
severity: normal
status: open
title: loop in loop with with 'zip'ped object misbehaves in py3.6
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47328/py3.6_vs_py2.7.ipynb

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32242>
_______________________________________

From report at bugs.python.org  Thu Dec  7 09:38:53 2017
From: report at bugs.python.org (Erik Bray)
Date: Thu, 07 Dec 2017 14:38:53 +0000
Subject: [New-bugs-announce] [issue32243] Tests that set aggressive switch
 interval hang in Cygwin on a VM
Message-ID: <1512657533.84.0.213398074469.issue32243@psf.upfronthosting.co.za>


New submission from Erik Bray <erik.m.bray at gmail.com>:

This is basically the same as #26939, but rather than Android running in an emulator it is affecting Cygwin running in a slow VM (in this case it's on my university's OpenStack infrastructure--I don't know what hypervisor they're using but probably KVM--either way the point is that it's a Windows VM and relatively slow).

With Cygwin on Windows running natively this has never been a problem.

FWIW I tried my own version of Victor's patch from #23428 (adapted to the new _PyTime API).  This patch would be worth applying regardless and I can attach my version of the patch to that ticket, but alone it did not fix it.

On top of that I also added a version of Xavier's patch from #26939 that adjusts the wait interval in PyCOND_TIMEDWAIT to ensure that the deadline is late enough to account for delays.  I'm not sure that this is completely fool-proof, but it solved the problem for me.  With that patch I was unable to make the system hang again.

For some reason in #26939 that more general fix was abandoned in favor of simply setting the switch interval less aggressively for those tests in the particular case of the android emulator.  But it seems that the more general fix might still be worthwhile.

----------
components: Tests
messages: 307808
nosy: erik.bray
priority: normal
severity: normal
status: open
title: Tests that set aggressive switch interval hang in Cygwin on a VM

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32243>
_______________________________________

From report at bugs.python.org  Thu Dec  7 10:09:59 2017
From: report at bugs.python.org (Tom Cook)
Date: Thu, 07 Dec 2017 15:09:59 +0000
Subject: [New-bugs-announce] [issue32244] Multiprocessing:
 multiprocessing.connection.Listener.accept() should accept a timeout
Message-ID: <1512659399.52.0.213398074469.issue32244@psf.upfronthosting.co.za>


New submission from Tom Cook <tom.k.cook at gmail.com>:

If nothing connects to it, `multiprocessing.connection.Listener.accept()` will block forever with no good way to interrupt it.

Supposing that a thread implements a loop like this:

    def run(self):
        l = Listener(socket_path, 'AF_UNIX')
        while self.running:
            c = l.accept()
            while self.running:
                data = c.recv()
                self.process(data)

There is no obvious way to implement a `stop` method on this thread.  Setting `self.running = False` may never result in the thread terminating, as it may be that no client connects to it.  The following is a possible way of implementing it:

    def stop(self):
        self.running = False
        try:
            c = Client(socket_path, 'AF_UNIX')
        except:
            pass

however it seems fraught with race conditions.  Letting `accept()` accept a timeout would be a much cleaner solution to this and many similar problems.

----------
components: Library (Lib)
messages: 307809
nosy: Tom Cook
priority: normal
severity: normal
status: open
title: Multiprocessing: multiprocessing.connection.Listener.accept() should accept a timeout
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32244>
_______________________________________

From report at bugs.python.org  Thu Dec  7 10:21:22 2017
From: report at bugs.python.org (Simon Depiets)
Date: Thu, 07 Dec 2017 15:21:22 +0000
Subject: [New-bugs-announce] [issue32245] OSError: raw write() returned
 invalid length on latest Win 10 Consoles
Message-ID: <1512660082.17.0.213398074469.issue32245@psf.upfronthosting.co.za>


New submission from Simon Depiets <sdepiets at gmail.com>:

A couple of users have been having issues on console output since the Fall 2017 Creator Update on Windows 10

An OSError is triggered randomly when rewriting data on the console (typically with progress bars, for instance when you install a module with pip), this only happens with the Microsoft Console (within Powershell or cmd.exe).

It seems the windows stdout console stream returns a length double what python expects. I don't have the skills to go deeper than the bufferedio.c method _bufferedwriter_raw_write to diagnostic the issue, so I've made a very dirty fix (which I do not recommend) https://github.com/python/cpython/compare/3.5...LlianeFR:patch-1

Different unrelated use cases where an error is triggered :

https://stackoverflow.com/questions/47356993/oserror-raw-write-returned-invalid-length-when-using-print-in-python

https://github.com/Microsoft/vscode/issues/39149

----------
components: IO
messages: 307811
nosy: Simon Depiets
priority: normal
severity: normal
status: open
title: OSError: raw write() returned invalid length on latest Win 10 Consoles
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32245>
_______________________________________

From report at bugs.python.org  Thu Dec  7 11:01:42 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 07 Dec 2017 16:01:42 +0000
Subject: [New-bugs-announce] [issue32246] test_regrtest alters the execution
 environment on Android
Message-ID: <1512662502.3.0.213398074469.issue32246@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

Sorry, this is a bit involved :-(
BTW all the tests except this one pass (ctypes is disabled on x86_64 and arm64) on Android API 24 for x86, x86_64, armv7 and arm64 :-)

Description:
-----------
There are two different cases:
1) When buildbottest is tweaked to run only test_regrtest and is run remotely from the build system, the error occurs systematically and is:

      Warning -- files was modified by test_regrtest
        Before: []
        After:  ['test_python_2535/']

Here is the command that is run remotely (through adb), the run_tests.py file is Tools/scripts/run_tests.py from the src tree that has been pushed to the emulator by buildbottest:

python /data/local/tmp/python/bin/run_tests.py -j 1 -u all -W --slowest --fail-env-changed --timeout=900 -j2 test_regrtest

The command also fails when replacing '-j2' with '-j1'.

In that case:
* There is no 'test_support_*' directory left over in the TEMP directory, the directory is clean.
* The command 'adb logcat' reports a crash ("Fatal signal 11 (SIGSEGV)") during the execution of the command. This sounds familiar :-)


2) When this same command is run on the emulator (i.e. the user is remotely logged in with the command 'adb shell'), the environment is never altered (never == about 20 attempts to raise the problem).

In that case:
* A 'test_support_*' directory is left in the TEMP directory and it is empty.

The fact that the TEMP directory is not clean already happens when running buildbottest natively with the standard Python Makefile (no one has noticed it yet I guess) and the directory contains a core file. This is another bug, related to this one and it provided a much welcome hint to use 'adb logcat' and for a work-around :-)
Maybe this last bug is related to issue 26295 ?

Work-around
-----------
* The problem does not happen when skipping ArgsTestCase.test_crashed for Android in the same manner that tests that raise SIGSEGV are skipped in test_faulthandler. And there is no 'test_support_*' directory left over in the TEMP directory.

----------
components: Tests
messages: 307812
nosy: vstinner, xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: test_regrtest alters the execution environment on Android
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32246>
_______________________________________

From report at bugs.python.org  Thu Dec  7 15:56:56 2017
From: report at bugs.python.org (Radostin)
Date: Thu, 07 Dec 2017 20:56:56 +0000
Subject: [New-bugs-announce] [issue32247] shutil-copytree: Create dst folder
 only if it doesn't exist
Message-ID: <1512680216.59.0.213398074469.issue32247@psf.upfronthosting.co.za>


New submission from Radostin <rstoyanov1 at gmail.com>:

shutil.copytree method always tries to create the destination directory which raises the error message "OSError: [Errno 17] File exists".

This issue has been discussed here:
https://stackoverflow.com/questions/1868714/how-do-i-copy-an-entire-directory-of-files-into-an-existing-directory-using-pyth

----------
messages: 307823
nosy: rst0py
priority: normal
pull_requests: 4655
severity: normal
status: open
title: shutil-copytree: Create dst folder only if it doesn't exist
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32247>
_______________________________________

From report at bugs.python.org  Thu Dec  7 16:12:39 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 07 Dec 2017 21:12:39 +0000
Subject: [New-bugs-announce] [issue32248] Port importlib_resources (module
 and ABC) to Python 3.7
Message-ID: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

We intend to port importlib_resources to Python 3.7 as importlib.resources, with a provisional API.  There's also a ResourceReader ABC to include, along with documentation and tests.

Nosying Brett and assigning to myself, but if Brett *wants* to do the work, I won't stand in his way. :)

----------
assignee: barry
components: Library (Lib)
messages: 307824
nosy: barry, brett.cannon
priority: normal
severity: normal
status: open
title: Port importlib_resources (module and ABC) to Python 3.7
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32248>
_______________________________________

From report at bugs.python.org  Thu Dec  7 17:47:25 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 07 Dec 2017 22:47:25 +0000
Subject: [New-bugs-announce] [issue32249] Document handler.cancelled()
Message-ID: <1512686845.02.0.213398074469.issue32249@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Method was added by https://bugs.python.org/issue31943

----------
components: asyncio
messages: 307825
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Document handler.cancelled()
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32249>
_______________________________________

From report at bugs.python.org  Thu Dec  7 18:04:02 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 07 Dec 2017 23:04:02 +0000
Subject: [New-bugs-announce] [issue32250] Add loop.current_task() and
 loop.all_tasks() methods
Message-ID: <1512687842.07.0.213398074469.issue32250@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Existing `Task.current_task()` and `Task.all_tasks()` class methods are not overridable by custom event loop implementation.

The proposal is adding new optional loop methods and using them by existing task methods.

----------
components: asyncio
messages: 307826
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Add loop.current_task() and loop.all_tasks() methods
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32250>
_______________________________________

From report at bugs.python.org  Thu Dec  7 21:04:18 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 08 Dec 2017 02:04:18 +0000
Subject: [New-bugs-announce] [issue32251] Add asyncio.BufferedProtocol
Message-ID: <1512698658.84.0.213398074469.issue32251@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
assignee: yselivanov
components: asyncio
nosy: asvetlov, gvanrossum, pitrou, yselivanov
priority: normal
severity: normal
status: open
title: Add asyncio.BufferedProtocol
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32251>
_______________________________________

From report at bugs.python.org  Fri Dec  8 03:49:13 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 08 Dec 2017 08:49:13 +0000
Subject: [New-bugs-announce] [issue32252] test_regrtest leaves a
 test_python_* directory in TEMPDIR
Message-ID: <1512722953.36.0.213398074469.issue32252@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

After running test_regrtest in the source tree on linux, the build/ subdirectory (i.e. test.libregrtest.main.TEMPDIR) contains a new test_python_* directory that contains a core file when the core file size is unlimited.

I did not test on 3.6.

----------
components: Tests
messages: 307837
nosy: vstinner, xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: test_regrtest  leaves a test_python_* directory in TEMPDIR
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32252>
_______________________________________

From report at bugs.python.org  Fri Dec  8 03:59:40 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 08 Dec 2017 08:59:40 +0000
Subject: [New-bugs-announce] [issue32253] Deprecate old-style locking in
 asyncio/locks.py
Message-ID: <1512723580.6.0.213398074469.issue32253@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Now constructions like

await lock  # "yield from lock" can be used as well
try:
    ...
finally:
    lock.release()

and

with (yield from lock):
    ...

are supported. Let's deprecate them in favor of

async with lock:
    ...

----------
components: asyncio
messages: 307839
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Deprecate old-style locking in asyncio/locks.py
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32253>
_______________________________________

From report at bugs.python.org  Fri Dec  8 04:41:48 2017
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 08 Dec 2017 09:41:48 +0000
Subject: [New-bugs-announce] [issue32254] documentation builds (even local
 ones) refer to https://docs.python.org/
Message-ID: <1512726108.41.0.213398074469.issue32254@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

lintian (the Debian packaging checker) recently started flagging so-called "privacy-breach" issues:

https://lintian.debian.org/maintainer/doko at debian.org.html#python2.7

python2.7-doc
W privacy-breach-generic
usr/share/doc/python2.7/html/about.html (https://docs.python.org/2/about.html)
usr/share/doc/python2.7/html/bugs.html (https://docs.python.org/2/bugs.html)
usr/share/doc/python2.7/html/c-api/abstract.html (https://docs.python.org/2/c-api/abstract.html)
[...]
and 500 more.

that's because Doc/tools/templates/layout.html hardcodes an absolute URL and there is no configure way to change it.  I don't think that local builds should point to the same single-point-of-failure URL, but use local references instead.

----------
components: Build
messages: 307842
nosy: doko
priority: normal
severity: normal
status: open
title: documentation builds (even local ones) refer to https://docs.python.org/

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32254>
_______________________________________

From report at bugs.python.org  Fri Dec  8 09:43:54 2017
From: report at bugs.python.org (Licht Takeuchi)
Date: Fri, 08 Dec 2017 14:43:54 +0000
Subject: [New-bugs-announce] [issue32255] csv.writer converts None to '""\n'
 when it is first line, otherwise '\n'
Message-ID: <1512744234.4.0.213398074469.issue32255@psf.upfronthosting.co.za>


New submission from Licht Takeuchi <licht-t at outlook.jp>:

Inconsistent behavior while reading a single column CSV.
I have the patch and waiting for the CLA response.

# Case 1
## Input
```
import csv
fp = open('test.csv', 'w')
w = csv.writer(fp)
w.writerow([''])
w.writerow(['1'])
fp.close()
```
## Output
```
""
1
```

# Case 2
## Input
```
import csv
fp = open('test.csv', 'w')
w = csv.writer(fp)
w.writerow(['1'])
w.writerow([''])
fp.close()
```
## Output
```
1

```

----------
components: IO
messages: 307851
nosy: licht-t
priority: normal
severity: normal
status: open
title: csv.writer converts None to '""\n' when it is first line, otherwise '\n'
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32255>
_______________________________________

From report at bugs.python.org  Fri Dec  8 20:35:58 2017
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 09 Dec 2017 01:35:58 +0000
Subject: [New-bugs-announce] [issue32256] Make patchcheck.py work for
 out-of-tree builds
Message-ID: <1512783358.62.0.213398074469.issue32256@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

Despite some steps made in issue 9860 make patchcheck still doesn't work for out-of-tree builds because it runs git and hg in the current directory instead of the source directory (msg169465).

----------
messages: 307875
nosy: izbyshev
priority: normal
severity: normal
status: open
title: Make patchcheck.py work for out-of-tree builds
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32256>
_______________________________________

From report at bugs.python.org  Sat Dec  9 01:38:23 2017
From: report at bugs.python.org (Qichao Chu)
Date: Sat, 09 Dec 2017 06:38:23 +0000
Subject: [New-bugs-announce] [issue32257] Support Disabling Renegotiation
 for SSLContext
Message-ID: <1512801503.1.0.213398074469.issue32257@psf.upfronthosting.co.za>


New submission from Qichao Chu <qc.chu at gatech.edu>:

Adding a new method in SSLContext so that we can disable renegotiation easier.
This resolves CVE-2009-3555 and attack demoed by thc-ssl-dos

----------
assignee: christian.heimes
components: SSL
messages: 307879
nosy: christian.heimes, chuq
priority: normal
severity: normal
status: open
title: Support Disabling Renegotiation for SSLContext
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32257>
_______________________________________

From report at bugs.python.org  Sat Dec  9 05:06:15 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 09 Dec 2017 10:06:15 +0000
Subject: [New-bugs-announce] [issue32258] Rewrite ayncio docs to use
 async/await syntax
Message-ID: <1512813975.64.0.213398074469.issue32258@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

https://bugs.python.org/issue32193 switched asyncio implementation to async/await syntax.

We need to update documentation as well.

----------
assignee: docs at python
components: Documentation, asyncio
messages: 307889
nosy: asvetlov, docs at python, yselivanov
priority: normal
severity: normal
status: open
title: Rewrite ayncio docs to use async/await syntax
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32258>
_______________________________________

From report at bugs.python.org  Sat Dec  9 07:10:32 2017
From: report at bugs.python.org (Camion)
Date: Sat, 09 Dec 2017 12:10:32 +0000
Subject: [New-bugs-announce] [issue32259] Misleading "not iterable" Error
 Message when generator return a "simple" type, and a tuple is expected
Message-ID: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za>


New submission from Camion <camion_spam-pybugs at yahoo.com>:

I'm new with Python and I've been blocked for day on a "TypeError: 'Fraction' object is not iterable" error message, while the problem turned out to be completely different.

I don't even know to what programming case this message would have been the right interpretation, but in this situation, it was completely wrong and I believe it can cause much loss of time for inexperienced python programmer (at least, I believe it should document alternative causes)

Here is a sample code to show how misleading it can be (It's a program to compute pi with fractions)

from fractions import Fraction


def order(x):
    r, old_r, n, old_n = 2, 1, 1, 0
    while (x>=r):
        r, old_r, n, old_n = r*r, r, 2*n, n
    return order(x >> old_n) + old_n if old_n > 0 else 0


def terms(m, n, i):
    return Fraction(4 * m, n**(2*i+1) * (2*i+1))


def terms_generator(exp_prec):
    ws = [ [terms(parm[1], parm[2], 0), 0] + list(parm)
          for parm in ((1, 44, 57),
                       (1, 7, 239),
                       (-1, 12, 682),
                       (1, 24, 12943))]
    digits = 0
    while digits<exp_prec:
        curws = max(ws, key=lambda col: col[0])
        digits = int(0.30103 *
                     (order(curws[0].denominator))
                      - order(curws[0].numerator))
        yield curws[2] * curws[0] #, digits
        curws[2] = -curws[2]                
        curws[1] += 1
        curws[0] = terms(curws[3], curws[4], curws[1])



expected_precision = 100

pi = 0
for term, dgts in terms_generator(expected_precision):
    pi += term

print("{} digits".format(dgts))
print("pi = 3.{}".format(int((pi-3)*10**expected_precision)))




Obviously, the problem came from having forgotten one argument in the "yield" line, which has nothing to do with a problem of iterability of my type.

----------
components: Interpreter Core
messages: 307892
nosy: Camion
priority: normal
severity: normal
status: open
title: Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32259>
_______________________________________

From report at bugs.python.org  Sat Dec  9 14:02:55 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 09 Dec 2017 19:02:55 +0000
Subject: [New-bugs-announce] [issue32260] siphash shouldn't byte swap the
 keys
Message-ID: <1512846175.55.0.213398074469.issue32260@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

Reference siphash takes the keys as a bytes, so it makes sense to byte swap when reifying the keys as 64-bit integers. However, Python's modified siphash takes host integers in to start with.

----------
components: Interpreter Core
messages: 307910
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: siphash shouldn't byte swap the keys
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32260>
_______________________________________

From report at bugs.python.org  Sat Dec  9 14:14:41 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 09 Dec 2017 19:14:41 +0000
Subject: [New-bugs-announce] [issue32261] Online doc does not include
 inspect.classify_class_attrs
Message-ID: <1512846881.17.0.213398074469.issue32261@psf.upfronthosting.co.za>


New submission from Cheryl Sabella <chekat2 at gmail.com>:

Documentation for inspect.classify_class_attrs exists in the docstring and, therefore, pydoc, but is not included in the online docs for inspect.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 307912
nosy: csabella, docs at python
priority: normal
severity: normal
status: open
title: Online doc does not include inspect.classify_class_attrs
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32261>
_______________________________________

From report at bugs.python.org  Sat Dec  9 16:35:20 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 09 Dec 2017 21:35:20 +0000
Subject: [New-bugs-announce] [issue32262] Fix linting errors in asyncio code;
 use f-strings consistently
Message-ID: <1512855320.36.0.213398074469.issue32262@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
components: asyncio
nosy: yselivanov
priority: normal
severity: normal
status: open
title: Fix linting errors in asyncio code; use f-strings consistently
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32262>
_______________________________________

From report at bugs.python.org  Sat Dec  9 16:36:38 2017
From: report at bugs.python.org (Glenn Linderman)
Date: Sat, 09 Dec 2017 21:36:38 +0000
Subject: [New-bugs-announce] [issue32263] Template string docs refer to
 "normal %-based substitutions"
Message-ID: <1512855398.42.0.213398074469.issue32263@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

At least as far back as Python 3.1, the description for Template strings (section 6.1.5 in version 3.6.4rc1 docs) starts by differentiating what Template strings do, as:

Instead of the normal %-based substitutions, Templates support $-based substitutions, using the following rules:

Since this immediately follows a section describing the "Custom String Formatting" and the "Format Specification Mini-Language", which does a type of substitutions that is {} based, rather than % based, it is hard to grasp exactly why %-based substitutions would be considered "normal". Of course, I know why, due to the % operator, but for someone just reading through chapter 6, it is a reference that raises the mental question "Huh? What is normal %-based substitution? Are Templates abnormal, if %-based substitutions are normal? What did I miss? The previous section was about {}-based substitutions? Are they abnormal, too? What are normal %-based substitutions, anyway?" rather than helping to describe what Templates are and do.

----------
assignee: docs at python
components: Documentation
messages: 307922
nosy: docs at python, v+python
priority: normal
severity: normal
status: open
title: Template string docs refer to "normal %-based substitutions"
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32263>
_______________________________________

From report at bugs.python.org  Sat Dec  9 17:08:43 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 09 Dec 2017 22:08:43 +0000
Subject: [New-bugs-announce] [issue32264] move pygetopt.h into internal/
Message-ID: <1512857323.9.0.213398074469.issue32264@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

This header has no public functions. It shouldn't be distributed.

----------
components: Interpreter Core
messages: 307925
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: move pygetopt.h into internal/
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32264>
_______________________________________

From report at bugs.python.org  Sat Dec  9 17:54:10 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Dec 2017 22:54:10 +0000
Subject: [New-bugs-announce] [issue32265] Correctly classify builtin static
 and class methods
Message-ID: <1512860050.29.0.213398074469.issue32265@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Currently class and some static methods of builtin types are classified as plain methods. The proposed patch adds types.ClassMethodDescriptorType for unbound class methods of builtin types and makes inspect.classify_class_attrs() correctly classifying static and class methods of builtin types. This results in changing the help() output.

All __new__ methods now are classified as static.

Examples of class methods are dict.fromkeys and int.from_bytes.

----------
components: Library (Lib)
messages: 307928
nosy: serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Correctly classify builtin static and class methods
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32265>
_______________________________________

From report at bugs.python.org  Sun Dec 10 03:29:27 2017
From: report at bugs.python.org (Ivan Pozdeev)
Date: Sun, 10 Dec 2017 08:29:27 +0000
Subject: [New-bugs-announce] [issue32266] test_pathlib fails if current path
 has junctions
Message-ID: <1512894567.77.0.213398074469.issue32266@psf.upfronthosting.co.za>


New submission from Ivan Pozdeev <ivan_pozdeev at mail.ru>:

On this machine, C:\Users is a junction to D:\Users .

Sample failure:

Running Release|x64 interpreter...
....FFF........s...s..s.s.s................s......FF..............ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss.........................................................................................................................................................................FFF........s...s..s.s.s................s......FF...........
======================================================================
FAIL: test_complex_symlinks_absolute (__main__.PathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 2027, in test_complex_symlinks_absolute
    self._check_complex_symlinks(BASE)
  File "Lib\test\test_pathlib.py", line 1994, in _check_complex_symlinks
    self.assertEqual(p, P)
AssertionError: WindowsPath('D:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') != WindowsPath('C:/Users/Ivan/Documents/cpython_all/@test_2376_tmp')

======================================================================
FAIL: test_complex_symlinks_relative (__main__.PathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 2031, in test_complex_symlinks_relative
    self._check_complex_symlinks('.')
  File "Lib\test\test_pathlib.py", line 1994, in _check_complex_symlinks
    self.assertEqual(p, P)
AssertionError: WindowsPath('D:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') != WindowsPath('C:/Users/Ivan/Documents/cpython_all/@test_2376_tmp')

======================================================================
FAIL: test_complex_symlinks_relative_dot_dot (__main__.PathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 2035, in test_complex_symlinks_relative_dot_dot
    self._check_complex_symlinks(os.path.join('dirA', '..'))
  File "Lib\test\test_pathlib.py", line 1994, in _check_complex_symlinks
    self.assertEqual(p, P)
AssertionError: WindowsPath('D:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') != WindowsPath('C:/Users/Ivan/Documents/cpython_all/@test_2376_tmp')

======================================================================
FAIL: test_resolve_common (__main__.PathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 1491, in test_resolve_common
    os.path.join(BASE, 'foo'))
AssertionError: 'D:\\Users\\Ivan\\Documents\\cpython_all\\@test_2376_tmp\\foo' != 'C:\\Users\\Ivan\\Documents\\cpython_all\\@test_2376_tmp\\foo'
- D:\Users\Ivan\Documents\cpython_all\@test_2376_tmp\foo
? ^
+ C:\Users\Ivan\Documents\cpython_all\@test_2376_tmp\foo
? ^


======================================================================
FAIL: test_resolve_dot (__main__.PathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 1550, in test_resolve_dot
    self.assertEqual(q.resolve(strict=True), p)
AssertionError: WindowsPath('D:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') != WindowsPath('C:/Users/Ivan/Documents/cpython_all/@test_2376_tmp')

======================================================================
FAIL: test_complex_symlinks_absolute (__main__.WindowsPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 2027, in test_complex_symlinks_absolute
    self._check_complex_symlinks(BASE)
  File "Lib\test\test_pathlib.py", line 1994, in _check_complex_symlinks
    self.assertEqual(p, P)
AssertionError: WindowsPath('D:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') != WindowsPath('C:/Users/Ivan/Documents/cpython_all/@test_2376_tmp')

======================================================================
FAIL: test_complex_symlinks_relative (__main__.WindowsPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 2031, in test_complex_symlinks_relative
    self._check_complex_symlinks('.')
  File "Lib\test\test_pathlib.py", line 1994, in _check_complex_symlinks
    self.assertEqual(p, P)
AssertionError: WindowsPath('D:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') != WindowsPath('C:/Users/Ivan/Documents/cpython_all/@test_2376_tmp')

======================================================================
FAIL: test_complex_symlinks_relative_dot_dot (__main__.WindowsPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 2035, in test_complex_symlinks_relative_dot_dot
    self._check_complex_symlinks(os.path.join('dirA', '..'))
  File "Lib\test\test_pathlib.py", line 1994, in _check_complex_symlinks
    self.assertEqual(p, P)
AssertionError: WindowsPath('D:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') != WindowsPath('C:/Users/Ivan/Documents/cpython_all/@test_2376_tmp')

======================================================================
FAIL: test_resolve_common (__main__.WindowsPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 1491, in test_resolve_common
    os.path.join(BASE, 'foo'))
AssertionError: 'D:\\Users\\Ivan\\Documents\\cpython_all\\@test_2376_tmp\\foo' != 'C:\\Users\\Ivan\\Documents\\cpython_all\\@test_2376_tmp\\foo'
- D:\Users\Ivan\Documents\cpython_all\@test_2376_tmp\foo
? ^
+ C:\Users\Ivan\Documents\cpython_all\@test_2376_tmp\foo
? ^


======================================================================
FAIL: test_resolve_dot (__main__.WindowsPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 1550, in test_resolve_dot
    self.assertEqual(q.resolve(strict=True), p)
AssertionError: WindowsPath('D:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') != WindowsPath('C:/Users/Ivan/Documents/cpython_all/@test_2376_tmp')

----------------------------------------------------------------------
Ran 394 tests in 2.215s

FAILED (failures=10, skipped=112)

----------
components: Tests
messages: 307945
nosy: Ivan.Pozdeev
priority: normal
severity: normal
status: open
title: test_pathlib fails if current path has junctions
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32266>
_______________________________________

From report at bugs.python.org  Sun Dec 10 05:12:00 2017
From: report at bugs.python.org (Mario Corchero)
Date: Sun, 10 Dec 2017 10:12:00 +0000
Subject: [New-bugs-announce] [issue32267] strptime misparses offsets with
 microsecond format
Message-ID: <1512900720.16.0.213398074469.issue32267@psf.upfronthosting.co.za>


New submission from Mario Corchero <mariocj89 at gmail.com>:

At the moment strptime misparses all microsecond specifications that do not have exactly 6 digits as it is just converted into an int and considered microsecond.

This bug was introduced with the implementation in bpo-31800

Example:
_strptime._strptime("+01:30:30.001", "%z") == _strptime._strptime("+01:30:30.000001", "%z")

----------
components: Library (Lib)
messages: 307952
nosy: mariocj89
priority: normal
severity: normal
status: open
title: strptime misparses offsets with microsecond format
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32267>
_______________________________________

From report at bugs.python.org  Sun Dec 10 05:45:53 2017
From: report at bugs.python.org (Alexey Luchko)
Date: Sun, 10 Dec 2017 10:45:53 +0000
Subject: [New-bugs-announce] [issue32268] quopri.decode(): string argument
 expected, got 'bytes'
Message-ID: <1512902753.61.0.213398074469.issue32268@psf.upfronthosting.co.za>


New submission from Alexey Luchko <soulne4ny at gmail.com>:

$ python3 -c 'import io, quopri; quopri.decode(io.StringIO("some initial text data"), io.StringIO())'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/quopri.py", line 125, in decode
    output.write(odata)
TypeError: string argument expected, got 'bytes'

----------
components: Library (Lib)
messages: 307957
nosy: luch
priority: normal
severity: normal
status: open
title: quopri.decode(): string argument expected, got 'bytes'
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32268>
_______________________________________

From report at bugs.python.org  Sun Dec 10 12:08:44 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 10 Dec 2017 17:08:44 +0000
Subject: [New-bugs-announce] [issue32269] Add `asyncio.get_running_loop()`
 function
Message-ID: <1512925724.74.0.213398074469.issue32269@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

In many contexts `asyncio._get_running_loop()` is more useful than `asyncio.get_event_loop()`.  The former function is predictable and simple, the latter can change its behaviour depending on the current policy and can even create new event loops.

Both `asyncio._get_running_loop()` and `asyncio._set_running_loop()` are public asyncio API, although the leading underscore suggests that they are special and shouldn't be used by regular users.  That's true for `asyncio._set_running_loop()`, which is intended to be used by event loops exclusively.

I propose to remove the leading underscore from `asyncio._get_running_loop()`, making it `asyncio.get_running_loop()`, and thus promoting a safer alternative to `asyncio.get_event_loop()`.

`asyncio._get_running_loop()` will be deprecated and removed in Python 3.9.

----------
assignee: yselivanov
messages: 307961
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Add `asyncio.get_running_loop()` function

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32269>
_______________________________________

From report at bugs.python.org  Sun Dec 10 12:14:06 2017
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sun, 10 Dec 2017 17:14:06 +0000
Subject: [New-bugs-announce] [issue32270] subprocess closes redirected fds
 even if they are in pass_fds
Message-ID: <1512926046.73.0.213398074469.issue32270@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

Demonstration:

$ cat test.py
import os
import subprocess
import sys

fd = os.dup(sys.stdout.fileno())
subprocess.call([sys.executable, '-c',
                 'import sys;'
                 'print("Hello stdout");'
                 'print("Hello fd", file=open(int(sys.argv[1]), "w"))',
                 str(fd)],
                stdout=fd,
                pass_fds=[fd])


$ python3 test.py
Hello stdout
Traceback (most recent call last):
  File "<string>", line 1, in <module>
OSError: [Errno 9] Bad file descriptor

I see two issues here:

1. The fact that file descriptors specified for redirection are closed (even with close_fds=False) unless in range [0, 2] is not documented and not tested. If I change the corresponding code in _posixsubprocess.c to close them only if they are ends of pipes created by subprocess itself, all tests still pass. Also, shells behave differently: e.g., in command 'echo 3>&1' fd 3 is duplicated but not closed in the child, so subprocess behavior may be not what people expect.

2. pass_fds interaction with (1) should be fixed and documented. We may either raise ValueError if pass_fds contains a redirected fd or don't close such a redirected fd.

Please provide your thoughts.

----------
components: Library (Lib)
files: test.py
messages: 307962
nosy: gregory.p.smith, izbyshev, pitrou, vstinner
priority: normal
severity: normal
status: open
title: subprocess closes redirected fds even if they are in pass_fds
type: behavior
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47329/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32270>
_______________________________________

From report at bugs.python.org  Sun Dec 10 14:12:15 2017
From: report at bugs.python.org (Amit Ghadge)
Date: Sun, 10 Dec 2017 19:12:15 +0000
Subject: [New-bugs-announce] [issue32271] test_ssl test failed on Fedora 27
Message-ID: <1512933135.19.0.213398074469.issue32271@psf.upfronthosting.co.za>


New submission from Amit Ghadge <amitg.b14 at gmail.com>:

I cloned Python repo on my machine, 
below command run successfully,
$ ./configure --with-pydebug && make -j 

But When I was run $./python -m test
test_ssl failed,

0:08:44 load avg: 4.65 [303/406/1] test_ssl failed
Exception in thread Thread-85:
Traceback (most recent call last):
  File "/home/aghadge/my/Open_Source/cpython/Lib/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/home/aghadge/my/Open_Source/cpython/Lib/test/test_ssl.py", line 1936, in run
    if not self.wrap_conn():
  File "/home/aghadge/my/Open_Source/cpython/Lib/test/test_ssl.py", line 1881, in wrap_conn
    self.sock, server_side=True)
  File "/home/aghadge/my/Open_Source/cpython/Lib/ssl.py", line 401, in wrap_socket
    _context=self, _session=session)
  File "/home/aghadge/my/Open_Source/cpython/Lib/ssl.py", line 808, in __init__
    self.do_handshake()
  File "/home/aghadge/my/Open_Source/cpython/Lib/ssl.py", line 1061, in do_handshake
    self._sslobj.do_handshake()
  File "/home/aghadge/my/Open_Source/cpython/Lib/ssl.py", line 683, in do_handshake
    self._sslobj.do_handshake()
OSError: [Errno 0] Error

test test_ssl failed -- Traceback (most recent call last):
  File "/home/aghadge/my/Open_Source/cpython/Lib/test/test_ssl.py", line 3273, in test_alpn_protocols
    self.assertIsInstance(stats, ssl.SSLError)
AssertionError: {'compression': None, 'cipher': ('ECDHE-RSA-AES256-GCM-SHA384', 'TLSv1.2', 256), 'peercert': {}, 'client_alpn_protocol': None, 'client_npn_protocol': None, 'version': 'TLSv1.2', 'session_reused': False, 'session': <_ssl.Session object at 0x7f8acc86d608>, 'server_alpn_protocols': [None], 'server_npn_protocols': [None], 'server_shared_ciphers': [[('ECDHE-ECDSA-AES256-GCM-SHA384', 'TLSv1.2', 256), ('ECDHE-RSA-AES256-GCM-SHA384', 'TLSv1.2', 256), ('ECDHE-ECDSA-AES128-GCM-SHA256', 'TLSv1.2', 128), ('ECDHE-RSA-AES128-GCM-SHA256', 'TLSv1.2', 128), ('ECDHE-ECDSA-CHACHA20-POLY1305', 'TLSv1.2', 256), ('ECDHE-RSA-CHACHA20-POLY1305', 'TLSv1.2', 256), ('DHE-DSS-AES256-GCM-SHA384', 'TLSv1.2', 256), ('DHE-RSA-AES256-GCM-SHA384', 'TLSv1.2', 256), ('DHE-DSS-AES128-GCM-SHA256', 'TLSv1.2', 128), ('DHE-RSA-AES128-GCM-SHA256', 'TLSv1.2', 128), ('DHE-RSA-CHACHA20-POLY1305', 'TLSv1.2', 256), ('ECDHE-ECDSA-AES256-CCM8', 'TLSv1.2', 256), ('ECDHE-ECDSA-AES256-CCM', 'TLSv1.2', 256), ('ECDHE-ECDSA-AES256-SHA384', 'TLSv1.2', 256), ('ECDHE-RSA-AES256-SHA384', 'TLSv1.2', 256), ('ECDHE-ECDSA-AES256-SHA', 'TLSv1.0', 256), ('ECDHE-RSA-AES256-SHA', 'TLSv1.0', 256), ('DHE-RSA-AES256-CCM8', 'TLSv1.2', 256), ('DHE-RSA-AES256-CCM', 'TLSv1.2', 256), ('DHE-RSA-AES256-SHA256', 'TLSv1.2', 256), ('DHE-DSS-AES256-SHA256', 'TLSv1.2', 256), ('DHE-RSA-AES256-SHA', 'SSLv3', 256), ('DHE-DSS-AES256-SHA', 'SSLv3', 256), ('ECDHE-ECDSA-AES128-CCM8', 'TLSv1.2', 128), ('ECDHE-ECDSA-AES128-CCM', 'TLSv1.2', 128), ('ECDHE-ECDSA-AES128-SHA256', 'TLSv1.2', 128), ('ECDHE-RSA-AES128-SHA256', 'TLSv1.2', 128), ('ECDHE-ECDSA-AES128-SHA', 'TLSv1.0', 128), ('ECDHE-RSA-AES128-SHA', 'TLSv1.0', 128), ('DHE-RSA-AES128-CCM8', 'TLSv1.2', 128), ('DHE-RSA-AES128-CCM', 'TLSv1.2', 128), ('DHE-RSA-AES128-SHA256', 'TLSv1.2', 128), ('DHE-DSS-AES128-SHA256', 'TLSv1.2', 128), ('DHE-RSA-AES128-SHA', 'SSLv3', 128), ('DHE-DSS-AES128-SHA', 'SSLv3', 128), ('ECDHE-ECDSA-CAMELLIA256-SHA384', 'TLSv1.2', 256), ('ECDHE-RSA-CAMELLIA256-SHA384', 'TLSv1.2', 256), ('ECDHE-ECDSA-CAMELLIA128-SHA256', 'TLSv1.2', 128), ('ECDHE-RSA-CAMELLIA128-SHA256', 'TLSv1.2', 128), ('DHE-RSA-CAMELLIA256-SHA256', 'TLSv1.2', 256), ('DHE-DSS-CAMELLIA256-SHA256', 'TLSv1.2', 256), ('DHE-RSA-CAMELLIA128-SHA256', 'TLSv1.2', 128), ('DHE-DSS-CAMELLIA128-SHA256', 'TLSv1.2', 128), ('DHE-RSA-CAMELLIA256-SHA', 'SSLv3', 256), ('DHE-DSS-CAMELLIA256-SHA', 'SSLv3', 256), ('DHE-RSA-CAMELLIA128-SHA', 'SSLv3', 128), ('DHE-DSS-CAMELLIA128-SHA', 'SSLv3', 128), ('AES256-GCM-SHA384', 'TLSv1.2', 256), ('AES128-GCM-SHA256', 'TLSv1.2', 128), ('AES256-CCM8', 'TLSv1.2', 256), ('AES256-CCM', 'TLSv1.2', 256), ('AES128-CCM8', 'TLSv1.2', 128), ('AES128-CCM', 'TLSv1.2', 128), ('AES256-SHA256', 'TLSv1.2', 256), ('AES128-SHA256', 'TLSv1.2', 128), ('AES256-SHA', 'SSLv3', 256), ('AES128-SHA', 'SSLv3', 128), ('CAMELLIA256-SHA256', 'TLSv1.2', 256), ('CAMELLIA128-SHA256', 'TLSv1.2', 128), ('CAMELLIA256-SHA', 'SSLv3', 256), ('CAMELLIA128-SHA', 'SSLv3', 128)]]} is not an instance of <class 'ssl.SSLError'>

----------
assignee: christian.heimes
components: SSL
messages: 307972
nosy: amitg-b14, christian.heimes
priority: normal
severity: normal
status: open
title: test_ssl test failed on Fedora 27
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32271>
_______________________________________

From report at bugs.python.org  Sun Dec 10 18:57:08 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 10 Dec 2017 23:57:08 +0000
Subject: [New-bugs-announce] [issue32272] Remove asyncio.async function
Message-ID: <1512950228.3.0.213398074469.issue32272@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

asyncio.async() is a deprecated alias for asyncio.ensure_future().

Since Python 3.7, async and await are proper keywords, and it is no longer possible to use the function.  I.e. both 'from asyncio import async' and 'asyncio.async(...)' are a SyntaxError.

----------
components: asyncio
messages: 308006
nosy: yselivanov
priority: normal
severity: normal
status: open
title: Remove asyncio.async function
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32272>
_______________________________________

From report at bugs.python.org  Sun Dec 10 19:12:27 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 11 Dec 2017 00:12:27 +0000
Subject: [New-bugs-announce] [issue32273] Remove asyncio.test_utils
Message-ID: <1512951147.51.0.213398074469.issue32273@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

asyncio.test_utils was never part of asyncio API and was never even documented.  It's purely due to historical reasons that test_utils.py is in the Lib/asyncio directory.

----------
components: asyncio
messages: 308008
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Remove asyncio.test_utils
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32273>
_______________________________________

From report at bugs.python.org  Mon Dec 11 04:41:13 2017
From: report at bugs.python.org (Lele Gaifax)
Date: Mon, 11 Dec 2017 09:41:13 +0000
Subject: [New-bugs-announce] [issue32274] Potential leak in
 pysqlite_connection_init()
Message-ID: <1512985273.03.0.213398074469.issue32274@psf.upfronthosting.co.za>


New submission from Lele Gaifax <lelegaifax at gmail.com>:

The function calls ``sqlite3_open()`` that, if I understand its documentation correctly[#], returns a new connection object in all cases (that is, even on errors) with the only exception of "out of memory" (in which case it sets the second parameter to ``NULL``).

I think that the new connection object should be immediately released in case of errors, passing it to ``sqlite3_close()``.

.. [#] http://sqlite.org/c3ref/open.html

----------
messages: 308021
nosy: lelit
priority: normal
severity: normal
status: open
title: Potential leak in pysqlite_connection_init()
type: resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32274>
_______________________________________

From report at bugs.python.org  Mon Dec 11 05:45:05 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Dec 2017 10:45:05 +0000
Subject: [New-bugs-announce] [issue32275] SSL socket methods don't retry on
 EINTR?
Message-ID: <1512989105.2.0.213398074469.issue32275@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Some time ago, PEP 475 was accepted in order to automatically retry system calls on EINTR, but the _ssl module wasn't touched.

However, it seems that OpenSSL socket calls can fail with EINTR:
https://stackoverflow.com/questions/24188013/openssl-and-signals

----------
messages: 308026
nosy: alex, christian.heimes, dstufft, janssen, njs, pitrou, vstinner
priority: normal
severity: normal
status: open
title: SSL socket methods don't retry on EINTR?
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32275>
_______________________________________

From report at bugs.python.org  Mon Dec 11 09:25:27 2017
From: report at bugs.python.org (Yaroslav Halchenko)
Date: Mon, 11 Dec 2017 14:25:27 +0000
Subject: [New-bugs-announce] [issue32276] there is no way to make tempfile
 reproducible (i.e. seed the used RNG)
Message-ID: <1513002327.33.0.213398074469.issue32276@psf.upfronthosting.co.za>


New submission from Yaroslav Halchenko <yarikoptic at gmail.com>:

It is quite often desired to reproduce the same failure identically. In many cases sufficient to seed the shared random._inst (via random.seed). tempfile creates new instance(s) for its own operation and does not provide API to seed it.  I do not think it would be easy (unless I miss some pattern) to make it deterministic/reproducible for multi-process apps, but I wondered why initially (for the main process) tempfile module doesn't just reuse the random._inst while only creating a new _Random in children processes?
Another alternative solution would be to allow to specify seed for all those mkstemp/mkdtemp/... and pass it all way to _RandomNameSequence which would initialize _Random with it.  This way, developers who need to seed it, could do so

----------
messages: 308043
nosy: Yaroslav.Halchenko
priority: normal
severity: normal
status: open
title: there is no way to make tempfile reproducible (i.e. seed the used RNG)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32276>
_______________________________________

From report at bugs.python.org  Mon Dec 11 12:45:53 2017
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 11 Dec 2017 17:45:53 +0000
Subject: [New-bugs-announce] [issue32277] SystemError via chmod(symlink, ...,
 follow_symlinks=False)
Message-ID: <1513014353.51.0.213398074469.issue32277@psf.upfronthosting.co.za>


New submission from Anthony Sottile <asottile at umich.edu>:

While investigating https://bugs.python.org/issue31940 I noticed the following is raised as `SystemError` instead of the expected `NotImplementedError`

(note: you need a platform with fchmodat but does not support nofollow)

```
touch foo
ln -s foo bar
python3.6 -c 'import os; os.chmod("bar", 0o666, follow_symlinks=False)
```

Expected: raised `NotImplementedError`
Actual: raised `SystemError`

----------
messages: 308062
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: SystemError via chmod(symlink, ..., follow_symlinks=False)
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32277>
_______________________________________

From report at bugs.python.org  Mon Dec 11 14:47:31 2017
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 11 Dec 2017 19:47:31 +0000
Subject: [New-bugs-announce] [issue32278] Allow dataclasses.make_dataclass()
 to omit type information
Message-ID: <1513021651.3.0.213398074469.issue32278@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

Make the typing information optional.

>From Raymond Hettinger:

The make_dataclass() factory function in the dataclasses module currently requires type declarations. It would be nice if the type declarations were optional.

With typing (currently works):

    Point = NamedTuple('Point', [('x', float), ('y', float), ('z', float)])
    Point = make_dataclass('Point', [('x', float), ('y', float), ('z', float)])

Without typing (only the first currently works):

    Point = namedtuple('Point', ['x', 'y', 'z'])          # underlying store is a tuple
    Point = make_dataclass('Point', ['x', 'y', 'z'])      # underlying store is an instance dict

----------
assignee: eric.smith
components: Library (Lib)
messages: 308071
nosy: eric.smith, levkivskyi, rhettinger
priority: normal
severity: normal
status: open
title: Allow dataclasses.make_dataclass() to omit type information
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32278>
_______________________________________

From report at bugs.python.org  Mon Dec 11 14:58:58 2017
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 11 Dec 2017 19:58:58 +0000
Subject: [New-bugs-announce] [issue32279] Pass keyword arguments from
 dataclasses.make_dataclass() to @dataclass.
Message-ID: <1513022338.87.0.213398074469.issue32279@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

make_dataclass() should take optional keyword only arguments and pass them to @dataclass() when it uses it after it creates a new class.

The parameters are:
init=True, repr=True, eq=True, order=False, hash=None, frozen=False

Obviously, these should reflect their default values in @dataclass, should that ever change.

----------
assignee: eric.smith
components: Library (Lib)
messages: 308074
nosy: eric.smith, levkivskyi, rhettinger
priority: normal
severity: normal
status: open
title: Pass keyword arguments from dataclasses.make_dataclass() to @dataclass.
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32279>
_______________________________________

From report at bugs.python.org  Mon Dec 11 18:24:41 2017
From: report at bugs.python.org (Maxime Belanger)
Date: Mon, 11 Dec 2017 23:24:41 +0000
Subject: [New-bugs-announce] [issue32280] Expose `_PyRuntime` through a
 section name
Message-ID: <1513034681.19.0.213398074469.issue32280@psf.upfronthosting.co.za>


New submission from Maxime Belanger <max at dropbox.com>:

We've recently been toying with more sophisticated crash reporting machinery for our Desktop Python application (which we deploy on macOS, Windows and Linux).

To assist in debugging, we are storing `_PyRuntime` in a predictable location our crash reporter can later look up without needing the symbol table (this can grow complicated across multiple platforms).

Taking a page from `crashpad`'s book (https://chromium.googlesource.com/crashpad/crashpad/+/master/client/crashpad_info.cc), we've patched `pylifecycle.c` to store the `_PyRuntime` struct in a section of the same name. Upon a crash,  this section is then used by the tool to annotate each report with enough information to reconstruct the Python stack frames in each thread (as applicable).

We're contributing our patch here in the hopes this can be helpful to others.

----------
components: Interpreter Core, Windows, macOS
messages: 308079
nosy: Maxime Belanger, ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Expose `_PyRuntime` through a section name
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32280>
_______________________________________

From report at bugs.python.org  Mon Dec 11 18:26:49 2017
From: report at bugs.python.org (Ben Hyde)
Date: Mon, 11 Dec 2017 23:26:49 +0000
Subject: [New-bugs-announce] [issue32281] bdist_rpm v.s. the Macintosh
Message-ID: <1513034809.77.0.213398074469.issue32281@psf.upfronthosting.co.za>


New submission from Ben Hyde <bhyde at pobox.com>:

With the fix below is becomes possible to build rpms on the Mac.

The developer will need to install rpm tooling.  That's easy via "brew install rpm".

That, for example, installs /usr/local/bin/rpmbuild.

Sadly bdist_rpm.py only supports rpmbuild in two places, see:

https://github.com/python/cpython/blob/6f0eb93183519024cb360162bdd81b9faec97ba6/Lib/distutils/command/bdist_rpm.py#L313

Which due to the Mac's fastidious security setup we are very strongly discouraged from working around.

So, yeah, let's add a third, like so maybe:

        if ((os.path.exists('/usr/bin/rpmbuild')
             or os.path.exists('/bin/rpmbuild')
             or os.path.exists('/usr/local/bin/rpmbuild'))):
            rpm_cmd = ['rpmbuild']

And now I can use build_rpm on my mac, oh joy.

----------
components: Distutils
messages: 308080
nosy: bhyde, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: bdist_rpm v.s. the Macintosh
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32281>
_______________________________________

From report at bugs.python.org  Mon Dec 11 19:00:54 2017
From: report at bugs.python.org (Maxime Belanger)
Date: Tue, 12 Dec 2017 00:00:54 +0000
Subject: [New-bugs-announce] [issue32282] When using a Windows XP compatible
 toolset, `socketmodule.c` fails to build
Message-ID: <1513036854.54.0.213398074469.issue32282@psf.upfronthosting.co.za>


New submission from Maxime Belanger <max at dropbox.com>:

If Python is built using the Windows XP "variant" of the toolset (e.g. `v140_xp`), build errors can occur in `socketmodule.c`. This is due to the include of `VersionHelpers.h` being gated on `_MSC_VER`, which "lies" if `v140_xp` is in use.

We'll be contributing our patch to this issue here.

----------
components: Windows
messages: 308081
nosy: Maxime Belanger, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: When using a Windows XP compatible toolset, `socketmodule.c` fails to build
versions: Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32282>
_______________________________________

From report at bugs.python.org  Mon Dec 11 19:20:54 2017
From: report at bugs.python.org (Kevin Lyda)
Date: Tue, 12 Dec 2017 00:20:54 +0000
Subject: [New-bugs-announce] [issue32283] Cmd.onecmd documentation is
 misleading
Message-ID: <1513038054.93.0.213398074469.issue32283@psf.upfronthosting.co.za>


New submission from Kevin Lyda <kevin at ie.suberic.net>:

The documentation for Cmd.onecmd is misleading. It says that "This may be overridden, but should not normally need to be; see the precmd() and postcmd() methods for useful execution hooks."

https://github.com/python/cpython/blob/v3.7.0a3/Lib/cmd.py#L193

However a common idiom is to call onecmd directly to process commands coming from sys.argv. This shows up in the Cmd entries the Python MOTW site for instance.

https://pymotw.com/3/cmd/#commands-from-sys-argv

>From the docs you might think that precmd and postcmd are called when you call onecmd directly this way. However this is not true - they are only called in the cmdloop method.

https://github.com/python/cpython/blob/v3.7.0a3/Lib/cmd.py#L137

Moving the precmd and postcmd methods into onecmd would make the onecmd docs make more sense. Then they could be used in lieu of overriding onecmd for all uses of onecmd - inside of cmdloop and on its own. But loads of code depends on current behaviour.

So instead something in the docs to indicate that those hooks only work when onecmd is called inside cmdloop would be good. Perhaps like so:

        """Interpret the argument as though it had been typed in response
        to the prompt.

        This may be overridden, but should not normally need to be;
        see the precmd() and postcmd() methods for useful execution hooks
        when onecmd() is called from cmdloop(). When onecmd() is called
        directly, make sure to call precmd() and postcmd() yourself.
        The return value is a flag indicating whether interpretation of
        commands by the interpreter should stop.

        """

----------
components: Library (Lib)
messages: 308082
nosy: lyda
priority: normal
severity: normal
status: open
title: Cmd.onecmd documentation is misleading
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32283>
_______________________________________

From report at bugs.python.org  Mon Dec 11 19:34:35 2017
From: report at bugs.python.org (Sebastian Rittau)
Date: Tue, 12 Dec 2017 00:34:35 +0000
Subject: [New-bugs-announce] [issue32284] typing.TextIO and BinaryIO are not
 aliases of IO[...]
Message-ID: <1513038875.1.0.213398074469.issue32284@psf.upfronthosting.co.za>


New submission from Sebastian Rittau <srittau at rittau.biz>:

See https://github.com/python/typing/issues/518 for context.

The typing documentation for 3.6.4rc1 states:

> typing.io ... defines the generic type IO[AnyStr] and aliases TextIO and BinaryIO for respectively IO[str] and IO[bytes].

In the current implementation TextIO and BinaryIO are not aliases, but instead derived from IO. This means that values of type IO[...], and especially IO[Any] can not be assigned where TextIO or BinaryIO is expected.

----------
assignee: docs at python
components: Documentation
messages: 308083
nosy: docs at python, srittau
priority: normal
severity: normal
status: open
title: typing.TextIO and BinaryIO are not aliases of IO[...]
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32284>
_______________________________________

From report at bugs.python.org  Mon Dec 11 20:16:10 2017
From: report at bugs.python.org (Maxime Belanger)
Date: Tue, 12 Dec 2017 01:16:10 +0000
Subject: [New-bugs-announce] [issue32285] In `unicodedata`,
 it should be possible to check a unistr's normal form without
 necessarily copying it
Message-ID: <1513041370.04.0.213398074469.issue32285@psf.upfronthosting.co.za>


New submission from Maxime Belanger <max at dropbox.com>:

In our deployment of Python 2.7, we've patched `unicodedata` to introduce a new function: `is_normalized` can check whether a unistr is in a given normal form. This currently has to be done by creating a normalized copy, then checking whether it is equal to the source string.

This function uses the internal helper (also called `is_normalized`) that can "quick check" normalization, but falls back on creating a normalized copy and comparing (when necessary).

We're contributing this change in case this can helpful to others. Feedback is welcome!

----------
components: Unicode
messages: 308085
nosy: Maxime Belanger, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: In `unicodedata`, it should be possible to check a unistr's normal form without necessarily copying it
versions: Python 2.7, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32285>
_______________________________________

From report at bugs.python.org  Tue Dec 12 03:20:10 2017
From: report at bugs.python.org (wangtie)
Date: Tue, 12 Dec 2017 08:20:10 +0000
Subject: =?iso-8859-1?q?_=5BNew-bugs-announce=5D_=5Bissue32286=5D_python_?=
 =?iso-8859-1?q?2=2E7_cannot_parse_=27=1A=27?=
Message-ID: <1513066810.97.0.213398074469.issue32286@psf.upfronthosting.co.za>


New submission from wangtie <wangtie1988 at 126.com>:

I have a txt file,use code UTF-8,and include char ''(ASCII code?), when use f.readlines() to get a list, the program exit without any exception,then I got a list without data after line which include char ''.

----------
components: Unicode
files: b.txt
messages: 308091
nosy: ezio.melotti, vstinner, wt19880712wt
priority: normal
severity: normal
status: open
title: python 2.7 cannot parse ''
versions: Python 2.7
Added file: https://bugs.python.org/file47331/b.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32286>
_______________________________________

From report at bugs.python.org  Tue Dec 12 06:14:02 2017
From: report at bugs.python.org (=?utf-8?b?TWF0w7rFoSB2YWxv?=)
Date: Tue, 12 Dec 2017 11:14:02 +0000
Subject: [New-bugs-announce] [issue32287] Import of _pyio module failed on
 cygwin
Message-ID: <1513077242.25.0.213398074469.issue32287@psf.upfronthosting.co.za>


New submission from Mat?? valo <matusvalo at gmail.com>:

When trying to impor _pyio from python3 in Cygwin, import fails with exception:
$ python3
Python 3.6.3 (default, Oct 31 2017, 19:00:36)
[GCC 6.4.0] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import _pyio
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.6/_pyio.py", line 17, in <module>
    from msvcrt import setmode as _setmode
ModuleNotFoundError: No module named 'msvcrt'

This issue is breaking cherrypy server (cheroot component):
https://github.com/cherrypy/cheroot/blob/86c6b246ec7cb704c6f96123556db1a083301634/cheroot/makefile.py#L5

----------
components: IO, Library (Lib)
messages: 308115
nosy: Mat?? valo
priority: normal
severity: normal
status: open
title: Import of _pyio module failed on cygwin
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32287>
_______________________________________

From report at bugs.python.org  Tue Dec 12 06:58:23 2017
From: report at bugs.python.org (Massimiliano Culpo)
Date: Tue, 12 Dec 2017 11:58:23 +0000
Subject: [New-bugs-announce] [issue32288] Inconsistent behavior with slice
 assignment?
Message-ID: <1513079903.38.0.213398074469.issue32288@psf.upfronthosting.co.za>


New submission from Massimiliano Culpo <massimiliano.culpo at googlemail.com>:

I am not really sure if what I am reporting is to be considered a bug in the interpreter (slice built-in), a lack in documentation or if it is just me not finding the proper references (in which case feel free to close this and sorry for the noise).

Anyhow, while trying to code a class that mimics built-in lists, I noticed a few seemingly inconsistent behaviors in the use of slices to set items.

This can be reduced down to this very simple example:
```
Python 3.6.2 (default, Jul 29 2017, 00:00:00) 
[GCC 4.8.4] on linux

# 1. Slice has start and stop, step is defaulted to None
>>> a = [1, 2, 3, 4]
>>> a[1:3] = [11, 22, 33, 44]
>>> a
[1, 11, 22, 33, 44, 4]

# 2. Same as above setting explicitly step == 1
>>> a = [1, 2, 3, 4]
>>> a[1:3:1] = [11, 22, 33, 44]
>>> a
[1, 11, 22, 33, 44, 4]

# 3. Trying to do the same thing with step == -1
# (I naively expected either [1, 44, 33, 22, 11, 4] or 2. to fail like 3.)
>>> a = [1, 2, 3, 4]
>>> a[3:1:-1] = [11, 22, 33, 44]
Traceback (most recent call last):
  File "<input>", line 1, in <module>
ValueError: attempt to assign sequence of size 4 to extended slice of size 2
```

Now, the first issue: I tried to search what an "extended slice" is exactly, but found nothing in the docs. What is written here

https://docs.python.org/3/library/functions.html#slice

seems to suggest that an "extended slice" is a slice where `step is not None`, but then I would expect case 2. to behave the same as case 3. So to me it appears as either lack of documentation on the behavior, or a bug in 2.

Second issue: in the same page in the docs it's written

> slice objects are also generated when extended indexing syntax is used. For example: a[start:stop:step] or a[start:stop, i]

I wasn't aware of the second syntax, and tried to use it:
```
>>> a = [1, 2, 3, 4]
>>> a[1:3:1]
[2, 3]
>>> a[1:3, 1]
Traceback (most recent call last):
  File "<input>", line 1, in <module>
TypeError: list indices must be integers or slices, not tuple
```
I guess that's not the result one would expect...

Third issue: slightly related, but here

https://docs.python.org/3/library/stdtypes.html#mutable-sequence-types

I see that the documentation of `insert` reads:

> inserts x into s at the index given by i (same as s[i:i] = [x])

and from the interpreter:
```
help(list.insert)
Help on method_descriptor:
insert(...)
    L.insert(index, object) -- insert object before index

```

Here the fact is that `insert` really behaves like `s[i:i] = [x]`, but in my understanding it doesn't keep the promise to `insert object before index`.
```
# "Out of bounds" on the right
>>> a = [1, 2, 3, 4]
>>> a.insert(101, 11)
>>> a
[1, 2, 3, 4, 11]

# "Out of bounds" on the left
>>> a.insert(-101, 11)
>>> a
[11, 1, 2, 3, 4]
```
I don't know honestly if docs are not clear here, or if it is just me, but I didn't expect this behavior and thought it was worth reporting.

Let me know if you need more information.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 308120
nosy: Massimiliano Culpo, docs at python
priority: normal
severity: normal
status: open
title: Inconsistent behavior with slice assignment?
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32288>
_______________________________________

From report at bugs.python.org  Tue Dec 12 08:03:53 2017
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 12 Dec 2017 13:03:53 +0000
Subject: [New-bugs-announce] [issue32289] Glossary does not define "extended
 slicing"
Message-ID: <1513083833.6.0.213398074469.issue32289@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve+python at pearwood.info>:

Looking at issue 32288, I realised that the glossary doesn't define "extended slicing" or "extended slice", even though they are common terms. Although I thought I know what they meant, on closer reflection I realised I wasn't sure.

Does extended slicing refer to slice *objects* with a stride/step, as opposed to slice objects all the way back in Python 1.3 (yes, *one* point 3) that only had start and end?

Does it refer specifically to the two-colon form of slice *syntax*?

Both? Neither?

https://docs.python.org/3/glossary.html#term-slice

The only documentation I found is from the 2.3 What's New:

https://docs.python.org/2.3/whatsnew/section-slices.html

----------
assignee: docs at python
components: Documentation
messages: 308125
nosy: Massimiliano Culpo, docs at python, steven.daprano
priority: normal
severity: normal
status: open
title: Glossary does not define "extended slicing"
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32289>
_______________________________________

From report at bugs.python.org  Tue Dec 12 10:40:45 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Dec 2017 15:40:45 +0000
Subject: [New-bugs-announce] [issue32290] bolen-dmg-3.6: compilation failed
 with OSError: [Errno 23] Too many open files in system
Message-ID: <1513093245.22.0.213398074469.issue32290@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

http://buildbot.python.org/all/#/builders/49/builds/67

...
http://buildbot.python.org/all/#/builders/49/builds/67
...
Installing collected packages: sphinxcontrib-websupport, setuptools, snowballstemmer, docutils, imagesize, urllib3, chardet, certifi, idna, requests, pytz, babel, alabaster, MarkupSafe, Jinja2, six, Pygments, Sphinx, blurb
  Found existing installation: setuptools 28.8.0
    Uninstalling setuptools-28.8.0:
      Successfully uninstalled setuptools-28.8.0
  Running setup.py install for MarkupSafe: started
    Running setup.py install for MarkupSafe: finished with status 'done'
Successfully installed Jinja2-2.10 MarkupSafe-1.0 Pygments-2.2.0 Sphinx-1.6.5 alabaster-0.7.10 babel-2.5.1 blurb-1.0.5 certifi-2017.11.5 chardet-3.0.4 docutils-0.14 idna-2.6 imagesize-0.7.1 pytz-2017.3 requests-2.18.4 setuptools-38.2.4 six-1.11.0 snowballstemmer-1.2.1 sphinxcontrib-websupport-1.0.1 urllib3-1.22
The venv has been created in the ./venv directory

Exception occurred:
  File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/util/osutil.py", line 230, in getcwd
OSError: [Errno 23] Too many open files in system
Traceback (most recent call last):
  File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/cmdline.py", line 306, in main
  File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/application.py", line 339, in build
  File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/builders/__init__.py", line 331, in build_update
  File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/builders/__init__.py", line 344, in build
  File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/environment/__init__.py", line 584, in update
  File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/environment/__init__.py", line 603, in _read_serial
  File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/environment/__init__.py", line 735, in read_doc
  File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/application.py", line 489, in emit
  File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/events.py", line 79, in emit
  File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/environment/collectors/dependencies.py", line 43, in process_doc
  File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/util/osutil.py", line 230, in getcwd
OSError: [Errno 23] Too many open files in system

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./venv/bin/sphinx-build", line 11, in <module>
  File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/__init__.py", line 71, in main
  File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/__init__.py", line 113, in build_main
  File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/cmdline.py", line 309, in main
  File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/cmdline.py", line 105, in handle_exception
  File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/util/__init__.py", line 219, in save_traceback
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/tempfile.py", line 335, in mkstemp
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/tempfile.py", line 130, in _sanitize_params
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/tempfile.py", line 296, in gettempdir
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/tempfile.py", line 231, in _get_default_tempdir
FileNotFoundError: [Errno 2] No usable temporary directory found in ['/tmp', '/var/tmp', '/usr/tmp', '.']
make: *** [build] Error 1
Traceback (most recent call last):
mkdir -p build
Building NEWS from Misc/NEWS.d with blurb
PATH=./venv/bin:$PATH sphinx-build -b html -d build/doctrees -D latex_elements.papersize=  . build/html 
Running Sphinx v1.6.5
making output directory...
loading pickled environment... not yet created
building [mo]: targets for 0 po files that are out of date
building [html]: targets for 465 source files that are out of date
updating environment: 465 added, 0 changed, 0 removed
reading sources... [  0%] about
reading sources... [  0%] bugs

...
    main()
  File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Mac/BuildScript/build-installer.py", line 1620, in main
    buildPythonDocs()
  File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Mac/BuildScript/build-installer.py", line 1093, in buildPythonDocs
    runCommand('make html PYTHON=venv/bin/python')
  File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Mac/BuildScript/build-installer.py", line 531, in runCommand
    raise RuntimeError("command failed: %s"%(commandline,))
RuntimeError: command failed: make html PYTHON=venv/bin/python
program finished with exit code 1
elapsedTime=1719.516712

----------
components: macOS
messages: 308141
nosy: ned.deily, ronaldoussoren, vstinner
priority: normal
severity: normal
status: open
title: bolen-dmg-3.6: compilation failed with OSError: [Errno 23] Too many open files in system
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32290>
_______________________________________

From report at bugs.python.org  Tue Dec 12 12:00:36 2017
From: report at bugs.python.org (Marc Guetg)
Date: Tue, 12 Dec 2017 17:00:36 +0000
Subject: [New-bugs-announce] [issue32291] Value error for string shared
 memory in multiprocessing
Message-ID: <1513098036.37.0.213398074469.issue32291@psf.upfronthosting.co.za>


New submission from Marc Guetg <guetg.marc at gmail.com>:

It seems like sharing a string over processes is not possible.

	#!/usr/bin/env python3
	
	import multiprocessing
	import threading
	import ctypes
	
	
	def fun(share_c, share_s, set_c, set_s, name):
		print(f'{name}: {share_c.value}; {share_s.value}')
		share_c.value = set_c
		share_s.value = set_s
		print(f'{name}: {share_c.value}; {share_s.value}')
	
	
	if __name__ == '__main__':
		share_c = multiprocessing.Value(ctypes.c_wchar, 'a')
		share_s = multiprocessing.Value(ctypes.c_wchar_p, 'aa')
	
		print(f'pre_thread: {share_c.value}; {share_s.value}')
		thread = threading.Thread(target=fun, args=(share_c, share_s, 'b', 'bb', 'thread'))
		thread.start()
		thread.join()
	
		print(f'post_thread: {share_c.value}; {share_s.value}')
		process = multiprocessing.Process(target=fun, args=(share_c, share_s, 'c', 'cc', 'process'))
		process.start()
		process.join()
	
		print(f'post_process: {share_c.value}', end='; ')
		print(share_s.value)  # <--- Blows here

produces: 

	pre_thread: a; aa
	thread: a; aa
	thread: b; bb
	post_thread: b; bb
	process: b; bb
	process: c; cc
	post_process: c; Traceback (most recent call last):
	  File "test2.py", line 30, in <module>
	    print(share_s.value)  # <--- Blows here
	  File "<string>", line 5, in getvalue
	ValueError: character U+ff92f210 is not in range [U+0000; U+10ffff]

Where the character value in the error message is different every time. To me this seems like a bug as it is working properly with threads as well as single characters. (Maybe relevant question also here: https://stackoverflow.com/questions/47763878/how-to-share-string-between-processes?noredirect=1#comment82492062_47763878)

For the case it matters:
Python 3.6.1 (Anaconda 4.4.0) on RHEL 6

----------
components: Library (Lib), Unicode
messages: 308144
nosy: ezio.melotti, magu, vstinner
priority: normal
severity: normal
status: open
title: Value error for string shared memory in multiprocessing
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32291>
_______________________________________

From report at bugs.python.org  Tue Dec 12 12:45:37 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Dec 2017 17:45:37 +0000
Subject: [New-bugs-announce] [issue32292] Building fails on Windows
Message-ID: <1513100737.71.0.213398074469.issue32292@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Sorry if this looks more like a support request.  There's probably something wrong in my setup (I do have Visual Studio 2015 installed, though).

I am trying to build on Windows using "Tools\buildbot\build.bat -p x64".  It worked a few months ago.  Now I get:

Build FAILED.

       "c:\t\cpython\PCbuild\pcbuild.proj" (Build target) (1) ->
       "c:\t\cpython\PCbuild\pythoncore.vcxproj" (Build target) (2) ->
       (Desktop_PlatformPrepareForBuild target) ->
         C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\x64\P
       latformToolsets\v140\Toolset.targets(36,5): error MSB8036: The Windows S
       DK version 10.0.16299.0 was not found. Install the required version of W
       indows SDK or change the SDK version in the project property pages or by
        right-clicking the solution and selecting "Retarget solution". [c:\t\cp
       ython\PCbuild\pythoncore.vcxproj]

    0 Warning(s)
    1 Error(s)

----------
components: Windows
messages: 308145
nosy: paul.moore, pitrou, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Building fails on Windows
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32292>
_______________________________________

From report at bugs.python.org  Tue Dec 12 13:03:00 2017
From: report at bugs.python.org (Lloyd Vancil)
Date: Tue, 12 Dec 2017 18:03:00 +0000
Subject: [New-bugs-announce] [issue32293] macos pkg fails  10.13.2
Message-ID: <1513101780.7.0.213398074469.issue32293@psf.upfronthosting.co.za>


New submission from Lloyd Vancil <lloydevancil at gmail.com>:

the downloadble pkg file fails on attempt to install on 10.13.2  "no software to install"

----------
components: macOS
messages: 308147
nosy: Lloyd Vancil, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: macos pkg fails  10.13.2
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32293>
_______________________________________

From report at bugs.python.org  Tue Dec 12 17:13:34 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Dec 2017 22:13:34 +0000
Subject: [New-bugs-announce] [issue32294] test_semaphore_tracker() of
 test_multiprocessing_spawn fails with -W error
Message-ID: <1513116814.7.0.213398074469.issue32294@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

vstinner at apu$ PYTHONWARNINGS=error ./python -W error -m test test_multiprocessing_spawn -v -m test_semaphore_tracker 
== CPython 3.7.0a3+ (heads/master:747f48e2e9, Dec 12 2017, 23:12:36) [GCC 7.2.1 20170915 (Red Hat 7.2.1-2)]
== Linux-4.13.16-300.fc27.x86_64-x86_64-with-fedora-27-Twenty_Seven little-endian
== cwd: /home/vstinner/prog/python/master/build/test_python_29868
== CPU count: 8
== encodings: locale=UTF-8, FS=utf-8
Run tests sequentially
0:00:00 load avg: 0.52 [1/1] test_multiprocessing_spawn
test_semaphore_tracker (test.test_multiprocessing_spawn.TestSemaphoreTracker) ... FAIL
Exception ignored in: <_io.FileIO name=7 mode='rb' closefd=True>
ResourceWarning: unclosed file <_io.BufferedReader name=7>

======================================================================
FAIL: test_semaphore_tracker (test.test_multiprocessing_spawn.TestSemaphoreTracker)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vstinner/prog/python/master/Lib/test/_test_multiprocessing.py", line 4380, in test_semaphore_tracker
    _multiprocessing.sem_unlink(name2)
AssertionError: OSError not raised

----------------------------------------------------------------------
Ran 1 test in 2.060s

FAILED (failures=1)
test test_multiprocessing_spawn failed
test_multiprocessing_spawn failed

1 test failed:
    test_multiprocessing_spawn

Total duration: 2 sec
Tests result: FAILURE

----------
components: Tests
messages: 308161
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_semaphore_tracker() of test_multiprocessing_spawn fails with -W error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32294>
_______________________________________

From report at bugs.python.org  Tue Dec 12 17:39:54 2017
From: report at bugs.python.org (Ernest W. Durbin III)
Date: Tue, 12 Dec 2017 22:39:54 +0000
Subject: [New-bugs-announce] [issue32295] User friendly message when
 invoking bdist_wheel sans wheel package
Message-ID: <1513118394.49.0.213398074469.issue32295@psf.upfronthosting.co.za>


New submission from Ernest W. Durbin III <ewdurbin at gmail.com>:

Wheels are a well-known part of the Python packaging ecosystem at this point!

Many tutorials, gists, and other tools suggest to build wheels using setuptools and distutils, but may not remind users to install the wheel package.

In light of Issue 31634 being temporarily suspended and given that this does not interfere with experienced users implementing their own bdist_wheel command, it should be a welcome addition to help guide novice packagers in the right direction.

Result for a Python environment without the `wheel` package installed:

$ python3 setup.py bdist_wheel
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: invalid command 'bdist_wheel'
note: The wheel package provides this command. See https://packaging.python.org/tutorials/distributing-packages/#wheels for information on packaging wheels

----------
components: Distutils
messages: 308165
nosy: EWDurbin, dstufft, eric.araujo
priority: normal
pull_requests: 4715
severity: normal
status: open
title: User friendly message when invoking bdist_wheel sans wheel package
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32295>
_______________________________________

From report at bugs.python.org  Tue Dec 12 17:59:23 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 12 Dec 2017 22:59:23 +0000
Subject: [New-bugs-announce] [issue32296] Implement
 asyncio._get_running_loop() and get_event_loop() in C
Message-ID: <1513119563.35.0.213398074469.issue32296@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

asyncio.get_event_loop(), and, subsequently asyncio._get_running_loop() are one of the most frequently executed functions in asyncio.  They also can't be sped up by third-party event loops like uvloop.

When implemented in C they become 4x faster.

----------
assignee: yselivanov
components: asyncio
messages: 308169
nosy: asvetlov, lukasz.langa, yselivanov
priority: normal
severity: normal
status: open
title: Implement asyncio._get_running_loop() and get_event_loop() in C
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32296>
_______________________________________

From report at bugs.python.org  Tue Dec 12 19:10:06 2017
From: report at bugs.python.org (Mikhail Afanasev)
Date: Wed, 13 Dec 2017 00:10:06 +0000
Subject: [New-bugs-announce] [issue32297] Few misspellings found in Python
 source code comments.
Message-ID: <1513123806.73.0.213398074469.issue32297@psf.upfronthosting.co.za>


New submission from Mikhail Afanasev <mehanig at gmail.com>:

I have noticed few misspellings in Python source code comments while doing some research with the help of spelling and grammatic tools. I double checked all of them and corrected.
There is just one docstring affected. All the other changes are in Python source code comments. It also affects 49 different files from all the modules. 
I made a PR, and I think it's up to file maintainers to decide if they want to merge any of this edits. 
At this moment maintainer of idlelib package picked and merged changes which affect his pars independently.

----------
messages: 308175
nosy: mehanig
priority: normal
pull_requests: 4720
severity: normal
status: open
title: Few misspellings found in Python source code comments.
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32297>
_______________________________________

From report at bugs.python.org  Tue Dec 12 20:17:17 2017
From: report at bugs.python.org (Geoff Kuenning)
Date: Wed, 13 Dec 2017 01:17:17 +0000
Subject: [New-bugs-announce] [issue32298] Email.quopriprime over-encodes
 characters
Message-ID: <1513127837.95.0.213398074469.issue32298@psf.upfronthosting.co.za>


New submission from Geoff Kuenning <geoff at cs.hmc.edu>:

Email.quopriprime creates a map of header and body bytes that need no encoding:

for c in b'-!*+/' + ascii_letters.encode('ascii') + digits.encode('ascii'):
    _QUOPRI_HEADER_MAP[c] = chr(c)

This map is overly restrictive; in fact only two printable characters need to be omitted: the space and the equals sign.  The following revision to the loop creates a correct table:

for c in list(range(33, 61)) + list(range(62, 127)):
    _QUOPRI_HEADER_MAP[c] = chr(c)

Why does this matter?  Well, first, it's wasteful since it creates messages with larger headers than necessary.  But more important, it makes it impossible for other tools to operate on the messages unless they're encoding aware; for example, one can't easily grep for "foo at bar.com" because the at sign is encoded as =40.

----------
components: Library (Lib)
messages: 308181
nosy: gkuenning
priority: normal
severity: normal
status: open
title: Email.quopriprime over-encodes characters
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32298>
_______________________________________

From report at bugs.python.org  Wed Dec 13 02:08:20 2017
From: report at bugs.python.org (Allen Li)
Date: Wed, 13 Dec 2017 07:08:20 +0000
Subject: [New-bugs-announce] [issue32299] unittest.mock.patch.dict.__enter__
 should return the dict
Message-ID: <1513148900.41.0.213398074469.issue32299@psf.upfronthosting.co.za>


New submission from Allen Li <vianchielfaura at gmail.com>:

mock.patch.dict.__enter__ should return the patched dict/mapping object.

Currently it returns nothing (None).

This would make setting up fixtures more convenient:

 with mock.patch.dict(some.thing):
   some.thing['foo'] = 'bar'

 with mock.patch.dict(some.thing) as x:
   x['foo'] = 'bar'

----------
components: Library (Lib)
messages: 308188
nosy: Allen Li
priority: normal
severity: normal
status: open
title: unittest.mock.patch.dict.__enter__ should return the dict
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32299>
_______________________________________

From report at bugs.python.org  Wed Dec 13 03:37:00 2017
From: report at bugs.python.org (Aaron Meurer)
Date: Wed, 13 Dec 2017 08:37:00 +0000
Subject: [New-bugs-announce] [issue32300] print(os.environ.keys()) should
 only print the keys
Message-ID: <1513154220.65.0.213398074469.issue32300@psf.upfronthosting.co.za>


New submission from Aaron Meurer <asmeurer at gmail.com>:

Take the following scenario which happened to me recently. I am trying to debug an issue on Travis CI involving environment variables. Basically, I am not sure if an environment variable is being set correctly. So in my code, I put

print(os.environ.keys())

The reason I put keys() was 1, I didn't care about the values, and 2, I have secure environment variables set on Travis. 

To my surprise, in the Travis logs, I found something like this

KeysView(environ({'TRAVIS_STACK_FEATURES': 'basic cassandra chromium couchdb disabled-ipv6 docker docker-compose elasticsearch firefox go-toolchain google-chrome jdk memcached mongodb mysql neo4j nodejs_interpreter perl_interpreter perlbrew phantomjs postgresql python_interpreter rabbitmq redis riak ruby_interpreter sqlite xserver', 'CI': 'true', ..., 'MANPATH': '/home/travis/.nvm/versions/node/v7.4.0/share/man:/home/travis/.kiex/elixirs/elixir-1.4.5/man:/home/travis/.rvm/rubies/ruby-2.4.1/share/man:/usr/local/man:/usr/local/clang-3.9.0/share/man:/usr/local/share/man:/usr/share/man:/home/travis/.rvm/man'}))

So instead of just printing the keys like I asked for, it printed the whole environment, plus "KeysView(environ(". Included here was my secure environment variable. 

Now, fortunately, Travis hides the contents of secure environment variables in the logs, but it didn't used to (https://blog.travis-ci.com/2017-05-08-security-advisory).

Aside from being a potential security issue, it's just annoying that it prints the whole environment. The values are much larger than the keys. With a normal dictionary, print(d.keys()) just prints the keys:

>>> print(dict(a=1, b=2).keys())
dict_keys(['a', 'b'])

----------
messages: 308190
nosy: Aaron.Meurer
priority: normal
severity: normal
status: open
title: print(os.environ.keys()) should only print the keys
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32300>
_______________________________________

From report at bugs.python.org  Wed Dec 13 05:13:31 2017
From: report at bugs.python.org (Maik Ro)
Date: Wed, 13 Dec 2017 10:13:31 +0000
Subject: [New-bugs-announce] [issue32301] Typo in array documentation
Message-ID: <1513160011.36.0.213398074469.issue32301@psf.upfronthosting.co.za>


New submission from Maik Ro <lefthand3r at googlemail.com>:

.. class:: array(typecode[, initializer])

should be 

typecode, [initializer] - comma is in square brackets

----------
assignee: docs at python
components: Documentation
messages: 308195
nosy: Maik Ro, docs at python
priority: normal
severity: normal
status: open
title: Typo in array documentation
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32301>
_______________________________________

From report at bugs.python.org  Wed Dec 13 10:35:38 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Dec 2017 15:35:38 +0000
Subject: [New-bugs-announce] [issue32302] test_distutils:
 test_get_exe_bytes() failure on AppVeyor
Message-ID: <1513179338.41.0.213398074469.issue32302@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

Example: https://ci.appveyor.com/project/python/cpython/build/3.7.0a0.9414

======================================================================
ERROR: test_get_exe_bytes (distutils.tests.test_bdist_wininst.BuildWinInstTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\projects\cpython\lib\distutils\tests\test_bdist_wininst.py", line 24, in test_get_exe_bytes
    exe_file = cmd.get_exe_bytes()
  File "C:\projects\cpython\lib\distutils\command\bdist_wininst.py", line 361, in get_exe_bytes
    f = open(filename, "rb")
FileNotFoundError: [Errno 2] No such file or directory: 'C:\\projects\\cpython\\lib\\distutils\\command\\wininst-14.12.exe'
----------------------------------------------------------------------

----------
components: Tests
messages: 308203
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_distutils: test_get_exe_bytes() failure on AppVeyor
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32302>
_______________________________________

From report at bugs.python.org  Wed Dec 13 10:41:43 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 13 Dec 2017 15:41:43 +0000
Subject: [New-bugs-announce] [issue32303] Namespace packages have
 inconsistent __loader__ and __spec__.loader
Message-ID: <1513179703.14.0.213398074469.issue32303@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

Let's say I have a namespace package:

>>> importlib_resources.tests.data03.namespace
<module 'importlib_resources.tests.data03.namespace' (namespace)>

This package has a non-None __loader__ but a None __spec__.loader:

>>> importlib_resources.tests.data03.namespace.__loader__
<_frozen_importlib_external._NamespaceLoader object at 0x1043c1588>
>>> importlib_resources.tests.data03.namespace.__spec__.loader
>>> 

That seems inconsistent and broken.  I suspect it's just an oversight that the __spec__.loader for a namespace package isn't getting set.  It's probably been this way forever.

See also Issue31554

----------
messages: 308204
nosy: barry
priority: normal
severity: normal
status: open
title: Namespace packages have inconsistent __loader__ and __spec__.loader
versions: Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32303>
_______________________________________

From report at bugs.python.org  Wed Dec 13 10:48:29 2017
From: report at bugs.python.org (Louis Lecaroz)
Date: Wed, 13 Dec 2017 15:48:29 +0000
Subject: [New-bugs-announce] [issue32304] Upload failed (400): Digests do
 not match on .tar.gz ending with x0d binary code
Message-ID: <1513180109.43.0.213398074469.issue32304@psf.upfronthosting.co.za>


New submission from Louis Lecaroz <louis at lecaroz.name>:

Hi,
.tar.gz files can end with x0d bytes or whatever you want

When running setup.py sdist upload, depending on the project, the .tar.gz file, as said can sometimes end with x0d. When doing the upload, the line https://github.com/python/cpython/blob/master/Lib/distutils/command/upload.py#L162 (if value and value[-1:] == b'\r') will remove the ending char of the .tar.gz generating a 400 response error from the server like: 

Upload failed (400): Digests do not match, found: 09f23b52764a6802a87dd753009c2d3d, expected: 972b8e9d3dc8cf6ba6b4b1ad5991f013
error: Upload failed (400): Digests do not match, found: 09f23b52764a6802a87dd753009c2d3d, expected: 972b8e9d3dc8cf6ba6b4b1ad5991f013

As this line is generic & run on all key/values, I clearly understand that this check was initially written to eliminate certainly some issues on values in text format. 

But the mistake here, is that you are also changing the content of the 'content' key which contains the .tar.gz as value, and because you remove the ending 0D, you change the .tar.gz content to be uploaded. As consequence, the server will return a 400 error about a wrong digest/crc.

I was able to make the code working with all .tar.gz files by changing this line to:

                if value and value[-1:] == '\r' and not key=='content':

With a such fix, the .tar.gz content will not see its ending \r to be removed & the computed CRC from the server will be the same as computed by md5(content).hexdigest() in upload.py

----------
components: Distutils
messages: 308205
nosy: dstufft, eric.araujo, llecaroz
priority: normal
severity: normal
status: open
title: Upload failed (400): Digests do not match on .tar.gz ending with x0d binary code
type: security
versions: Python 2.7, Python 3.5, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32304>
_______________________________________

From report at bugs.python.org  Wed Dec 13 10:48:41 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 13 Dec 2017 15:48:41 +0000
Subject: [New-bugs-announce] [issue32305] Namespace packages have
 inconsistent __file__ and __spec__.origin
Message-ID: <1513180121.5.0.213398074469.issue32305@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

Along the lines of Issue32303 there's another inconsistency in namespace package metadata.  Let's say I have a namespace package:

>>> importlib_resources.tests.data03.namespace
<module 'importlib_resources.tests.data03.namespace' (namespace)>

The package has no __file__ attribute, and it has a misleading __spec__.origin

>>> importlib_resources.tests.data03.namespace.__spec__.origin
'namespace'
>>> importlib_resources.tests.data03.namespace.__file__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'importlib_resources.tests.data03.namespace' has no attribute '__file__'

This is especially bad because the documentation for __spec__.origin implies a correlation to __file__, and says:

"Name of the place from which the module is loaded, e.g. ?builtin? for built-in modules and the filename for modules loaded from source. Normally ?origin? should be set, but it may be None (the default) which indicates it is unspecified."

I don't particularly like that its origin is "namespace".  That's an odd special case that's unhelpful to test against (what if you import a non-namespace package from the directory "namespace"?)

What would break if __spec__.origin were (missing? or) None?

----------
messages: 308206
nosy: barry
priority: normal
severity: normal
status: open
title: Namespace packages have inconsistent __file__ and __spec__.origin
versions: Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32305>
_______________________________________

From report at bugs.python.org  Wed Dec 13 12:15:53 2017
From: report at bugs.python.org (=?utf-8?q?David_Luke=C5=A1?=)
Date: Wed, 13 Dec 2017 17:15:53 +0000
Subject: [New-bugs-announce] [issue32306] Clarify map API in
 concurrent.futures
Message-ID: <1513185353.85.0.213398074469.issue32306@psf.upfronthosting.co.za>


New submission from David Luke? <dafydd.lukes at gmail.com>:

The docstring for `concurrent.futures.Executor.map` starts by stating that it is "Equivalent to map(func, *iterables)". In the case of Python 3, I would argue this is true only superficially: with `map`, the user expects memory-efficient processing, i.e. that the entire resulting collection will not be held in memory at once unless s/he requests so e.g. with `list(map(...))`. (In Python 2, the expectations are different of course.) On the other hand, while `Executor.map` superficially returns a generator, which seems to align with this expectation, what happens behind the scenes is that the call blocks until all results are computed and only then starts yielding them. In other words, they have to be stored in memory all at once at some point.

The lower-level multiprocessing module also describes `multiprocessing.pool.Pool.map` as "A parallel equivalent of the map() built-in function", but at least it immediately goes on to add that "It blocks until the result is ready.", which is a clear indication that all of the results will have to be stored somewhere before being yielded.

I can think of several ways the situation could be improved, listed here from most conservative to most progressive:

1. Add "It blocks until the result is ready." to the docstring of `Executor.map` as well, preferably somewhere at the beginning.
2. Reword the docstrings of both `Executor.map` and `Pool.map` so that they don't describe the functions as "equivalent" to built-in `map`, which raises the wrong expectations. ("Similar to map(...), but blocks until all results are collected and only then yields them.")
3. I would argue that the function that can be described as semantically equivalent to `map` is actually `Pool.imap`, which yields results as they're being computed. It would be really nice if this could be added to the higher-level `futures` API, along with `Pool.imap_unordered`. `Executor.map` simply doesn't work for very long streams of data.
4. Maybe instead of adding `imap` and `imap_unordered` methods to `Executor`, it would be a good idea to change the signature of `Executor.map(func, *iterables, timeout=None, chunksize=1)` to `Executor.map(func, *iterables, timeout=None, chunksize=1, block=True, ordered=True)`, in order to keep the API simple with good defaults while providing flexibility via keyword arguments.
5. I would go so far as to say that for me personally, the `block` argument to the version of `Executor.map` proposed in #4 above should be `False` by default, because that would make it behave most like built-in `map`, which is the least suprising behavior. But I've observed that for smaller work loads, `imap` tends to be slower than `map`, so I understand it might be a tradeoff between performance and semantics. Still, in a higher-level API meant for non-experts, I think semantics should be emphasized.

If the latter options seem much too radical, please consider at least something along the lines of #1 above, I think it would help people correct their expectations when they first encounter the API :)

----------
components: Library (Lib)
messages: 308221
nosy: David Luke?
priority: normal
severity: normal
status: open
title: Clarify map API in concurrent.futures
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32306>
_______________________________________

From report at bugs.python.org  Wed Dec 13 12:46:34 2017
From: report at bugs.python.org (Natanael Copa)
Date: Wed, 13 Dec 2017 17:46:34 +0000
Subject: [New-bugs-announce] [issue32307] Bad assumption on thread stack
 size makes python crash with musl libc
Message-ID: <1513187194.31.0.213398074469.issue32307@psf.upfronthosting.co.za>


New submission from Natanael Copa <natanael.copa at docker.com>:

Python assumes that the system default thread stack size is big enough for python, except for OSX and FreeBSD where stack size is explicitly set. With musl libc the system thread stack size is only 80k, which leads to hard crash before `sys.getrecursionlimit()` is hit.

See: https://github.com/python/cpython/blob/master/Python/thread_pthread.h#L22


Testcase:

import threading
import sys

def f(n=0):
    try:
        print(n)
        f(n+1)
    except Exception:
        print("we hit recursion limit")
        sys.exit(0)

t = threading.Thread(target=f)
t.start()


This can be pasted into:

  docker run --rm -it python:2.7-alpine
  docker run --rm -it python:3.6-alpine

----------
components: Interpreter Core
messages: 308226
nosy: Natanael Copa
priority: normal
severity: normal
status: open
title: Bad assumption on thread stack size makes python crash with musl libc
type: crash
versions: Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32307>
_______________________________________

From report at bugs.python.org  Wed Dec 13 13:28:38 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Dec 2017 18:28:38 +0000
Subject: [New-bugs-announce] [issue32308] Replace empty matches adjacent to
 a previous non-empty match in re.sub()
Message-ID: <1513189718.03.0.213398074469.issue32308@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Currently re.sub() replaces empty matches only when not adjacent to a previous match. This makes it inconsistent with re.findall() and re.finditer() which finds empty matches adjacent to a previous non-empty match and with other RE engines.

Proposed PR makes all functions that makes repeated searching (re.split(), re.sub(), re.findall(), re.finditer()) mutually consistent.

The PR change the behavior of re.split() too, but this doesn't matter, since it already is different from the 3.6 behavior.

BDFL have approved this change.

This change doesn't break any stdlib code. It is expected that it will not break much third-party code, and even if it will break some code, it can be easily rewritten. For example replacing re.sub('(.*)', ...) (which now matches an empty string at the end of the string) with re.sub('(.+)', ...) is an obvious fix.

----------
assignee: serhiy.storchaka
components: Library (Lib), Regular Expressions
messages: 308229
nosy: ezio.melotti, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Replace empty matches adjacent to a previous non-empty match in re.sub()
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32308>
_______________________________________

From report at bugs.python.org  Wed Dec 13 14:54:21 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 13 Dec 2017 19:54:21 +0000
Subject: [New-bugs-announce] [issue32309] Implement asyncio.create_task()
 and asyncio.run_in_executor shortcuts
Message-ID: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

loop.create_task() and loop.run_in_executor are present very often in user code. But they are require a loop instance, actual call looks like

loop = asyncio.get_running_loop()
loop.create_task(coro())

The proposal adds create_task(coro) and run_in_executor(executor, func, *args) shortcuts for this.

----------
assignee: docs at python
components: Documentation, asyncio
messages: 308238
nosy: asvetlov, docs at python, yselivanov
priority: normal
severity: normal
status: open
title: Implement asyncio.create_task() and asyncio.run_in_executor shortcuts
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Wed Dec 13 15:25:35 2017
From: report at bugs.python.org (Neil Schemenauer)
Date: Wed, 13 Dec 2017 20:25:35 +0000
Subject: [New-bugs-announce] [issue32310] Remove _Py_PyAtExit from Python.h
Message-ID: <1513196735.39.0.213398074469.issue32310@psf.upfronthosting.co.za>


New submission from Neil Schemenauer <nas-python at arctrix.com>:

_Py_PyAtExit only supports on callback function.  Its sole use it to be used by atexit.  IMHO, it should be removed from Python.h to prevent misuse.

----------
components: Interpreter Core
messages: 308242
nosy: nascheme
priority: low
severity: normal
stage: patch review
status: open
title: Remove _Py_PyAtExit from Python.h
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32310>
_______________________________________

From report at bugs.python.org  Wed Dec 13 15:28:03 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 13 Dec 2017 20:28:03 +0000
Subject: [New-bugs-announce] [issue32311] Implement asyncio.create_task()
 shortcut
Message-ID: <1513196883.62.0.213398074469.issue32311@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
components: Library (Lib), asyncio
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Implement asyncio.create_task() shortcut
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32311>
_______________________________________

From report at bugs.python.org  Wed Dec 13 15:45:20 2017
From: report at bugs.python.org (Neil Schemenauer)
Date: Wed, 13 Dec 2017 20:45:20 +0000
Subject: [New-bugs-announce] [issue32312] Create Py_AtExitRegister C API
Message-ID: <1513197920.45.0.213398074469.issue32312@psf.upfronthosting.co.za>


New submission from Neil Schemenauer <nas-python at arctrix.com>:

It would be handy to have a C API that registered an atexit function, similar to what calling atexit.register does.  This API could be used by C extension modules to register atexit functions.

I think the implementation would be fairly simple.  We need a function that calls atexit_register().  The tricky bit is that we need to make sure the atexit module has been initialized as atexit_register uses the module state.

This API is different from Py_AtExit in that atexit.register() calls the function early in the interpreter shutdown whereas Py_AtExit calls functions very late in the shutdown.

----------
messages: 308246
nosy: nascheme
priority: low
severity: normal
stage: needs patch
status: open
title: Create Py_AtExitRegister C API
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32312>
_______________________________________

From report at bugs.python.org  Wed Dec 13 16:46:39 2017
From: report at bugs.python.org (Aaron Meurer)
Date: Wed, 13 Dec 2017 21:46:39 +0000
Subject: [New-bugs-announce] [issue32313] Wrong inspect.getsource for
 datetime
Message-ID: <1513201599.09.0.213398074469.issue32313@psf.upfronthosting.co.za>


New submission from Aaron Meurer <asmeurer at gmail.com>:

inspect.getsource(datetime) shows the Python source code for datetime, even when it is the C extension. This is very confusing. 

I believe it's because _datetime is used to override everything in datetime at the end of the file (here https://github.com/python/cpython/blob/11a247df88f15b51feff8a3c46005676bb29b96e/Lib/datetime.py#L2285), but __file__ is not imported.

----------
messages: 308255
nosy: Aaron.Meurer
priority: normal
severity: normal
status: open
title: Wrong inspect.getsource for datetime

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32313>
_______________________________________

From report at bugs.python.org  Wed Dec 13 16:47:08 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 13 Dec 2017 21:47:08 +0000
Subject: [New-bugs-announce] [issue32314] Implement asyncio.run()
Message-ID: <1513201628.59.0.213398074469.issue32314@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

There's a fairly extensive discussion here: https://github.com/python/asyncio/pull/465

In short, asyncio.run() is a pretty straightforward addition, so let's add it.

The discussion was more focused on the asyncio.run_forever() proposal.  I now think that it shouldn't be implemented in asyncio.  Instead we should fix cases where 'loop.run_forever' is usually required.  Mainly that's servers, and they are easily fixable by making "Server" an async context manager and implementing a "server.serve_forever()" method.  That way, with asyncio.run():

    async def serve_something():
       async with asyncio.start_server(...) as server:
           await server.serve_forever()

    asyncio.run(serve_something())  # No loop.run_forever()!

----------
assignee: yselivanov
components: asyncio
messages: 308256
nosy: asvetlov, lukasz.langa, yselivanov
priority: normal
severity: normal
status: open
title: Implement asyncio.run()
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32314>
_______________________________________

From report at bugs.python.org  Wed Dec 13 17:11:11 2017
From: report at bugs.python.org (Martin)
Date: Wed, 13 Dec 2017 22:11:11 +0000
Subject: [New-bugs-announce] [issue32315] can't run any scripts with 2.7.x,
 32 and 64-bit
Message-ID: <1513203071.76.0.213398074469.issue32315@psf.upfronthosting.co.za>


New submission from Martin <mdelija92 at gmail.com>:

When I try to run a really simple script like:
def fun(a):
    print a
    return

I get this error:

Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python27\lib\lib-tk\Tkinter.py", line 1541, in __call__
    return self.func(*args)
  File "C:\Python27\lib\idlelib\MultiCall.py", line 166, in handler
    r = l[i](event)
  File "C:\Python27\lib\idlelib\ScriptBinding.py", line 149, in run_module_event

    if PyShell.use_subprocess:
AttributeError: 'module' object has no attribute 'use_subprocess'

It basically means Python is only usable by copy-pasting code into Shell, any kind of script fails with that error.

----------
components: Library (Lib)
messages: 308260
nosy: DoctorEvil
priority: normal
severity: normal
status: open
title: can't run any scripts with 2.7.x, 32 and 64-bit
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32315>
_______________________________________

From report at bugs.python.org  Wed Dec 13 17:32:34 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Dec 2017 22:32:34 +0000
Subject: [New-bugs-announce] [issue32316] [3.6] make regen-all fails on
 Travis CI on "python3.6" command
Message-ID: <1513204354.33.0.213398074469.issue32316@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

The cpython job of Travis CI compiles Python with clang and then run "make regen-all" which fails.

"make regen-all" fails for example on regen-typeslots which runs "$(PYTHON_FOR_REGEN) ...". On Travis CI, $(PYTHON_FOR_REGEN) is "python3.6", but running python3.6 fails with:

"""
The `python3.6' command exists in these Python versions:
  3.6
  3.6.3
"""

Example of failed build:
https://travis-ci.org/python/cpython/jobs/315978517

----------
components: Build
messages: 308262
nosy: brett.cannon, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: [3.6] make regen-all fails on Travis CI on "python3.6" command
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32316>
_______________________________________

From report at bugs.python.org  Wed Dec 13 18:27:44 2017
From: report at bugs.python.org (Garrett Berg)
Date: Wed, 13 Dec 2017 23:27:44 +0000
Subject: [New-bugs-announce] [issue32317] sys.exc_clear() clears exception
 in other stack frames
Message-ID: <1513207664.32.0.213398074469.issue32317@psf.upfronthosting.co.za>


New submission from Garrett Berg <googberg at gmail.com>:

# Summary
In python (2 or 3) it should always be valid to have a bare *raise* statement in an exception block.

    try:
        do_something()
    except SomeException:
        do_cleanup()
        raise # always reraises SomeException with original stack trace

You can see this in the python exception documentation:
https://docs.python.org/2.7/tutorial/errors.html#raising-exceptions


# Reproduction of Failure of invariants
Example python file where this doesn't work:

    from __future__ import print_function

    import sys

    def doclear():
        """This should basically be a noop"""
        sys.exc_clear()

    try:
        1/0
    except ZeroDivisionError:
        exc = sys.exc_info()[0]
        print("first exc:", exc)
        assert exc is ZeroDivisionError

    try:
        1/0
    except ZeroDivisionError:
        exc = sys.exc_info()[0]
        print("second exc (before doclear):", exc)
        doclear()
        exc = sys.exc_info()[0]
        print("second exc (after  doclear):", exc)
        assert sys.exc_info()[0] is ZeroDivisionError  # fails


Running in python2.7 gives:

    first exc: <type 'exceptions.ZeroDivisionError'>
    second exc (before doclear): <type 'exceptions.ZeroDivisionError'>
    second exc (after  doclear): None
    Traceback (most recent call last):
      File "doclear.py", line 23, in <module>
        assert sys.exc_info()[0] is ZeroDivisionError  # fails
    AssertionError


# Conclusion
There seems to be a bug in python 2.7 where it doesn't follow it's own spec.
[sys.exc_clear()](https://docs.python.org/2/library/sys.html#sys.exc_clear)
states:

> This function clears all information relating to the current or last
> exception that occurred in the current thread. After calling this function,
> exc_info() will return three None values until another exception is raised in
> the current thread or *the execution stack returns to a frame where another
> exception is being handled*.

The above code is clear example where sys.exc_clear() is changing the value of
sys.exc_info() *in a different stack frame*, which is against what is stated in
the above docs.

This bug makes it impossible to reraise with a bare raise statement when doing
cleanup that could use sys.exc_clear(). In other words, calling into functions
can *change your local state* with regards to what exception is being handled.

----------
components: Interpreter Core
messages: 308264
nosy: Garrett Berg
priority: normal
severity: normal
status: open
title: sys.exc_clear() clears exception in other stack frames
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32317>
_______________________________________

From report at bugs.python.org  Wed Dec 13 23:30:55 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 14 Dec 2017 04:30:55 +0000
Subject: [New-bugs-announce] [issue32318] Remove "globals()" call from
 "socket.accept()"
Message-ID: <1513225855.23.0.213398074469.issue32318@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy: yselivanov
priority: normal
severity: normal
status: open
title: Remove "globals()" call from "socket.accept()"

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32318>
_______________________________________

From report at bugs.python.org  Thu Dec 14 02:56:47 2017
From: report at bugs.python.org (Daniel Hrisca)
Date: Thu, 14 Dec 2017 07:56:47 +0000
Subject: [New-bugs-announce] [issue32319] re fullmatch error with non greedy
 modifier
Message-ID: <1513238207.94.0.213398074469.issue32319@psf.upfronthosting.co.za>


New submission from Daniel Hrisca <daniel.hrisca at gmail.com>:

Consider this code snippet:


from re import match, fullmatch

pattern = '".+?"'
string = '"hello" "again"'

print(match(pattern, string))
print(fullmatch(pattern, string))


Which prints:
<_sre.SRE_Match object; span=(0, 7), match='"hello"'>
<_sre.SRE_Match object; span=(0, 15), match='"hello" "again"'>

The fullmatch function seems to ignore the non-greedy modifier.

>From the fullmatch docstring I expected that fullmatch is equivalent to:

def fullmatch(pattern, string):
    match = re.match(pattern, string)
    if match:
        if match.start() == 0 and match.end() == len(string):
            return match
        else:
            return None
    else:
        return None

----------
components: Library (Lib)
messages: 308278
nosy: danielhrisca
priority: normal
severity: normal
status: open
title: re fullmatch error with non greedy modifier
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32319>
_______________________________________

From report at bugs.python.org  Thu Dec 14 03:44:35 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 14 Dec 2017 08:44:35 +0000
Subject: [New-bugs-announce] [issue32320] Add default value support to
 collections.namedtuple()
Message-ID: <1513241075.07.0.213398074469.issue32320@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Add default argument support and _fields_defaults attribute modeled after typing.NamedTuple.

----------
components: Library (Lib)
messages: 308282
nosy: rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Add default value support to collections.namedtuple()
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32320>
_______________________________________

From report at bugs.python.org  Thu Dec 14 08:26:34 2017
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 14 Dec 2017 13:26:34 +0000
Subject: [New-bugs-announce] [issue32321] functools.reduce has a redundant
 guard or needs a pure Python fallback
Message-ID: <1513257994.59.0.213398074469.issue32321@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve+python at pearwood.info>:

The functools module imports reduce from _functools, using a guard in case it is not present:

try:
    from _functools import reduce
except ImportError:
    pass


However, the documentation says nothing about reduce being optional, and it is unconditionally included in the module __all__.

If reduce is guaranteed to be implemented in _functools, then the guard is redundant and should be removed. Otherwise, a pure python fallback should be added.

(The docs for reduce include a pure Python equivalent which might be sufficient.)

----------
components: Library (Lib)
keywords: easy
messages: 308297
nosy: steven.daprano
priority: normal
severity: normal
status: open
title: functools.reduce has a redundant guard or needs a pure Python fallback
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32321>
_______________________________________

From report at bugs.python.org  Thu Dec 14 09:44:08 2017
From: report at bugs.python.org (Rostislav Kondratenko)
Date: Thu, 14 Dec 2017 14:44:08 +0000
Subject: [New-bugs-announce] [issue32322] Heap type with Py_TPFLAGS_HAVE_GC
 leads to segfault due to not incrementing type object refcout in
 PyObject_GC_New
Message-ID: <1513262648.0.0.213398074469.issue32322@psf.upfronthosting.co.za>


New submission from Rostislav Kondratenko <grostik at gmail.com>:

If one creates a type with both Py_TPFLAGS_HAVE_GC and Py_TPFLAGS_HEAPTYPE set and implemented, one has to create instances with PyObject_GC_New() per current docs: https://docs.python.org/3.7/c-api/gcsupport.html .

However, PyObject_GC_New() unlike PyType_GenericAlloc() does not increment refcount of a type object. As the refcount is still decremented when instances are destroyed, it leads to steady drain on type object's refcount. Eventually it reaches zero and the type object gets deleted while there are still instances and references to it. And it usually results in crash after a number of instances (20-50 is usually enough) is created and destroyed.

One should either update the docs to point that call to PyType_GenericAlloc() would be sufficient (as it would use _PyObject_GC_Malloc() and increment refcount when appropriate) or update _PyObject_GC_New() code to increment type object's refcount when the type is heap type. Or both.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 308302
nosy: docs at python, rkond
priority: normal
severity: normal
status: open
title: Heap type with Py_TPFLAGS_HAVE_GC leads to segfault due to not incrementing type object refcout in PyObject_GC_New
type: crash
versions: Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32322>
_______________________________________

From report at bugs.python.org  Thu Dec 14 10:30:39 2017
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Thu, 14 Dec 2017 15:30:39 +0000
Subject: [New-bugs-announce] [issue32323] urllib.parse.urlsplit() must not
 lowercase() IPv6 scope value
Message-ID: <1513265439.83.0.213398074469.issue32323@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

qwe = urlsplit('http://[FE80::822a:a8ff:fe49:470c%????]:1234/keys')
qwe.hostname will be 'fe80::822a:a8ff:fe49:470c%????'

Which is wrong.

correct value is

'fe80::822a:a8ff:fe49:470c%????'

so, IP-address is lowercased and zone id does not.

----------
components: Library (Lib)
messages: 308306
nosy: socketpair
priority: normal
severity: normal
status: open
title: urllib.parse.urlsplit() must not lowercase() IPv6 scope value
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32323>
_______________________________________

From report at bugs.python.org  Thu Dec 14 11:09:15 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Dec 2017 16:09:15 +0000
Subject: [New-bugs-announce] [issue32324] [Security] "python3 directory"
 inserts "directory" at sys.path[0] even in isolated mode
Message-ID: <1513267755.86.0.213398074469.issue32324@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

Christian Heimes, author of the -I option (isolated mode), asked me to open an issue to check if the following behaviour is correct (safe in term of security).

"python3 directory" inserts "directory" at sys.path[0], even in isolated mode. Example:
---
vstinner at apu$ mkdir directory
vstinner at apu$ echo "import pprint, sys; pprint.pprint(sys.path)" > directory/__main__.py

vstinner at apu$ python3 directory
['directory',
 '/usr/lib64/python3.6',
 ...]

# Same behaviour with -I
vstinner at apu$ python3 -I directory
['directory',
 '/usr/lib64/python3.6',
 ...]
---


Same behaviour for a ZIP file:
---
vstinner at apu$ cd directory/
vstinner at apu$ zip ../testzip.zp __main__.py 
  adding: __main__.py (deflated 20%)
vstinner at apu$ cd ..
vstinner at apu$ python3 testzip.zip
python3: can't open file 'testzip.zip': [Errno 2] No such file or directory
vstinner at apu$ mv testzip.zp testzip.zip 
'testzip.zp' -> 'testzip.zip'

vstinner at apu$ python3 testzip.zip
['testzip.zip',
 '/usr/lib64/python3.6',
 ...]

# Same behaviour with -I
vstinner at apu$ python3 -I testzip.zip
['testzip.zip',
 '/usr/lib64/python3.6',
 ...]
---

The -I option:
https://docs.python.org/dev/using/cmdline.html#id2

----------
messages: 308310
nosy: steve.dower, vstinner
priority: normal
severity: normal
status: open
title: [Security] "python3 directory" inserts "directory" at sys.path[0] even in isolated mode
type: security
versions: Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32324>
_______________________________________

From report at bugs.python.org  Thu Dec 14 11:32:21 2017
From: report at bugs.python.org (Stephen Kelly)
Date: Thu, 14 Dec 2017 16:32:21 +0000
Subject: [New-bugs-announce] [issue32325] C API should use 'const char *'
 instead of 'char *'
Message-ID: <1513269141.75.0.213398074469.issue32325@psf.upfronthosting.co.za>


New submission from Stephen Kelly <steveire at gmail.com>:

When using C++ to extend python, one may use PyGetSetDef for example:


static PyGetSetDef Noddy_getseters[] = {
    {"first",
     (getter)Noddy_getfirst, (setter)Noddy_setfirst,
     "first name",
     NULL},
    {"last",
     (getter)Noddy_getlast, (setter)Noddy_setlast,
     "last name",
     NULL},
    {NULL}  /* Sentinel */
};

However, in C++ implicit conversion from const char* to char* is deprecated since C++98, and is a removed conversion in C++11.

 https://godbolt.org/g/sswUKM

GCC/Clang warn about this, and MSVC in conformance mode (/permissive-) errors on it.

PyGetSetDef and similar APIs should use const char* instead of char* for members such as `name`.

----------
components: Library (Lib)
messages: 308316
nosy: steveire
priority: normal
severity: normal
status: open
title: C API should use 'const char *' instead of 'char *'
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32325>
_______________________________________

From report at bugs.python.org  Thu Dec 14 15:25:55 2017
From: report at bugs.python.org (Decorater)
Date: Thu, 14 Dec 2017 20:25:55 +0000
Subject: [New-bugs-announce] [issue32326] Update Build projects to version
 10.0.16299.0 of the Windows 10 SDK.
Message-ID: <1513283155.41.0.213398074469.issue32326@psf.upfronthosting.co.za>


New submission from Decorater <seandhunt_7 at yahoo.com>:

It seems that When I uninstalled an older version of the Windows 10 SDK to make more disk space to update Visual Studio that now python 3.6 will not compile. I am not sure if Python 3.7 on master currently has this issue or not though I still have not tested it on 3.7 either.

I am using Visual Studio 2017 to Compile the latest commit on branch 3.6. I could technically use branch master if the issue with Py_DecodeLocale() is fixed yet though.

----------
messages: 308333
nosy: Decorater
priority: normal
severity: normal
status: open
title: Update Build projects to version 10.0.16299.0 of the Windows 10 SDK.
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32326>
_______________________________________

From report at bugs.python.org  Thu Dec 14 15:58:58 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 14 Dec 2017 20:58:58 +0000
Subject: [New-bugs-announce] [issue32327] Make asyncio methods documented as
 coroutines - coroutines.
Message-ID: <1513285138.55.0.213398074469.issue32327@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

There's a handful of event loop methods that are currently documented as coroutines, but in reality they return asyncio.Future:

* loop.sock_sendall, 
* loop.sock_accept, 
* loop.sock_recv, and 
* loop.run_in_executor.

These methods need to become proper coroutines beacause:

1. loop.create_task(loop.sock_recv(..)) fails with a cryptic error.

2. It's harder for us to refactor the code keeping these functions as regular functions returning Futures.  Once asyncio was broken because of the bug in loop.sock_connect() because of a complex refactoring.  After we converted it to a coroutine in 3.6, we received 0 complaints, but the code became simpler.

3. It's easier to read the source code of asyncio, when all methods that are documented as coroutines are actually coroutines.

4. This downgrades the role of 'asyncio.ensure_future()' function.  Basically, when a user needs a task, they can now use create_task() (which won't fail on some "coroutines" sometimes).  asyncio users will be advised to design APIs in their programs and libraries around async/await and not Future objects.

----------
assignee: yselivanov
components: asyncio
messages: 308339
nosy: yselivanov
priority: normal
severity: normal
status: open
title: Make asyncio methods documented as coroutines - coroutines.
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32327>
_______________________________________

From report at bugs.python.org  Thu Dec 14 16:35:04 2017
From: report at bugs.python.org (Joshua Kinard)
Date: Thu, 14 Dec 2017 21:35:04 +0000
Subject: [New-bugs-announce] [issue32328] ttk.Treeview: _tkinter.TclError:
 list element in quotes followed by "; " instead of space
Message-ID: <1513287304.34.0.213398074469.issue32328@psf.upfronthosting.co.za>


New submission from Joshua Kinard <kumba at gentoo.org>:

I think I've found another bug with Tkinter's string handling in Python 2.7.14, before it passes off to the TCL interpreter when inserting items into a ttk.Treeview widget.  Specifically, it doesn't handle strings containing semi-colons very well if they are passed in via a kwarg dict.

Below is a simple test case.  The "kw" variable has a 'values' key with a string value using single quotes to store the value '" ";':

-------------------------------------------------------------------------------
from Tkinter import *
from ttk import *

root = Tk()
tv = Treeview(root, columns=("foobar",))

tv.heading("foobar", text="Foobar!")
tv.column("#0", width=0)
tv.column("foobar", stretch=True, minwidth=100, width=400)
tv.grid()

kw = {'values': '" ";', 'tags': ''}
tv.insert("", END, iid=None, **kw)

root.mainloop()
-------------------------------------------------------------------------------

This sample triggers this traceback:

Traceback (most recent call last):
  File "test.py", line 14, in <module>
    tv.insert("", END, iid=None, **kw)
  File "C:\Python27\lib\lib-tk\ttk.py", line 1339, in insert
    res = self.tk.call(self._w, "insert", parent, index, *opts)
_tkinter.TclError: list element in quotes followed by ";" instead of space


Furthermore, if the 'values' key is changed to the string 'X:"Y ";', you trigger a different traceback:

Traceback (most recent call last):
  File "test.py", line 13, in <module>
    tv.insert("", END, iid=None, **kw)
  File "C:\Python27\lib\lib-tk\ttk.py", line 1339, in insert
    res = self.tk.call(self._w, "insert", parent, index, *opts)
_tkinter.TclError: unmatched open quote in list

So definitely a case of something in the parser not handling things properly before sending to the TCL interpreter.

I suspect this is similar to Issue #15861.  One can work around this bug by checking for either a whitespace or backslash character in the string, and wrapping the string in curly braces if so, to disable TCL substitution mechanism, and it'll insert the string and display it correctly in the widget.

I have only verified this in Python 2.7.14 at the moment, which is what I primarily work in right now.

----------
components: Tkinter
messages: 308340
nosy: kumba
priority: normal
severity: normal
status: open
title: ttk.Treeview: _tkinter.TclError: list element in quotes followed by ";" instead of space
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32328>
_______________________________________

From report at bugs.python.org  Thu Dec 14 18:11:20 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Dec 2017 23:11:20 +0000
Subject: [New-bugs-announce] [issue32329] PYTHONHASHSEED=0 python3 -R should
 enable hash randomization
Message-ID: <1513293080.01.0.213398074469.issue32329@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

Python pretends that hash randomization is always enabled, but it's not:

$ PYTHONHASHSEED=0 python3 -c 'import sys; print(sys.flags.hash_randomization)'
1
vstinner at apu$ PYTHONHASHSEED=0 python3 -c 'import sys; print(hash("abc"))'
4596069200710135518
vstinner at apu$ PYTHONHASHSEED=0 python3 -c 'import sys; print(hash("abc"))'
4596069200710135518
vstinner at apu$ PYTHONHASHSEED=0 python3 -c 'import sys; print(hash("abc"))'
4596069200710135518

=> sys.flags.hash_randomization must be zero


Moreover, the -R flag is always ignored, it's not possible to override the PYTHONHASHSEED environment variable:

vstinner at apu$ PYTHONHASHSEED=0 python3 -R -c 'import sys; print(sys.flags.hash_randomization)'
1
vstinner at apu$ PYTHONHASHSEED=0 python3 -R -c 'import sys; print(hash("abc"))'
4596069200710135518
vstinner at apu$ PYTHONHASHSEED=0 python3 -R -c 'import sys; print(hash("abc"))'
4596069200710135518
vstinner at apu$ PYTHONHASHSEED=0 python3 -R -c 'import sys; print(hash("abc"))'
4596069200710135518

I expect that -R enables hash randomization and overrides PYTHONHASHSEED environment variable.

Attached PR fixes these issues and adds an unit test.

----------
messages: 308343
nosy: vstinner
priority: normal
severity: normal
status: open
title: PYTHONHASHSEED=0 python3 -R should enable hash randomization
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32329>
_______________________________________

From report at bugs.python.org  Thu Dec 14 19:25:27 2017
From: report at bugs.python.org (Mark Sapiro)
Date: Fri, 15 Dec 2017 00:25:27 +0000
Subject: [New-bugs-announce] [issue32330] Email parser creates a message
 object that can't be flattened
Message-ID: <1513297527.86.0.213398074469.issue32330@psf.upfronthosting.co.za>


New submission from Mark Sapiro <mark at msapiro.net>:

This is related to https://bugs.python.org/issue27321 but a different exception is thrown for a different reason. This is caused by a defective spam message. I don't actually have the offending message from the wild, but the attached bad_email_2.eml illustrates the problem.

The defect is the message declares the content charset as us-ascii, but the body contains non-ascii. When the message is parsed into an email.message.Message object and the objects as_string() method is called, UnicodeEncodeError is thrown as follows:

>>> import email
>>> with open('bad_email_2.eml', 'rb') as fp:
...     msg = email.message_from_binary_file(fp)
... 
>>> msg.as_string()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/email/message.py", line 159, in as_string
    g.flatten(self, unixfrom=unixfrom)
  File "/usr/lib/python3.5/email/generator.py", line 115, in flatten
    self._write(msg)
  File "/usr/lib/python3.5/email/generator.py", line 181, in _write
    self._dispatch(msg)
  File "/usr/lib/python3.5/email/generator.py", line 214, in _dispatch
    meth(msg)
  File "/usr/lib/python3.5/email/generator.py", line 243, in _handle_text
    msg.set_payload(payload, charset)
  File "/usr/lib/python3.5/email/message.py", line 316, in set_payload
    payload = payload.encode(charset.output_charset)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 31-33: ordinal not in range(128)

----------
components: email
files: bad_email_2.eml
messages: 308353
nosy: barry, msapiro, r.david.murray
priority: normal
severity: normal
status: open
title: Email parser creates a message object that can't be flattened
type: behavior
versions: Python 3.5, Python 3.6
Added file: https://bugs.python.org/file47333/bad_email_2.eml

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32330>
_______________________________________

From report at bugs.python.org  Thu Dec 14 22:42:49 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 15 Dec 2017 03:42:49 +0000
Subject: [New-bugs-announce] [issue32331] apply SOCK_TYPE_MASK to
 socket.type on Linux
Message-ID: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

On Linux, socket type is both a socket type and a bit mask (of SOCK_CLOEXEC and SOCK_NONBLOCK).  Therefore, anyone who write code like 'if sock.type == SOCK_STREAM' writes non-portable code, that occasionally breaks on Linux.  

This caused some hard to spot bugs in asyncio already: https://bugs.python.org/issue27456  -- this one was discovered only 1 year after the actual change.

On Linux, in 'include/linux/net.h' there's a SOCK_TYPE_MASK macro defined to 0xF.  The idea is that on Linux you should mask socket type before comparing it to SOCK_STREAM or other socket types.

Using socket.SOCK_NONBLOCK on Python was always error-prone even if one targets only Linux.  For instance, socket.type won't be updated to include SOCK_NONBLOCK if the socket was updated via ioctl call directly.

Therefore, I propose to fix socket.type getter to always (on Linux) apply that mask in Python.

----------
components: Library (Lib)
messages: 308363
nosy: asvetlov, inada.naoki, pitrou, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: apply SOCK_TYPE_MASK to socket.type on Linux
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32331>
_______________________________________

From report at bugs.python.org  Fri Dec 15 01:47:42 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 15 Dec 2017 06:47:42 +0000
Subject: [New-bugs-announce] [issue32332] Implement slots support for magic
 methods added in PEP 560
Message-ID: <1513320462.57.0.213398074469.issue32332@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

I propose to add type slots for magic methods introduced by PEP 560.  In the brief discussion on the mailing list Guido OK'd the idea: https://mail.python.org/pipermail/python-dev/2017-December/151262.html

I'll submit a PR that implements this proposal by adding new 'tp_as_class' slot, that points to a PyClassMethods struct, that has two fields: `cm_getitem` and `cm_mro_entries`.

Interestingly, when __class_getitem__ is implemented through the type/slots machinery it becomes a bit faster.  Given the following microbenchmark:

    class Foo:
        def __class_getitem__(cls, o):
            return o

    for _ in range(3):
        t = time.monotonic()
        for i in range(10 ** 8):
            assert i == Foo[i]
        print(f'{time.monotonic() - t:.3f}s')

I see these numbers for the master branch:

17.161s
17.024s
16.530s

and these for the C-slots branch:

15.010s
15.693s
15.035s

----------
components: Interpreter Core
messages: 308365
nosy: gvanrossum, levkivskyi, pitrou, yselivanov
priority: normal
severity: normal
status: open
title: Implement slots support for magic methods added in PEP 560
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32332>
_______________________________________

From report at bugs.python.org  Fri Dec 15 09:41:19 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Dec 2017 14:41:19 +0000
Subject: [New-bugs-announce] [issue32333] test_smtplib: dangling threads on
 x86 Gentoo Non-Debug with X 3.x
Message-ID: <1513348879.75.0.213398074469.issue32333@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

http://buildbot.python.org/all/#/builders/99/builds/363

0:00:16 load avg: 2.60 [ 12/412/1] test_smtplib failed (env changed)
testFailingHELO (test.test_smtplib.BadHELOServerTests) ... ok
(...)
testLineTooLong (test.test_smtplib.TooLongLineTests) ... ok

----------------------------------------------------------------------
Ran 54 tests in 1.828s

OK (skipped=1)
Warning -- threading_cleanup() failed to cleanup 0 threads (count: 0, dangling: 3)
Dangling thread: <_MainThread(MainThread, started 3075602176)>
Dangling thread: <Thread(Thread-19, stopped 3053071168)>
Dangling thread: <Thread(Thread-20, stopped 3053071168)>

----------
components: Tests
messages: 308396
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_smtplib: dangling threads on x86 Gentoo Non-Debug with X 3.x
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32333>
_______________________________________

From report at bugs.python.org  Fri Dec 15 09:45:07 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Dec 2017 14:45:07 +0000
Subject: [New-bugs-announce] [issue32334] test_configparser left
 @test_2876_tmp temporary file on x86 Windows7 3.x
Message-ID: <1513349107.71.0.213398074469.issue32334@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

http://buildbot.python.org/all/#/builders/58/builds/332

running: test_multiprocessing_spawn (901 sec), test_concurrent_futures (151 sec)
0:47:16 [250/413/1] test_multiprocessing_spawn crashed (Exit code 1) -- running: test_concurrent_futures (154 sec)
Timeout (0:15:00)!
Thread 0x00000238 (most recent call first):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\popen_spawn_win32.py", line 80 in wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\process.py", line 140 in join
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 2128 in join_thread
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\_test_multiprocessing.py", line 83 in join_process
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\_test_multiprocessing.py", line 740 in test_sys_exit
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 615 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 663 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\runner.py", line 176 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1861 in _run_suite
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1951 in run_unittest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 175 in test_runner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 176 in runtest_inner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 130 in runtest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest_mp.py", line 67 in run_tests_slave
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 517 in _main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 510 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 585 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", line 46 in _main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", line 50 in <module>
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 85 in _run_code
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 193 in _run_module_as_main
0:47:21 [251/413/1] test_timeit passed -- running: test_concurrent_futures (159 sec)
(...)
0:54:34 [295/413/1] test_tempfile passed -- running: test_mmap (238 sec)
minkernel\crts\ucrt\src\appcrt\lowio\write.cpp(49) : Assertion failed: (_osfile(fh) & FOPEN)
0:54:39 [296/413/2] test_configparser failed (env changed) -- running: test_mmap (243 sec)
D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py:1000: RuntimeWarning: tests may fail, unable to create temporary directory 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows7\\build\\build\\test_python_2876': [WinError 183] Cannot create a file when that file already exists: 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows7\\build\\build\\test_python_2876'
  with temp_dir(path=name, quiet=quiet) as temp_path:
test_converters_at_init (test.test_configparser.BlatantOverrideConvertersTestCase) ... ok
(...)
test_write (test.test_configparser.StrictTestCase) ... ok

----------------------------------------------------------------------
Ran 341 tests in 3.745s

OK (skipped=5)
Warning -- files was modified by test_configparser
  Before: ['@test_2876_tmp']
  After:  []

----------
components: Tests
messages: 308398
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_configparser left @test_2876_tmp temporary file on x86 Windows7 3.x
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32334>
_______________________________________

From report at bugs.python.org  Fri Dec 15 12:27:34 2017
From: report at bugs.python.org (Amit Ghadge)
Date: Fri, 15 Dec 2017 17:27:34 +0000
Subject: [New-bugs-announce] [issue32335] Failed Python build on Fedora 27
Message-ID: <1513358854.45.0.213398074469.issue32335@psf.upfronthosting.co.za>


New submission from Amit Ghadge <amitg.b14 at gmail.com>:

Hi, I'm try to build Python from source on Fedora 27 but it shows below message and build was failed,
gcc -pthread   -Xlinker -export-dynamic -o python Programs/python.o libpython3.7dm.a -lpthread -ldl  -lutil   -lm  
gcc -pthread   -Xlinker -export-dynamic -o Programs/_testembed Programs/_testembed.o libpython3.7dm.a -lpthread -ldl  -lutil   -lm  
./python -E -S -m sysconfig --generate-posix-vars ;\
if test $? -ne 0 ; then \
	echo "generate-posix-vars failed" ; \
	rm -f ./pybuilddir.txt ; \
	exit 1 ; \
fi
Traceback (most recent call last):
  File "<frozen importlib._bootstrap>", line 1141, in _install
  File "<frozen importlib._bootstrap>", line 1133, in _setup
  File "<frozen importlib._bootstrap>", line 1100, in _builtin_from_name
ImportError: no built-in module named _thread
Fatal Python error: initimport: importlib install failed

Current thread 0x00007fefeacef600 (most recent call first):
/bin/sh: line 5: 12806 Aborted                 (core dumped) ./python -E -S -m sysconfig --generate-posix-vars
generate-posix-vars failed
make: *** [Makefile:590: pybuilddir.txt] Error 1

----------
messages: 308413
nosy: amitg-b14
priority: normal
severity: normal
status: open
title: Failed Python build on Fedora 27
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32335>
_______________________________________

From report at bugs.python.org  Fri Dec 15 13:11:24 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 15 Dec 2017 18:11:24 +0000
Subject: [New-bugs-announce] [issue32336] Save OrderedDict import in argparse
Message-ID: <1513361484.23.0.213398074469.issue32336@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Since regular dicts are now ordered by default, the OrderedDict import is no longer necessary.  Removing it will give a small boost to start-up time.

----------
assignee: bethard
components: Library (Lib)
messages: 308416
nosy: bethard, rhettinger
priority: normal
severity: normal
status: open
title: Save OrderedDict import in argparse
type: performance
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32336>
_______________________________________

From report at bugs.python.org  Fri Dec 15 13:14:10 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 15 Dec 2017 18:14:10 +0000
Subject: [New-bugs-announce] [issue32337] Dict order is now guaranteed,
 so add tests for it
Message-ID: <1513361650.47.0.213398074469.issue32337@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: rhettinger
components: Tests
nosy: rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Dict order is now guaranteed, so add tests for it
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32337>
_______________________________________

From report at bugs.python.org  Fri Dec 15 13:21:39 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Dec 2017 18:21:39 +0000
Subject: [New-bugs-announce] [issue32338] Save OrderedDict import in re
Message-ID: <1513362099.11.0.213398074469.issue32338@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Since regular dicts are now ordered by default, the OrderedDict import is no longer necessary.

----------
components: Library (Lib), Regular Expressions
messages: 308418
nosy: ezio.melotti, mrabarnett, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Save OrderedDict import in re
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32338>
_______________________________________

From report at bugs.python.org  Fri Dec 15 14:00:53 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Dec 2017 19:00:53 +0000
Subject: [New-bugs-announce] [issue32339] Make the dict type used in
 csv.DictReader configurable
Message-ID: <1513364453.6.0.213398074469.issue32339@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Since 3.6 csv.DictReader emits OrderedDicts instead of regular dicts. Since regular dicts are ordered in 3.7, this is an overkill. It would be nice to add a configuration option for a return type.

This is an easy issue.

----------
components: Library (Lib)
keywords: easy
messages: 308420
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Make the dict type used in csv.DictReader configurable
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32339>
_______________________________________

From report at bugs.python.org  Fri Dec 15 14:46:47 2017
From: report at bugs.python.org (ikram)
Date: Fri, 15 Dec 2017 19:46:47 +0000
Subject: [New-bugs-announce] [issue32340] ValueError: time data 'N/A' does
 not match format '%Y%m%d'
Message-ID: <1513367207.62.0.213398074469.issue32340@psf.upfronthosting.co.za>


New submission from ikram <infernus.kai at gmail.com>:

Traceback (most recent call last):
  File "H:\Whatsapp_Xtract_V2.2_2012-11-17\whatsapp_xtract.py", line 2453, in <module>
    main(sys.argv[1:])
  File "H:\Whatsapp_Xtract_V2.2_2012-11-17\whatsapp_xtract.py", line 1921, in main
    linkimage = findfile ("IMG", y.media_size, y.local_url, date, 2)
  File "H:\Whatsapp_Xtract_V2.2_2012-11-17\whatsapp_xtract.py", line 1266, in findfile
    timestamptoday = int(str(time.mktime(datetime.datetime.strptime(date, "%Y%m%d").timetuple()))[:-2])
  File "C:\Python27\lib\_strptime.py", line 332, in _strptime
    (data_string, format))
ValueError: time data 'N/A' does not match format '%Y%m%d'
Press any key to continue . . .

----------
components: Windows
messages: 308423
nosy: marki94, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: ValueError: time data 'N/A' does not match format '%Y%m%d'
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32340>
_______________________________________

From report at bugs.python.org  Fri Dec 15 15:50:25 2017
From: report at bugs.python.org (Stefan Pochmann)
Date: Fri, 15 Dec 2017 20:50:25 +0000
Subject: [New-bugs-announce] [issue32341] itertools "generators"?
Message-ID: <1513371025.57.0.213398074469.issue32341@psf.upfronthosting.co.za>


New submission from Stefan Pochmann <stefan.pochmann at gmail.com>:

The itertools page https://docs.python.org/3.6/library/itertools.html says "Combinatoric generators:" above the table with product(), permutations(), etc. But as far as I understand, they're not generators and they don't produce generator iterators. I think the table title should be "Combinatoric iterators:" instead, in line with "Infinite Iterators:" and "Iterators terminating on the shortest input sequence:" of the two tables above it.

Reference:
https://docs.python.org/3/glossary.html#term-generator

----------
assignee: docs at python
components: Documentation
messages: 308425
nosy: Stefan Pochmann, docs at python
priority: normal
severity: normal
status: open
title: itertools "generators"?
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32341>
_______________________________________

From report at bugs.python.org  Fri Dec 15 16:39:12 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Dec 2017 21:39:12 +0000
Subject: [New-bugs-announce] [issue32342] safe_power(): CID 1426161: Integer
 handling issues (DIVIDE_BY_ZERO)
Message-ID: <1513373952.98.0.213398074469.issue32342@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

Coverity found an issue in the commit 2e3f5701858d1fc04caedefdd9a8ea43810270d2 (bpo-30416).

New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)

** CID 1426161:  Integer handling issues  (DIVIDE_BY_ZERO)
/Python/ast_opt.c: 219 in safe_power()

________________________________________________________________________________________________________
*** CID 1426161:  Integer handling issues  (DIVIDE_BY_ZERO)
/Python/ast_opt.c: 219 in safe_power()
213         if (PyLong_Check(v) && PyLong_Check(w) && Py_SIZE(v) && Py_SIZE(w) > 0) {
214             size_t vbits = _PyLong_NumBits(v);
215             size_t wbits = PyLong_AsSize_t(w);
216             if (vbits == (size_t)-1 || wbits == (size_t)-1) {
217                 return NULL;
218             }
>>>     CID 1426161:  Integer handling issues  (DIVIDE_BY_ZERO)
>>>     In expression "128UL / wbits", division by expression "wbits" which may be zero has undefined behavior.
219             if (vbits > MAX_INT_SIZE / wbits) {
220                 return NULL;
221             }
222         }
223
224         return PyNumber_Power(v, w, Py_None);

----------
components: Interpreter Core
messages: 308428
nosy: serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: safe_power(): CID 1426161:  Integer handling issues  (DIVIDE_BY_ZERO)
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32342>
_______________________________________

From report at bugs.python.org  Fri Dec 15 23:48:19 2017
From: report at bugs.python.org (Kirit Sankar Gupta)
Date: Sat, 16 Dec 2017 04:48:19 +0000
Subject: [New-bugs-announce] [issue32343] Leak Sanitizer reports memory
 leaks while building using ASAN
Message-ID: <1513399699.11.0.213398074469.issue32343@psf.upfronthosting.co.za>


New submission from Kirit Sankar Gupta <kirit1193 at gmail.com>:

./python -E -S -m sysconfig --generate-posix-vars ;\
if test $? -ne 0 ; then \
        echo "generate-posix-vars failed" ; \
        rm -f ./pybuilddir.txt ; \
        exit 1 ; \
fi

=================================================================
==12061==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 287665 byte(s) in 116 object(s) allocated from:
    #0 0x4ef9b0 in malloc (/home/ksg/cpython/python+0x4ef9b0)
    #1 0x6411a9 in PyMem_RawMalloc /home/ksg/cpython/Objects/obmalloc.c:503:12
    #2 0x6411a9 in _PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:1560
    #3 0x6462c7 in PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:616:12

Direct leak of 5096 byte(s) in 9 object(s) allocated from:
    #0 0x4ef9b0 in malloc (/home/ksg/cpython/python+0x4ef9b0)
    #1 0x6411a9 in PyMem_RawMalloc /home/ksg/cpython/Objects/obmalloc.c:503:12
    #2 0x6411a9 in _PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:1560
    #3 0x6462c7 in PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:616:12
    #4 0x9786dd in _PyObject_GC_Malloc /home/ksg/cpython/Modules/gcmodule.c:1713:12
    #5 0x9786dd in _PyObject_GC_NewVar /home/ksg/cpython/Modules/gcmodule.c:1742

Direct leak of 2746 byte(s) in 3 object(s) allocated from:
    #0 0x4efdd5 in realloc (/home/ksg/cpython/python+0x4efdd5)
    #1 0x641828 in PyMem_RawRealloc /home/ksg/cpython/Objects/obmalloc.c:521:12
    #2 0x641828 in _PyObject_Realloc /home/ksg/cpython/Objects/obmalloc.c:1905
    #3 0x6463fd in PyObject_Realloc /home/ksg/cpython/Objects/obmalloc.c:634:12

Direct leak of 591 byte(s) in 1 object(s) allocated from:
    #0 0x4ef9b0 in malloc (/home/ksg/cpython/python+0x4ef9b0)
    #1 0x6411a9 in PyMem_RawMalloc /home/ksg/cpython/Objects/obmalloc.c:503:12
    #2 0x6411a9 in _PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:1560
    #3 0x6462c7 in PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:616:12
    #4 0x8dace5 in r_object /home/ksg/cpython/Python/marshal.c:1392:20
    #5 0x8d8780 in r_object /home/ksg/cpython/Python/marshal.c:1224:18
    #6 0x8dad1c in r_object /home/ksg/cpython/Python/marshal.c:1395:22
    #7 0x8d8780 in r_object /home/ksg/cpython/Python/marshal.c:1224:18
    #8 0x8dad1c in r_object /home/ksg/cpython/Python/marshal.c:1395:22
    #9 0x8d3e1d in PyMarshal_ReadObjectFromString /home/ksg/cpython/Python/marshal.c:1598:14
    #10 0x8bffa6 in get_frozen_object /home/ksg/cpython/Python/import.c:1258:12
    #11 0x8bffa6 in _imp_get_frozen_object_impl /home/ksg/cpython/Python/import.c:2018
    #12 0x8bffa6 in _imp_get_frozen_object /home/ksg/cpython/Python/clinic/import.c.h:176
    #13 0x568e15 in _PyMethodDef_RawFastCallDict /home/ksg/cpython/Objects/call.c:497:18
    #14 0x56772b in _PyCFunction_FastCallDict /home/ksg/cpython/Objects/call.c:582:14
    #15 0x56772b in PyCFunction_Call /home/ksg/cpython/Objects/call.c:787

Direct leak of 560 byte(s) in 1 object(s) allocated from:
    #0 0x4ef9b0 in malloc (/home/ksg/cpython/python+0x4ef9b0)
    #1 0x641900 in PyMem_RawMalloc /home/ksg/cpython/Objects/obmalloc.c:503:12
    #2 0x641900 in _PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:1560
    #3 0x641900 in pymalloc_realloc /home/ksg/cpython/Objects/obmalloc.c:1882
    #4 0x641900 in _PyObject_Realloc /home/ksg/cpython/Objects/obmalloc.c:1901
    #5 0x6463fd in PyObject_Realloc /home/ksg/cpython/Objects/obmalloc.c:634:12

Direct leak of 2 byte(s) in 2 object(s) allocated from:
    #0 0x4ef9b0 in malloc (/home/ksg/cpython/python+0x4ef9b0)
    #1 0x6411a9 in PyMem_RawMalloc /home/ksg/cpython/Objects/obmalloc.c:503:12
    #2 0x6411a9 in _PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:1560
    #3 0x645e07 in PyMem_Malloc /home/ksg/cpython/Objects/obmalloc.c:536:12

Indirect leak of 28768 byte(s) in 31 object(s) allocated from:
    #0 0x4ef9b0 in malloc (/home/ksg/cpython/python+0x4ef9b0)
    #1 0x6411a9 in PyMem_RawMalloc /home/ksg/cpython/Objects/obmalloc.c:503:12
    #2 0x6411a9 in _PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:1560
    #3 0x6462c7 in PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:616:12
    #4 0x67ab2a in PyType_GenericAlloc /home/ksg/cpython/Objects/typeobject.c:969:15

Indirect leak of 8028 byte(s) in 8 object(s) allocated from:
    #0 0x4ef9b0 in malloc (/home/ksg/cpython/python+0x4ef9b0)
    #1 0x6411a9 in PyMem_RawMalloc /home/ksg/cpython/Objects/obmalloc.c:503:12
    #2 0x6411a9 in _PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:1560
    #3 0x6462c7 in PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:616:12

Indirect leak of 2571 byte(s) in 2 object(s) allocated from:
    #0 0x4ef9b0 in malloc (/home/ksg/cpython/python+0x4ef9b0)
    #1 0x6411a9 in PyMem_RawMalloc /home/ksg/cpython/Objects/obmalloc.c:503:12
    #2 0x6411a9 in _PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:1560
    #3 0x6462c7 in PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:616:12
    #4 0x68d0b6 in type_call /home/ksg/cpython/Objects/typeobject.c:928:11
    #5 0x569c86 in _PyMethodDef_RawFastCallKeywords /home/ksg/cpython/Objects/call.c:656:18

Indirect leak of 2096 byte(s) in 3 object(s) allocated from:
    #0 0x4ef9b0 in malloc (/home/ksg/cpython/python+0x4ef9b0)
    #1 0x6411a9 in PyMem_RawMalloc /home/ksg/cpython/Objects/obmalloc.c:503:12
    #2 0x6411a9 in _PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:1560
    #3 0x6462c7 in PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:616:12
    #4 0x9786dd in _PyObject_GC_Malloc /home/ksg/cpython/Modules/gcmodule.c:1713:12
    #5 0x9786dd in _PyObject_GC_NewVar /home/ksg/cpython/Modules/gcmodule.c:1742

Indirect leak of 632 byte(s) in 1 object(s) allocated from:
    #0 0x4ef9b0 in malloc (/home/ksg/cpython/python+0x4ef9b0)
    #1 0x641900 in PyMem_RawMalloc /home/ksg/cpython/Objects/obmalloc.c:503:12
    #2 0x641900 in _PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:1560
    #3 0x641900 in pymalloc_realloc /home/ksg/cpython/Objects/obmalloc.c:1882
    #4 0x641900 in _PyObject_Realloc /home/ksg/cpython/Objects/obmalloc.c:1901
    #5 0x6463fd in PyObject_Realloc /home/ksg/cpython/Objects/obmalloc.c:634:12

SUMMARY: AddressSanitizer: 338755 byte(s) leaked in 177 allocation(s).
generate-posix-vars failed
Makefile:589: recipe for target 'pybuilddir.txt' failed
make: *** [pybuilddir.txt] Error 1

----------
components: Build
messages: 308452
nosy: kirit1193
priority: normal
severity: normal
status: open
title: Leak Sanitizer reports memory leaks while building using ASAN
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32343>
_______________________________________

From report at bugs.python.org  Sat Dec 16 04:04:09 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 16 Dec 2017 09:04:09 +0000
Subject: [New-bugs-announce] [issue32344] Explore whether peephole.c tuple
 of constants folding can be an AST transformation
Message-ID: <1513415049.96.0.213398074469.issue32344@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Can the peephole optimizer's fold_tuple_on_constants() be moved to ast_opt?

It looks to me like there is sufficient information in the tree:


import ast
print(ast.dump(ast.parse('c = (50+1, 60+2)')))
-----------------------------------------------
Module(body=[Assign(targets=[Name(id='c', ctx=Store())],
                    value=Tuple(elts=[BinOp(left=Num(n=50), op=Add(), right=Num(n=1)),
                                      BinOp(left=Num(n=60), op=Add(), right=Num(n=2))], ctx=Load()))],
       docstring=None)
'''

----------
assignee: serhiy.storchaka
components: Interpreter Core
messages: 308467
nosy: inada.naoki, rhettinger, serhiy.storchaka, vstinner
priority: low
severity: normal
status: open
title: Explore whether peephole.c tuple of constants folding can be an AST transformation
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32344>
_______________________________________

From report at bugs.python.org  Sat Dec 16 04:28:32 2017
From: report at bugs.python.org (Creideiki)
Date: Sat, 16 Dec 2017 09:28:32 +0000
Subject: [New-bugs-announce] [issue32345] EIO from write() is only fatal if
 print() contains a newline
Message-ID: <1513416512.67.0.213398074469.issue32345@psf.upfronthosting.co.za>


New submission from Creideiki <creideiki+pythonbugs at ferretporn.se>:

This is Python 2.7.14 on Gentoo Linux.

I ran into an issue where a program crashes if I run it from a terminal, put it in the background, and then close the terminal too soon. Upstream bug report: https://github.com/micahflee/torbrowser-launcher/issues/298

It seems the cause is that a print() call without a newline ignores the EIO returned by the write() syscall, but if there is a newline in the string, that EIO is suddenly a fatal error.

Reproducer:

$ cat fatal.py 
#!/bin/env python2.7
import time
time.sleep(5)
print('A')
print('B\nC')
print('D')

Run this program in the background under strace to see what it does, and while it is sleeping, close its controlling terminal:

$ strace -s 256 -o fatal.log -f ./fatal.py &
[1] 17974
^d

Now look at the strace log:

$ grep write fatal.log
17978 write(1, "A\n", 2)                = -1 EIO (Input/output error)
17978 write(1, "B\n", 2)                = -1 EIO (Input/output error)
17978 write(2, "Traceback (most recent call last):\n", 35) = -1 EIO (Input/output error)
17978 write(2, "  File \"./fatal.py\", line 5, in <module>\n", 41) = -1 EIO (Input/output error)
17978 write(2, "    ", 4)               = -1 EIO (Input/output error)
17978 write(2, "print('B\\nC')\n", 14)  = -1 EIO (Input/output error)
17978 write(2, "IOError", 7)            = -1 EIO (Input/output error)
17978 write(2, ": ", 2)                 = -1 EIO (Input/output error)
17978 write(2, "[Errno 5] Input/output error", 28) = -1 EIO (Input/output error)
17978 write(2, "\n", 1)                 = -1 EIO (Input/output error)

The first print('A') ran and had an EIO error, which was ignored. The second print('B\nC') tried to write 'B', had an EIO error, and crashed. The third print('D') was never attempted.

----------
components: IO
messages: 308468
nosy: Creideiki
priority: normal
severity: normal
status: open
title: EIO from write() is only fatal if print() contains a newline
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32345>
_______________________________________

From report at bugs.python.org  Sat Dec 16 07:21:18 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Dec 2017 12:21:18 +0000
Subject: [New-bugs-announce] [issue32346] Speed up slot lookup for class
 creation
Message-ID: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

As mentioned in https://mail.python.org/pipermail/python-dev/2017-December/151298.html, slot lookup can take 75 to 80% of the runtime when creating a new class.  This was slightly improved in https://bugs.python.org/issue31336 but we're still doing one lookup per possible slot name *and* per class along the MRO.

I propose to speed up this step by caching the known descriptors for each class.  This way, when instantiating a new class, you can simply iterate over the known descriptors of the MRO without wasting time on hundreds of dict lookups.

(and it is reasonably easy to find all slot descriptors in a dict: first select only __dunder__ names, then look them up in a dedicated mapping)

----------
components: Interpreter Core
messages: 308474
nosy: pitrou, scoder, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Speed up slot lookup for class creation
type: performance
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32346>
_______________________________________

From report at bugs.python.org  Sat Dec 16 11:45:01 2017
From: report at bugs.python.org (Ryan Govostes)
Date: Sat, 16 Dec 2017 16:45:01 +0000
Subject: [New-bugs-announce] [issue32347] System Integrity Protection breaks
 shutil.copystat()
Message-ID: <1513442701.16.0.213398074469.issue32347@psf.upfronthosting.co.za>


New submission from Ryan Govostes <rgovostes+python at gmail.com>:

On macOS, shutil.copystat() uses chflags() to try to copy filesystem flags from the source to destination.

In recent years, Apple introduced System Integrity Protection, which prevents modification of system files. These files have the non-standard SF_RESTRICTED flag set, which only the superuser can set.

Thus, unprivileged users can no longer use shutil.copy2() et al. to copy system files, which is a regression from previous releases of the OS.

It's unclear what the correct behavior should be: It some cases, it would be desirable to attempt to copy the bit.

It might be informative to look at the behavior of Apple's `copyfile_stat` function, which unsets these two flags:

   /*
    * File flags that are not preserved when copying stat information.
    */
   #define COPYFILE_OMIT_FLAGS 	(UF_TRACKED | SF_RESTRICTED)

https://opensource.apple.com/source/copyfile/copyfile-146/copyfile.c.auto.html

This was also filed to Apple as rdar://36090921

----------
components: macOS
messages: 308479
nosy: Ryan Govostes, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: System Integrity Protection breaks shutil.copystat()
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32347>
_______________________________________

From report at bugs.python.org  Sat Dec 16 18:50:13 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 16 Dec 2017 23:50:13 +0000
Subject: [New-bugs-announce] [issue32348] Optimize asyncio.Future
 schedule/add/remove callback
Message-ID: <1513468213.29.0.213398074469.issue32348@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

Key observation: 99.9% of the time Futures and Tasks have only one callback.  

Currently we have a list of callbacks in each Future/Task.  We can avoid list object allocation if we add a field to store the first callback.  This way we'll only need to ever allocate the list if a Future/Task has more than one done callbacks.

asyncio with the proposed patch applied shows that 3-6% better performance of an asyncio echo server implemented using asyncio.streams.  This benchmark involves quite a bit of other Python code, so this improvement is actually quite significant.

The patch consists of:

1. first callback / callbacks list refactoring.

2. a free list implementation for Future.__await__ objects (which are created on almost all awaits in asyncio).

3. a big cleanup of the code, ensuring that Future/Task are always initialized properly.

----------
assignee: yselivanov
components: asyncio
messages: 308481
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Optimize asyncio.Future schedule/add/remove callback
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32348>
_______________________________________

From report at bugs.python.org  Sun Dec 17 00:29:21 2017
From: report at bugs.python.org (=?utf-8?b?7JaR7Jyg7ISd?=)
Date: Sun, 17 Dec 2017 05:29:21 +0000
Subject: [New-bugs-announce] [issue32349] Add detailed return value
 information for set.intersection function
Message-ID: <1513488561.11.0.213398074469.issue32349@psf.upfronthosting.co.za>


New submission from ??? <ileixe at gmail.com>:

I think it's intentional behavior seems to be minor though.

At a glance, I assume that a.set(b) should return items in a. But I found out the implementation always return items in smaller set.

There is no issue for common case, but custom class can make a trouble. So, I think additional information of return value is helpful.

----------
assignee: docs at python
components: Documentation
messages: 308484
nosy: docs at python, ???
priority: normal
severity: normal
status: open
title: Add detailed return value information for set.intersection function
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32349>
_______________________________________

From report at bugs.python.org  Sun Dec 17 06:59:07 2017
From: report at bugs.python.org (Cutter)
Date: Sun, 17 Dec 2017 11:59:07 +0000
Subject: [New-bugs-announce] [issue32350] pip can't handle MSVC warnings
 containing special characters
Message-ID: <1513511947.07.0.213398074469.issue32350@psf.upfronthosting.co.za>


New submission from Cutter <cutterx at free.fr>:

When trying to install pylint using pip on Windows 10, the installation of wrapt (a dependency of pylint) fails because a special character in an MSVC warning can't be decoded to utf-8.

Below is the relevant part of the console output:
---
Exception:
Traceback (most recent call last):
  File "C:\Users\(...)\AppData\Local\Programs\Python\Python36\lib\site-packages\pip\compat\__init__.py", line 73, in console_to_str
    return s.decode(sys.__stdout__.encoding)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 51: invalid start byte

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\(...)\AppData\Local\Programs\Python\Python36\lib\site-packages\pip\basecommand.py", line 215, in main
    status = self.run(options, args)
  File "C:\Users\(...)\AppData\Local\Programs\Python\Python36\lib\site-packages\pip\commands\install.py", line 342, in run
    prefix=options.prefix_path,
  File "C:\Users\(...)\AppData\Local\Programs\Python\Python36\lib\site-packages\pip\req\req_set.py", line 784, in install
    **kwargs
  File "C:\Users\(...)\AppData\Local\Programs\Python\Python36\lib\site-packages\pip\req\req_install.py", line 878, in install
    spinner=spinner,
  File "C:\Users\(...)\AppData\Local\Programs\Python\Python36\lib\site-packages\pip\utils\__init__.py", line 676, in call_subprocess
    line = console_to_str(proc.stdout.readline())
  File "C:\Users\(...)\AppData\Local\Programs\Python\Python36\lib\site-packages\pip\compat\__init__.py", line 75, in console_to_str
    return s.decode('utf_8')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 51: invalid start byte
---

I changed line 73 in \pip\compat\__init__.py to: print("!! TEST !! : ", s). The full console output after that change is in the attachment. The relevant part is:

 !! TEST !! :  b'C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.11.25503\\bin\\HostX86\\x64\\cl.exe /c /nologo /Ox /W3 /GL /DNDEBUG /MD -IC:\\Users\\(...)\\AppData\\Local\\Programs\\Python\\Python36\\include -IC:\\Users\\(...)\\AppData\\Local\\Programs\\Python\\Python36\\include "-IC:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.11.25503\\ATLMFC\\include" "-IC:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.11.25503\\include" "-IC:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.16299.0\\ucrt" "-IC:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.16299.0\\shared" "-IC:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.16299.0\\um" "-IC:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.16299.0\\winrt" /Tcsrc/wrapt/_wrappers.c /Fobuild\\temp.win-amd64-3.6\\Release\\src/wrapt/_wrappers.obj\r\n'
 !! TEST !! :  b'_wrappers.c\r\n'
 !! TEST !! :  b"src/wrapt/_wrappers.c(195): warning C4244: 'return'\xff: conversion de 'Py_hash_t' en 'long', perte possible de donn\x82es\r\n"
 error
 Exception:
 Traceback (most recent call last):
   File "C:\Users\(...)\AppData\Local\Programs\Python\Python36\Lib\site-packages\pip\compat\__init__.py", line 74, in console_to_str
     return s.decode(sys.__stdout__.encoding)
 UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 51: invalid start byte

As a workaround I've changed the original line 73 in \pip\compat\__init__.py :

return s.decode(sys.__stdout__.encoding)

to:

return s.decode(sys.__stdout__.encoding, "replace")

(thanks to dieter on comp.lang.python for his help). I don't have the knowledge to propose a patch.

----------
components: Windows
files: console.txt
messages: 308485
nosy: Cutter, Marcus.Smith, dstufft, ncoghlan, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pip can't handle MSVC warnings containing special characters
type: crash
versions: Python 3.6
Added file: https://bugs.python.org/file47334/console.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32350>
_______________________________________

From report at bugs.python.org  Sun Dec 17 07:22:02 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 17 Dec 2017 12:22:02 +0000
Subject: [New-bugs-announce] [issue32351] Use fastpath in asyncio.sleep if
 delay<0
Message-ID: <1513513322.7.0.213398074469.issue32351@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Currently asyncio.sleep schedules a callback execution by `loop.call_later()` call, which has the same behavior but 2x slower.

----------
components: Library (Lib), asyncio
messages: 308487
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Use fastpath in asyncio.sleep if delay<0
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32351>
_______________________________________

From report at bugs.python.org  Sun Dec 17 08:47:09 2017
From: report at bugs.python.org (thautwarm)
Date: Sun, 17 Dec 2017 13:47:09 +0000
Subject: [New-bugs-announce] [issue32352] `inspect.getfullargspec` doesn't
 work fine for some builtin callable objects
Message-ID: <1513518429.74.0.213398074469.issue32352@psf.upfronthosting.co.za>


New submission from thautwarm <yaoxiansamma at gmail.com>:

It's quite confusing to me that `inspect.getfullargspec` crashed when it was applied on some builtin callable objects.

```
for each in __builtin__.__dict__:
    try:
        obj = getattr(__builtin__, each)
        if not callable(obj): 
            continue
        inspect.getfullargspec(obj)
    except Exception as e:
        print(each, e)
```

Here are the results:

```
__build_class__ unsupported callable
__import__ unsupported callable
dir unsupported callable
getattr unsupported callable
iter unsupported callable
max unsupported callable
min unsupported callable
next unsupported callable
print unsupported callable
round unsupported callable
vars unsupported callable
bool unsupported callable
bytearray unsupported callable
bytes unsupported callable
classmethod unsupported callable
complex unsupported callable
dict unsupported callable
enumerate unsupported callable
filter unsupported callable
float unsupported callable
frozenset unsupported callable
property unsupported callable
int unsupported callable
list unsupported callable
map unsupported callable
range unsupported callable
reversed unsupported callable
set unsupported callable
slice unsupported callable
staticmethod unsupported callable
str unsupported callable
super unsupported callable
tuple unsupported callable
type unsupported callable
zip unsupported callable
BaseException unsupported callable
Exception unsupported callable
TypeError unsupported callable
StopAsyncIteration unsupported callable
StopIteration unsupported callable
GeneratorExit unsupported callable
SystemExit unsupported callable
KeyboardInterrupt unsupported callable
ImportError unsupported callable
ModuleNotFoundError unsupported callable
OSError unsupported callable
EnvironmentError unsupported callable
IOError unsupported callable
WindowsError unsupported callable
EOFError unsupported callable
RuntimeError unsupported callable
RecursionError unsupported callable
NotImplementedError unsupported callable
NameError unsupported callable
UnboundLocalError unsupported callable
AttributeError unsupported callable
SyntaxError unsupported callable
IndentationError unsupported callable
TabError unsupported callable
LookupError unsupported callable
IndexError unsupported callable
KeyError unsupported callable
ValueError unsupported callable
UnicodeError unsupported callable
UnicodeEncodeError unsupported callable
UnicodeDecodeError unsupported callable
UnicodeTranslateError unsupported callable
AssertionError unsupported callable
ArithmeticError unsupported callable
FloatingPointError unsupported callable
OverflowError unsupported callable
ZeroDivisionError unsupported callable
SystemError unsupported callable
ReferenceError unsupported callable
BufferError unsupported callable
MemoryError unsupported callable
Warning unsupported callable
UserWarning unsupported callable
DeprecationWarning unsupported callable
PendingDeprecationWarning unsupported callable
SyntaxWarning unsupported callable
RuntimeWarning unsupported callable
FutureWarning unsupported callable
ImportWarning unsupported callable
UnicodeWarning unsupported callable
BytesWarning unsupported callable
ResourceWarning unsupported callable
ConnectionError unsupported callable
BlockingIOError unsupported callable
BrokenPipeError unsupported callable
ChildProcessError unsupported callable
ConnectionAbortedError unsupported callable
ConnectionRefusedError unsupported callable
ConnectionResetError unsupported callable
FileExistsError unsupported callable
FileNotFoundError unsupported callable
IsADirectoryError unsupported callable
NotADirectoryError unsupported callable
InterruptedError unsupported callable
PermissionError unsupported callable
ProcessLookupError unsupported callable
TimeoutError unsupported callable
```

----------
components: Library (Lib)
messages: 308488
nosy: thautwarm
priority: normal
severity: normal
status: open
title: `inspect.getfullargspec` doesn't work fine for some builtin callable objects
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32352>
_______________________________________

From report at bugs.python.org  Sun Dec 17 15:09:34 2017
From: report at bugs.python.org (Decorater)
Date: Sun, 17 Dec 2017 20:09:34 +0000
Subject: [New-bugs-announce] [issue32353] Add docs about Embedding with an
 frozen module limitation.
Message-ID: <1513541374.74.0.213398074469.issue32353@psf.upfronthosting.co.za>


New submission from Decorater <seandhunt_7 at yahoo.com>:

It seems that 1 thing that bites me is that there is no section on the embedding docs about limitations to using frozen modules in them.

So lets say for example your program has this like in the main function on an embedded python:

```c
  PyRun_SimpleString("import mymodule");
```

And lets say ``mymodule`` is supposed to be an frozen module in that embedded interpreter named ``myprogram``

It would fail to work because it wont be able to find ``mymodule`` when it really should. This doc change should help fix that senerio and hopefully suggest an fix to that senerio as well.

----------
assignee: docs at python
components: Documentation
messages: 308497
nosy: Decorater, docs at python
priority: normal
severity: normal
status: open
title: Add docs about Embedding with an frozen module limitation.
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32353>
_______________________________________

From report at bugs.python.org  Sun Dec 17 21:00:12 2017
From: report at bugs.python.org (Campbell Barton)
Date: Mon, 18 Dec 2017 02:00:12 +0000
Subject: [New-bugs-announce] [issue32354] Unclear intention of deprecating
 Py_UNICODE_TOLOWER / Py_UNICODE_TOUPPER
Message-ID: <1513562412.88.0.213398074469.issue32354@psf.upfronthosting.co.za>


New submission from Campbell Barton <ideasman42 at gmail.com>:

Py_UNICODE_TOLOWER / Py_UNICODE_TOUPPER are marked as deprecated in the docs.

https://docs.python.org/3/c-api/unicode.html?highlight=py_unicode_tolower#c.Py_UNICODE_TOLOWER

Someone submitted a patch to our project which uses these.

What is unclear, is if there is an intention to replace these (wrappers for '_PyUnicode_ToLowerFull' for eg).

Or if this will be removed without any alternative.

I assume the functionality will be kept somewhere since Python needs str.lower/upper.

Will there be a way to perform this in the future? Either way, could docs be updated to reflect this?

----------
components: Unicode
messages: 308506
nosy: ezio.melotti, ideasman42, vstinner
priority: normal
severity: normal
status: open
title: Unclear intention of deprecating Py_UNICODE_TOLOWER / Py_UNICODE_TOUPPER
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32354>
_______________________________________

From report at bugs.python.org  Sun Dec 17 21:41:07 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 18 Dec 2017 02:41:07 +0000
Subject: [New-bugs-announce] [issue32355] Optimize asyncio.gather()
Message-ID: <1513564867.85.0.213398074469.issue32355@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

asyncio.gather can be made faster if:

1. we don't use functools.partial
2. create less intermittent collections
3. drop unnecessary code (e.g. gather has some code that's duplicated in ensure_future that it uses etc)

The proposed PR makes asyncio.gather 10-15% faster on the attached benchmark.

----------
assignee: yselivanov
components: asyncio
files: t.py
messages: 308508
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Optimize asyncio.gather()
type: performance
versions: Python 3.7
Added file: https://bugs.python.org/file47336/t.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32355>
_______________________________________

From report at bugs.python.org  Sun Dec 17 22:46:15 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 18 Dec 2017 03:46:15 +0000
Subject: [New-bugs-announce] [issue32356] asyncio: Make
 transport.pause_reading()/resume_reading() idempotent;
 add transport.is_reading()
Message-ID: <1513568775.87.0.213398074469.issue32356@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

As briefly discussed on https://github.com/python/asyncio/issues/488 and https://github.com/python/cpython/pull/528

----------
messages: 308509
nosy: yselivanov
priority: normal
severity: normal
status: open
title: asyncio: Make transport.pause_reading()/resume_reading() idempotent; add transport.is_reading()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32356>
_______________________________________

From report at bugs.python.org  Mon Dec 18 00:33:40 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 18 Dec 2017 05:33:40 +0000
Subject: [New-bugs-announce] [issue32357] Optimize asyncio.iscoroutine() for
 non-native coroutines
Message-ID: <1513575220.77.0.213398074469.issue32357@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

asyncio.Task now uses asyncio.iscoroutine() to give a comprehensible error if a user creates a Task for a non-awaitable type.

The problem is that iscoroutine() is quite expensive for non-native coroutines (like the ones compiled with Cython), as it uses `isinstance(obj, collections.abc.Coroutine)` call.  This makes 'loop.create_task(cython_coroutine)' 20% slower than 'loop.create_task(python_coroutine)'.

The PR adds a positive type cache to the iscoroutine() function and to the asyncio.Task C implementation.  Both caches make 'loop.create_task()' equally fast for all kinds of coroutines.

----------
components: asyncio
messages: 308515
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Optimize asyncio.iscoroutine() for non-native coroutines
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32357>
_______________________________________

From report at bugs.python.org  Mon Dec 18 01:24:46 2017
From: report at bugs.python.org (TaoQingyun)
Date: Mon, 18 Dec 2017 06:24:46 +0000
Subject: [New-bugs-announce] [issue32358] json.dump: fp must be a text file
 object
Message-ID: <1513578286.44.0.213398074469.issue32358@psf.upfronthosting.co.za>


New submission from TaoQingyun <845767657 at qq.com>:

```
>>> import json        
>>> f = open('/tmp/t.json', 'wb')              
>>> json.dump(123, f)  
Traceback (most recent call last):             
  File "<stdin>", line 1, in <module>          
  File "/usr/lib/python3.6/json/__init__.py", line 180, in dump                               
    fp.write(chunk)    
TypeError: a bytes-like object is required, not 'str'
```

This may not a bug. But it should mention at docs https://docs.python.org/3/library/json.html#json.dump

----------
components: Library (Lib)
messages: 308517
nosy: qingyunha
priority: normal
severity: normal
status: open
title: json.dump: fp must be a text file object
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32358>
_______________________________________

From report at bugs.python.org  Mon Dec 18 04:41:45 2017
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 18 Dec 2017 09:41:45 +0000
Subject: [New-bugs-announce] [issue32359] Add getters for all SSLContext
 internal configuration
Message-ID: <1513590105.76.0.213398074469.issue32359@psf.upfronthosting.co.za>


New submission from Nathaniel Smith <njs at pobox.com>:

Suppose you're writing a library that allows users to make or accept SSL/TLS connections. You use the 'ssl' module, because that's convenient. You need to let your users configure your SSL/TLS connections, and there really isn't any generic abstract way to do that -- SSL/TLS configuration is pretty complicated -- so you let your users set up an ssl.SSLContext and pass it into your API.

Later, you hit a limit in the ssl module and want to switch to PyOpenSSL, or perhaps eventually PEP 543. No problem: just switch what you're doing internally, and use some shim code to take the ssl.SSLContext objects that your users are passing in, and convert that to whatever your new library wants.

Except... ssl.SSLContext objects are almost entirely opaque. You can't read off the ciphers, or the ALPN protocols, or the servername_callback... so you're sunk. Once you expose ssl.SSLContext in your public API, you're stuck using the ssl module forever.

It would be nice if ssl.SSLContext provided getters that let you read off all the different configuration it holds.

----------
assignee: christian.heimes
components: SSL
messages: 308533
nosy: alex, christian.heimes, dstufft, janssen, njs
priority: normal
severity: normal
status: open
title: Add getters for all SSLContext internal configuration

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32359>
_______________________________________

From report at bugs.python.org  Mon Dec 18 04:45:46 2017
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 18 Dec 2017 09:45:46 +0000
Subject: [New-bugs-announce] [issue32360] Save OrderedDict imports in
 various stdlibs.
Message-ID: <1513590346.77.0.213398074469.issue32360@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
nosy: inada.naoki
priority: normal
severity: normal
status: open
title: Save OrderedDict imports in various stdlibs.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32360>
_______________________________________

From report at bugs.python.org  Mon Dec 18 04:59:49 2017
From: report at bugs.python.org (Camion)
Date: Mon, 18 Dec 2017 09:59:49 +0000
Subject: [New-bugs-announce] [issue32361] global / nonlocal interference :
 is this a bug, a feature or a design hole ?
Message-ID: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za>


New submission from Camion <camion_spam-pybugs at yahoo.com>:

Hello, 

"PEP 3104 -- Access to Names in Outer Scopes" introduced the keywords "global" and "nonlocal". but didn't make clear (to me) if this behaviour is a bug, an intentional feature, or a design hole which might be considered good or bad. 

I have observed that when the nonlocal keyword gives acces to a grand parent function's variable, the presence in the parent function, of an access to a global variable with the same name, blocks it with a syntax error (SyntaxError: no binding for nonlocal 'a' found).


a = "a : global"
def f():
    a = "a : local to f"
    def g():
#        global a     # uncommenting this line causes a syntax error.
#        a = a+", modified in g"
        def h():
            nonlocal a
            a = a+", modified in h"
        h()
        print (f"in g : a = '{a}'")
    g()
    print (f"in f : a = '{a}'")
f()
print (f"glogal : a = '{a}'")

----------
components: Interpreter Core
messages: 308537
nosy: Camion
priority: normal
severity: normal
status: open
title: global / nonlocal interference : is this a bug, a feature or a design hole ?
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32361>
_______________________________________

From report at bugs.python.org  Mon Dec 18 05:17:27 2017
From: report at bugs.python.org (Mark)
Date: Mon, 18 Dec 2017 10:17:27 +0000
Subject: [New-bugs-announce] [issue32362]
 multiprocessing.connection.Connection misdocumented as
 multiprocessing.Connection
Message-ID: <1513592247.3.0.213398074469.issue32362@psf.upfronthosting.co.za>


New submission from Mark <markamery at btinternet.com>:

https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Connection purports to document the multiprocessing.Connection class. There's no such thing:

Python 3.6.1 (v3.6.1:69c0db5050, Mar 21 2017, 01:21:04) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing
>>> multiprocessing.Connection
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'multiprocessing' has no attribute 'Connection'

I think it should be multiprocessing.connection.Connection?

----------
assignee: docs at python
components: Documentation
messages: 308539
nosy: Amery, docs at python
priority: normal
severity: normal
status: open
title: multiprocessing.connection.Connection misdocumented as multiprocessing.Connection
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32362>
_______________________________________

From report at bugs.python.org  Mon Dec 18 05:59:23 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 18 Dec 2017 10:59:23 +0000
Subject: [New-bugs-announce] [issue32363] Deprecate task.set_result() and
 task.set_exception()
Message-ID: <1513594763.95.0.213398074469.issue32363@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Task result is given from coroutine execution, explicit modification of the value should be deprecated and eventually removed.

----------
components: Library (Lib), asyncio
messages: 308542
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Deprecate task.set_result() and task.set_exception()
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32363>
_______________________________________

From report at bugs.python.org  Mon Dec 18 06:13:10 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 18 Dec 2017 11:13:10 +0000
Subject: [New-bugs-announce] [issue32364] Add AbstractFuture and AbstractTask
Message-ID: <1513595590.31.0.213398074469.issue32364@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Asyncio supports custom future and task by third-party loop implementation.
Abstract classes for them is needed.

AbstractTask should not have set_result()/set_exception() maybe, is this case abstract base is needed (AbstractPromise, AbstractCancellableValue or whatever).

----------
components: Library (Lib), asyncio
messages: 308543
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Add AbstractFuture and AbstractTask
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32364>
_______________________________________

From report at bugs.python.org  Mon Dec 18 06:24:03 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Dec 2017 11:24:03 +0000
Subject: [New-bugs-announce] [issue32365] Referenc leak: test_ast
 test_builtin test_compile
Message-ID: <1513596243.38.0.213398074469.issue32365@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

The following tests are leaking references: test_ast test_builtin test_compile.

It seems to be a regression introduced by the commit 3325a6780c81f1ea51190370b5454879c4862a37, bpo-27169.

Serhiy: would you mind to take a look?

----------
components: Tests
messages: 308544
nosy: serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Referenc leak: test_ast test_builtin test_compile
type: resource usage
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32365>
_______________________________________

From report at bugs.python.org  Mon Dec 18 06:37:43 2017
From: report at bugs.python.org (iMath)
Date: Mon, 18 Dec 2017 11:37:43 +0000
Subject: [New-bugs-announce] [issue32366] suggestion:html.escape(s,
 quote=True) escape  \n to <br />
Message-ID: <1513597063.07.0.213398074469.issue32366@psf.upfronthosting.co.za>


New submission from iMath <redstone-cold at 163.com>:

It would be better if html.escape(s, quote=True) could escape linefeed to <br />
https://docs.python.org/3/library/html.html#html.escape

----------
components: XML
messages: 308546
nosy: redstone-cold
priority: normal
severity: normal
status: open
title: suggestion:html.escape(s, quote=True) escape  \n to <br />
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32366>
_______________________________________

From report at bugs.python.org  Mon Dec 18 11:29:03 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Dec 2017 16:29:03 +0000
Subject: [New-bugs-announce] [issue32367] CVE-2017-17522: webbrowser.py in
 Python does not validate strings
Message-ID: <1513614543.15.0.213398074469.issue32367@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

https://security-tracker.debian.org/tracker/CVE-2017-17522

Lib/webbrowser.py in Python through 3.6.3 does not validate strings before launching the program specified by the BROWSER environment variable, which might allow remote attackers to conduct argument-injection attacks via a crafted URL.

----------
components: Library (Lib)
messages: 308572
nosy: vstinner
priority: normal
severity: normal
status: open
title: CVE-2017-17522: webbrowser.py in Python does not validate strings
type: security
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32367>
_______________________________________

From report at bugs.python.org  Mon Dec 18 11:29:24 2017
From: report at bugs.python.org (Stefan Nordhausen)
Date: Mon, 18 Dec 2017 16:29:24 +0000
Subject: [New-bugs-announce] [issue32368] Segfault when compiling many
 conditional expressions
Message-ID: <1513614564.0.0.213398074469.issue32368@psf.upfronthosting.co.za>


New submission from Stefan Nordhausen <stefan.nordhausen at solarisbank.de>:

The following code reproducibly segfaults in version 2.7.13, 3.6.3 and the current git master (3.7.0a3+):


code = "42 if True else 43\n" * 200000
compile(code, "foobar", "exec")


This issue was originally found because the Jinja templating engine internally produces large tuples with many conditional expressions, thus triggering this bug (see https://github.com/pallets/jinja/issues/784 ).

----------
components: Interpreter Core
messages: 308573
nosy: snordhausen
priority: normal
severity: normal
status: open
title: Segfault when compiling many conditional expressions
type: crash
versions: Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32368>
_______________________________________

From report at bugs.python.org  Mon Dec 18 14:23:30 2017
From: report at bugs.python.org (Alexey Izbyshev)
Date: Mon, 18 Dec 2017 19:23:30 +0000
Subject: [New-bugs-announce] [issue32369] test_subprocess: last part of
 test_close_fds() doesn't check what's intended
Message-ID: <1513625010.32.0.213398074469.issue32369@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

The last part of test_close_fds() doesn't match its own comment. The following assertion always holds because fds_to_keep and open_fds are disjoint by construction.

self.assertFalse(remaining_fds & fds_to_keep & open_fds,
                 "Some fds not in pass_fds were left open")

----------
components: Tests
messages: 308581
nosy: izbyshev
priority: normal
severity: normal
status: open
title: test_subprocess: last part of test_close_fds() doesn't check what's intended
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32369>
_______________________________________

From report at bugs.python.org  Mon Dec 18 19:24:51 2017
From: report at bugs.python.org (Segev Finer)
Date: Tue, 19 Dec 2017 00:24:51 +0000
Subject: [New-bugs-announce] [issue32370] Wrong ANSI encoding used by
 subprocess for some locales
Message-ID: <1513643091.19.0.213398074469.issue32370@psf.upfronthosting.co.za>


New submission from Segev Finer <segev208 at gmail.com>:

The following test is failing randomly for me (python -m test test_uuid -v):
======================================================================
ERROR: test_ipconfig_getnode (test.test_uuid.TestInternalsWithoutExtModule)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "cpython\lib\test\test_uuid.py", line 551, in test_ipconfig_getnode
    node = self.uuid._ipconfig_getnode()
  File "cpython\lib\uuid.py", line 487, in _ipconfig_getnode
    for line in pipe:
  File "cpython\lib\encodings\cp1255.py", line 23, in decode
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x8d in position 682: character maps to <undefined>

This is caused by trying to decode the output of "ipconfig" using cp1255, while the output really uses cp862 and annoyingly it started to print times using the current locale (Which displays broken in the console anyhow, question mark boxes... *sigh*) in some Windows version (Using Windows 10.0.16299 ATM).

----------
components: Windows
messages: 308597
nosy: Segev Finer, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Wrong ANSI encoding used by subprocess for some locales
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32370>
_______________________________________

From report at bugs.python.org  Tue Dec 19 08:13:18 2017
From: report at bugs.python.org (Pierre Chatelier)
Date: Tue, 19 Dec 2017 13:13:18 +0000
Subject: [New-bugs-announce] [issue32371] Delay-loading of python dll is
 impossible when using some C macros
Message-ID: <1513689198.93.0.213398074469.issue32371@psf.upfronthosting.co.za>


New submission from Pierre Chatelier <pierre at chachatelier.fr>:

Delay-loading of the python DLL is impossible when using some C macros.

For instance, PyLong_Check() is OK, but PyBool_Check() or PyFunc_Check() 
will eventually raise a link error.

This is due to the fact that PyBool_Check() directly use the PyBool_Type symbol instead of getting a reference through a function.

For the same reason, Py_False and Py_True are problematic.

----------
components: Windows
messages: 308639
nosy: Pierre Chatelier, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Delay-loading of python dll is impossible when using some C macros
type: compile error
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32371>
_______________________________________

From report at bugs.python.org  Tue Dec 19 09:11:45 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Dec 2017 14:11:45 +0000
Subject: [New-bugs-announce] [issue32372] Optimize out __debug__ at the AST
 level
Message-ID: <1513692705.53.0.213398074469.issue32372@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

__debug__ is substituted by the constant value at the code generation stage (see issue27169). This prevents it from participating in constant folding at the AST level. The proposed patch moves this optimization to the AST level. This will lead to optimizing "if not __debug__" and will allow to add more optimizations at the AST level (like optimizing expressions "a if __debug__ else b" and "__debug__ and a").

----------
assignee: serhiy.storchaka
components: Interpreter Core
messages: 308643
nosy: inada.naoki, pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Optimize out __debug__ at the AST level
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32372>
_______________________________________

From report at bugs.python.org  Tue Dec 19 09:23:24 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 19 Dec 2017 14:23:24 +0000
Subject: [New-bugs-announce] [issue32373] Add socket.getblocking() method
Message-ID: <1513693404.23.0.213398074469.issue32373@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

Currently we have the following methods:

* socket.settimeout(t) -- can set the socket in blocking mode, when t==0.
* socket.setblocking(flag) -- sets in blocking or non-blocking mode.
* socket.gettimeout() -- returns 0 when socket is in non-blocking mode.

socket.gettimeout() is the only easy way of checking if the socket is non-blocking or blocking, but it's not intuitive to use it.  It's especially strange that we have a setblocking() method without a corresponding getblocking().

I propose to add a 'socket.getblocking() -> bool' method.

----------
assignee: yselivanov
components: Library (Lib)
messages: 308645
nosy: yselivanov
priority: normal
severity: normal
status: open
title: Add socket.getblocking() method
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32373>
_______________________________________

From report at bugs.python.org  Tue Dec 19 09:40:38 2017
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 19 Dec 2017 14:40:38 +0000
Subject: [New-bugs-announce] [issue32374] Document that m_traverse for
 multi-phase initialized modules can be called with m_state=NULL
Message-ID: <1513694438.46.0.213398074469.issue32374@psf.upfronthosting.co.za>


New submission from Petr Viktorin <encukou at gmail.com>:

After the create phase of multiphase initialization, the per-module state is NULL and the module object is reachable by the garbage collector. Between the create and exec phases, Python code is run and garbage collection can be triggered.
So, any custom m_traverse/m_clear/m_free function must be prepared to handle m_state being NULL. This is currently not well documented.

It might be useful to insert a call m_traverse after the first phase, at least in --with-pydebug mode, so the potential error gets triggered early.

----------
components: Extension Modules
messages: 308647
nosy: encukou
priority: normal
severity: normal
status: open
title: Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32374>
_______________________________________

From report at bugs.python.org  Tue Dec 19 10:05:24 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Dec 2017 15:05:24 +0000
Subject: [New-bugs-announce] [issue32375] Compilation warnings with gcc
Message-ID: <1513695924.3.0.213398074469.issue32375@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

On Ubuntu 16.04:

$ gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ make
[...]
In function ?wcsncpy?,
    inlined from ?calculate_zip_path? at ./Modules/getpath.c:797:5:
/usr/include/x86_64-linux-gnu/bits/wchar2.h:200:9: warning: call to ?__wcsncpy_chk_warn? declared with attribute warning: wcsncpy called with length bigger than size of destination buffer
  return __wcsncpy_chk_warn (__dest, __src, __n,
         ^
In function ?wcsncpy?,
    inlined from ?calculate_zip_path? at ./Modules/getpath.c:806:9:
/usr/include/x86_64-linux-gnu/bits/wchar2.h:200:9: warning: call to ?__wcsncpy_chk_warn? declared with attribute warning: wcsncpy called with length bigger than size of destination buffer
  return __wcsncpy_chk_warn (__dest, __src, __n,
         ^
In function ?wcsncpy?,
    inlined from ?calculate_argv0_path? at ./Modules/getpath.c:683:5:
/usr/include/x86_64-linux-gnu/bits/wchar2.h:200:9: warning: call to ?__wcsncpy_chk_warn? declared with attribute warning: wcsncpy called with length bigger than size of destination buffer
  return __wcsncpy_chk_warn (__dest, __src, __n,
         ^
In function ?wcsncpy?,
    inlined from ?calculate_argv0_path? at ./Modules/getpath.c:736:13:
/usr/include/x86_64-linux-gnu/bits/wchar2.h:200:9: warning: call to ?__wcsncpy_chk_warn? declared with attribute warning: wcsncpy called with length bigger than size of destination buffer
  return __wcsncpy_chk_warn (__dest, __src, __n,
         ^

----------
components: Interpreter Core
messages: 308653
nosy: pitrou, serhiy.storchaka, vstinner
priority: low
severity: normal
status: open
title: Compilation warnings with gcc
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32375>
_______________________________________

From report at bugs.python.org  Tue Dec 19 10:59:56 2017
From: report at bugs.python.org (Dmitry sky)
Date: Tue, 19 Dec 2017 15:59:56 +0000
Subject: [New-bugs-announce] [issue32376] Unusable syntax error reported
 when Python keyword in a f-string
Message-ID: <1513699196.74.0.213398074469.issue32376@psf.upfronthosting.co.za>


New submission from Dmitry sky <d.v.selitsky at gmail.com>:

def get_search_url(from_, to):
    return f"http://thesite.com/Search?SO0={from_}&SD0={to}&SD1={from}&NA=false"
#   pls note `from_` vs `from`                                  ^^^^^^


$ python fstring.py
  File "<fstring>", line 1
    (from)
        ^
SyntaxError: invalid syntax


Should report real line #.

----------
components: Interpreter Core
files: fstring.py
messages: 308657
nosy: Dmitry sky
priority: normal
severity: normal
status: open
title: Unusable syntax error reported when Python keyword in a f-string
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47338/fstring.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32376>
_______________________________________

From report at bugs.python.org  Tue Dec 19 11:29:59 2017
From: report at bugs.python.org (Eric Cousineau)
Date: Tue, 19 Dec 2017 16:29:59 +0000
Subject: [New-bugs-announce] [issue32377] Difference in ressurrection
 behavior with __del__ in py2 vs. py3
Message-ID: <1513700999.05.0.213398074469.issue32377@psf.upfronthosting.co.za>


New submission from Eric Cousineau <eric.cousineau at tri.global>:

Due to how `PyObject_CallFinalizer` is written in python3, `__del__` will only *ever* be called once.

In my use case, I am experimenting with a feature in `pybind11` to prevent slicing with Python class instances that inherit from pybind11-C++ base classes, which involves detecting when an instance loses all reference in Python (`Py_REFCNT(...) == 0`) but still has reference in C++ (`shared_ptr::count() > 0`), and reviving the Python portion when this situation happens.

In python2, I could do this without a hitch, as a resurrected object could have its `__del__` method called multiple times (through `tp_dealloc` I believe?). But in python3, the object is marked with `_PyGC_SET_FINALIZED(...)`, thus preventing `__del__` from being called again.

It'd be nice to either (a) somehow allow `__del__` to be called naturally without too much fuss or, at the least, (b) have this reflected in the documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__

See attached `revive_test`. Example execution:

```
$ python2 ./revive_test.py 
Revive
Destroy
[ Done ]

$ python3 ./revive_test.py 
Revive
[ Done ]
```

----------
assignee: docs at python
components: Documentation
files: revive_test.py
messages: 308660
nosy: Eric Cousineau, docs at python
priority: normal
severity: normal
status: open
title: Difference in ressurrection behavior with __del__ in py2 vs. py3
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: https://bugs.python.org/file47339/revive_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32377>
_______________________________________

From report at bugs.python.org  Tue Dec 19 13:59:04 2017
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 19 Dec 2017 18:59:04 +0000
Subject: [New-bugs-announce] [issue32378] test_npn_protocols broken with
 LibreSSL 2.6.1+
Message-ID: <1513709944.02.0.213398074469.issue32378@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

LibreSSL 2.6.1 to 2.6.4 have a broken implementation of NPN protocol. 2.6.0 and earlier are fine.


======================================================================
FAIL: test_npn_protocols (test.test_ssl.ThreadedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", line 3424, in test_npn_protocols
    self.assertEqual(client_result, expected, msg % (client_result, "client"))
AssertionError: None != 'http/1.1' : failed trying ['http/1.1', 'spdy/2'] (s) and ['http/1.1', 'spdy/2'] (c).
was expecting http/1.1, but got None from the client

Upstream issue https://github.com/libressl-portable/portable/issues/368

----------
assignee: christian.heimes
components: SSL
messages: 308669
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: test_npn_protocols broken with LibreSSL 2.6.1+
versions: Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32378>
_______________________________________

From report at bugs.python.org  Tue Dec 19 14:54:59 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Dec 2017 19:54:59 +0000
Subject: [New-bugs-announce] [issue32379] MRO computation could be faster
Message-ID: <1513713299.76.0.213398074469.issue32379@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

MRO computation involves a complicated merge calculation over several lists.  But, for the simple (common) case where a class has a single base, the computation could be much simpler: take the base's MRO and prepend the derived class.

----------
components: Interpreter Core
messages: 308674
nosy: pitrou
priority: normal
severity: normal
status: open
title: MRO computation could be faster
type: performance
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32379>
_______________________________________

From report at bugs.python.org  Tue Dec 19 17:23:08 2017
From: report at bugs.python.org (Ethan Smith)
Date: Tue, 19 Dec 2017 22:23:08 +0000
Subject: [New-bugs-announce] [issue32380] functools.singledispatch interacts
 poorly with methods
Message-ID: <1513722188.44.0.213398074469.issue32380@psf.upfronthosting.co.za>


New submission from Ethan Smith <ethan at ethanhs.me>:

Consider the following:

from functools import singledispatch

class Dispatch:
    @singledispatch
    def foo(self, a):
        return a

    @foo.register(int)
    def _(self, a):
        return "int"

    @foo.register(str)
    def _(self, a):
        return "str"

cls = Dispatch()
cls.foo(3)  # 3
cls.foo('hm')  # 'hm'

I find this quite unintuitive. Essentially, since singledispatch dispatches based solely on a functions first argument, it is useless on methods unless one wraps it and modifies how it uses the internal wrapper function. I believe this should be relatively easy to fix with adding a check of inspect.ismethod and then modifying the number of the checked argument where appropriate.

I'm happy to write a patch if this change is seen as a good idea.

----------
components: Library (Lib)
messages: 308687
nosy: Ethan Smith
priority: normal
severity: normal
status: open
title: functools.singledispatch interacts poorly with methods
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32380>
_______________________________________

From report at bugs.python.org  Wed Dec 20 01:07:25 2017
From: report at bugs.python.org (tianjg)
Date: Wed, 20 Dec 2017 06:07:25 +0000
Subject: [New-bugs-announce] [issue32381] python3.6 can not reopen .pyc file
 with Chinese path
Message-ID: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>


New submission from tianjg <jango.tian at gmail.com>:

have a problem that python3.6 can not reopen .pyc file with Chinese path, and python3.5 can reopen the same pyc file. As shown in the picture

----------
components: Windows
files: 20171218111240.jpg
messages: 308705
nosy: paul.moore, steve.dower, tianjg, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: python3.6 can not reopen .pyc file with Chinese path
type: compile error
versions: Python 3.6
Added file: https://bugs.python.org/file47341/20171218111240.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32381>
_______________________________________

From report at bugs.python.org  Wed Dec 20 04:55:32 2017
From: report at bugs.python.org (Weize Xu)
Date: Wed, 20 Dec 2017 09:55:32 +0000
Subject: [New-bugs-announce] [issue32382] Python mulitiprocessing.Queue fail
 to get according to correct sequence
Message-ID: <1513763732.34.0.213398074469.issue32382@psf.upfronthosting.co.za>


New submission from Weize Xu <vet.xwz at gmail.com>:

I try to implement a "producer consumer" like design with mulitiprocessing module in my project, but I found that mulitiprocessing.Queue 's behavior is not as my expected. It seems Queue.get method return the end flag at the end of my queue too early. 

I am not experienced at muliti-process programing, I am not sure it's a bug or not. For reproduce this, I have simplified my code as following:

``` Python
import time
import multiprocessing as mp

def worker(task_queue, output_queue):
    while 1:
        i = task_queue.get()
        if i is None:
            print("Process-%d done"%mp.current_process().pid)
            task_queue.task_done()
            break
        output_queue.put(i+1)
        task_queue.task_done()

def outputer(output_queue):
    c = 0 # val for count how many obj geted
    while 1:
        j = output_queue.get()
        if j is None:
            print("Process(output)-%d done"%mp.current_process().pid)
            c += 1
            print("outputer get %d objects from the output_queue"%c)
            assert output_queue.empty(), "output queue should be empty here"
            break
        time.sleep(0.0001) # do output here
        c += 1

if __name__ == "__main__":
    task_queue = mp.JoinableQueue()
    #output_queue = mp.JoinableQueue()
    output_queue = mp.Queue()

    workers = [mp.Process(target=worker, args=(task_queue, output_queue))
               for i in range(10)]
    outputer = mp.Process(target=outputer, args=(output_queue,))

    for w in workers:
        w.start()
    outputer.start()

    for i in range(10**6):
        task_queue.put(i)
    for w in workers: # put end flag to task queue
        task_queue.put(None)

    task_queue.join() # wait all tasks done
    print("all tasks done.")

    print("queue size before put end flag: %d"%output_queue.qsize())
    output_queue.put(None) # put end flag to output queue

    print("end")
```

Get the output:

Process-20923 done
Process-20931 done
Process-20925 done
Process-20930 done
Process-20927 done
Process-20929 done
Process-20928 done
Process-20926 done
Process-20924 done
Process-20932 done
all tasks done.
queue size before put end flag: 914789
end
Process(output)-20933 done
outputer get 90383 objects from the output_queue
Process Process-11:
Traceback (most recent call last):
  File "/home/nanguage/S/miniconda3/lib/python3.6/multiprocessing/process.py", line 249, in _bootstrap
    self.run()
  File "/home/nanguage/S/miniconda3/lib/python3.6/multiprocessing/process.py", line 93, in run
    self._target(*self._args, **self._kwargs)
  File "joinablequeue.py", line 27, in outputer
    assert output_queue.empty(), "output queue should be empty here"
AssertionError: output queue should be empty here


I have wait all worker put the output to the output queue use taks_queue.join(), then I put the end flag to the output queue, but according to outputer's printed information, it get the `None` end flag before other value in the queue. It seems queue not get value according to 'FIFO' rule.

----------
components: Library (Lib)
messages: 308710
nosy: Weize Xu, davin
priority: normal
severity: normal
status: open
title: Python mulitiprocessing.Queue fail to get according to correct sequence
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32382>
_______________________________________

From report at bugs.python.org  Wed Dec 20 04:57:21 2017
From: report at bugs.python.org (=?utf-8?b?0J3QuNC60L7Qu9Cw0Lkg0KHQvtC60L7Qu9C+0LI=?=)
Date: Wed, 20 Dec 2017 09:57:21 +0000
Subject: [New-bugs-announce] [issue32383] subprocess.Popen() is slower than
 subprocess.run()
Message-ID: <1513763841.52.0.213398074469.issue32383@psf.upfronthosting.co.za>


New submission from ??????? ??????? <sokolov.nicholas at gmail.com>:

Hello.

I noticed different speed of application, which was execute with subprocess.Popen() and subprocess.run().

I tested on Linux Ubuntu 17.04 and Windows 10.
My command line is:
     "ffmpeg -i big_buck_bunny_480p_surround-fix.avi -f null -" 
you can use any video file on your PC.
I used ffmpeg (open source encoder/decoder/and etc.), but you can use any applications, which counts himself speed of work.

I got a difference in speed:

Using by terminal: fps=4402 (frame per second);
Using by run(): fps=4019;
Using by Popen(): fps=3431;

On Windows is difference about 5% percent, on Linux about 10% percent.

I did not use additional flags. All by default.
I downloaded video stream here https://peach.blender.org/download/

----------
components: Library (Lib)
messages: 308711
nosy: ??????? ???????
priority: normal
severity: normal
status: open
title: subprocess.Popen() is slower than subprocess.run()
type: performance
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32383>
_______________________________________

From report at bugs.python.org  Wed Dec 20 05:50:40 2017
From: report at bugs.python.org (Liqun Peng)
Date: Wed, 20 Dec 2017 10:50:40 +0000
Subject: [New-bugs-announce] [issue32384] Generator tests is broken in
 non-CPython implementation
Message-ID: <1513767040.63.0.213398074469.issue32384@psf.upfronthosting.co.za>


New submission from Liqun Peng <issaria at gmail.com>:

The fix for bpo-30039 introduced a regression test in `test.test_generators` which uses `_testcapi` module, it doesn't check `ImportError` and so breaks on other implementations.

----------
components: Tests
messages: 308717
nosy: isaiahp
priority: normal
severity: normal
status: open
title: Generator tests is broken in non-CPython implementation
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32384>
_______________________________________

From report at bugs.python.org  Wed Dec 20 10:40:56 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Dec 2017 15:40:56 +0000
Subject: [New-bugs-announce] [issue32385] Clean up the C3 MRO algorithm
 implementation.
Message-ID: <1513784456.46.0.213398074469.issue32385@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The C3 MRO algorithm implementation uses lists and converts input tuples to lists. This is redundant, because these lists are not mutated. The proposed PR makes the implementation using tuples and gets rid of unneeded conversions.

----------
components: Interpreter Core
messages: 308739
nosy: pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Clean up the C3 MRO algorithm implementation.
type: performance
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32385>
_______________________________________

From report at bugs.python.org  Wed Dec 20 10:44:33 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Dec 2017 15:44:33 +0000
Subject: [New-bugs-announce] [issue32386] dynload_next.c is obsolete
Message-ID: <1513784673.38.0.213398074469.issue32386@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The configure scripts has the following comment:
"""Use dynload_next.c only on 10.2 and below, which don't have native dlopen()"""

It seems dynload_next.c can be removed now.

----------
messages: 308740
nosy: ned.deily, pitrou, ronaldoussoren
priority: normal
severity: normal
status: open
title: dynload_next.c is obsolete
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32386>
_______________________________________

From report at bugs.python.org  Wed Dec 20 10:47:54 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Dec 2017 15:47:54 +0000
Subject: [New-bugs-announce] [issue32387] Disallow untagged C extension
 import on major platforms
Message-ID: <1513784874.54.0.213398074469.issue32387@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Windows and the major POSIX platforms (including Linux and macOS) now support loading C extension with a version-tagged name (and build them likewise), such as "foobar.cpython-36.so".

Following the discussion in https://mail.python.org/pipermail/python-dev/2017-December/151328.html, I propose to remove the ability to load untagged C extension names on those platforms.  IOW, "foobar.dll" or "foobar.so" will not be recognized when "import foobar" is executed anymore.

----------
components: Interpreter Core
messages: 308741
nosy: brett.cannon, eric.snow, ncoghlan, ned.deily, paul.moore, pitrou, ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Disallow untagged C extension import on major platforms
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32387>
_______________________________________

From report at bugs.python.org  Wed Dec 20 12:27:59 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Dec 2017 17:27:59 +0000
Subject: [New-bugs-announce] [issue32388] Remove cross-version binary
 compatibility
Message-ID: <1513790879.02.0.213398074469.issue32388@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

See original discussion on python-dev:
https://mail.python.org/pipermail/python-dev/2017-December/151328.html

Summary: binary compatibility for C extensions which don't use the stable ABI is currently "best effort" and uses distinguished flags in the tp_flags field of type objects to indicate whether a field is physically present or not.  Unfortunately, tp_flags is 32 bits and therefore a scarce resource.  Also, binary compatibility is 1) not guaranteed anyway 2) of less use nowadays.

So we propose to remove the binary compatibility requirement when creating static type objects (i.e. not using the stable ABI).

----------
components: Interpreter Core
messages: 308753
nosy: barry, paul.moore, pitrou, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Remove cross-version binary compatibility
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32388>
_______________________________________

From report at bugs.python.org  Wed Dec 20 13:15:40 2017
From: report at bugs.python.org (Gianguido Piani)
Date: Wed, 20 Dec 2017 18:15:40 +0000
Subject: [New-bugs-announce] [issue32389] urllib3 wrong computation of
 'Content-Length' for file upload
Message-ID: <1513793740.16.0.213398074469.issue32389@psf.upfronthosting.co.za>


New submission from Gianguido Piani <gianguido at mail.ru>:

Hi! This is my first posting ever on this site. I need to upload a simple text file to Internet servers. With "curl" the operation goes smoothly, both with http and https protocols, both up/downloads. With urllib3 and other TCP-IP handlers the generated header for 'Content-Length' contains a wrong file length indication (log verification with TCPDUMP), the file is not uploaded, the servers return different error messages.

On the contrary, urllib3 file downloads do work, also with authentication.

code example
headers = {'authorization': 'Basic ==codeduserpwd=='}
resp = http_client.request('PUT',
                           'https://webserver.com',
                           headers=headers,
                           fields={'whatfile': (filename, file_data)}
                           )

In addition, in the documentation I still haven't figured out what 'whatfile' (or any of the other keywords used there) actually is. Is this a keyword (where is the list of all allowed kwds?), the source file, the target file, or what else?? How does the function behaviour change depending on that indication?

Thankful for your support!

----------
components: Library (Lib)
messages: 308761
nosy: gianguido
priority: normal
severity: normal
status: open
title: urllib3 wrong computation of 'Content-Length' for file upload
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32389>
_______________________________________

From report at bugs.python.org  Wed Dec 20 14:02:31 2017
From: report at bugs.python.org (Michael Felt)
Date: Wed, 20 Dec 2017 19:02:31 +0000
Subject: [New-bugs-announce] [issue32390] AIX (xlc_r) compile error with
 Modules/posixmodule.c: Explicit dimension specification or initializer
 required
Message-ID: <1513796551.12.0.213398074469.issue32390@psf.upfronthosting.co.za>


New submission from Michael Felt <michael at felt.demon.nl>:

current level: commit 4b965930e8625f77cb0e821daf5cc40e85b45f84 (HEAD -> master, upstream/master, origin/master, origin/HEAD)

Build message:
michael at x071:[/data/prj/python/git/python3-3.7.X]make
xlc_r  -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5      -I. -I./Include -I/opt/include   -DPy_BUILD_CORE  -c ./Modules/posixmodule.c -o Modules/posixmodule.o
"./Modules/posixmodule.c", line 5514.11: 1506-131 (W) Explicit dimension specification or initializer required for an auto or static array.
"./Modules/posixmodule.c", line 9328.64: 1506-280 (S) Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed.
Makefile:1765: recipe for target 'Modules/posixmodule.o' failed
make: *** [Modules/posixmodule.o] Error 1

Details (note rewrite from listing for line 5514)

     5514 | PyDoc_VAR(os_sched_param__doc__);
     5514 + static char os_sched_param__doc__[];
"./Modules/posixmodule.c", line 5514.11: 1506-131 (W) Explicit dimension specification or initializer required for an auto or static array.
     5515 |
     5516 | static PyStructSequence_Field sched_param_fields[] = {
     5517 |     {"sched_priority", "the scheduling priority"},
     5518 |     {0}
     5519 | };

----------
components: Build
messages: 308775
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: AIX (xlc_r) compile error with Modules/posixmodule.c: Explicit dimension specification or initializer required
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32390>
_______________________________________

From report at bugs.python.org  Wed Dec 20 14:12:25 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 20 Dec 2017 19:12:25 +0000
Subject: [New-bugs-announce] [issue32391] Add StreamWriter.wait_closed()
Message-ID: <1513797145.51.0.213398074469.issue32391@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Without the method there is no possibility to wait for actual writer closing (it's performed at least on next loop iteration, and even later for SSL transports).

Without waiting for actual closing writing tests is a pain: user should either add asyncio.sleep() after writer closing or suppress many warnings about unclosed resources.

----------
components: Library (Lib), asyncio
messages: 308780
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Add StreamWriter.wait_closed()
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32391>
_______________________________________

From report at bugs.python.org  Wed Dec 20 15:47:11 2017
From: report at bugs.python.org (Oleh Prypin)
Date: Wed, 20 Dec 2017 20:47:11 +0000
Subject: [New-bugs-announce] [issue32392] subprocess.run documentation does
 not have **kwargs
Message-ID: <1513802831.78.0.213398074469.issue32392@psf.upfronthosting.co.za>


New submission from Oleh Prypin <blaxpirit at gmail.com>:

I was just looking at documentation of https://docs.python.org/3.6/library/subprocess.html#subprocess.run
and thought that it doesn't support passing `env` because the list of supported keyword arguments is exhaustive (no **kwargs). But it does support passing **kwargs to Popen, so that should be specified in the docs.

----------
assignee: docs at python
components: Documentation
messages: 308810
nosy: docs at python, oprypin
priority: normal
severity: normal
status: open
title: subprocess.run documentation does not have **kwargs
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32392>
_______________________________________

From report at bugs.python.org  Wed Dec 20 18:00:52 2017
From: report at bugs.python.org (Joseph Hendrey)
Date: Wed, 20 Dec 2017 23:00:52 +0000
Subject: [New-bugs-announce] [issue32393] nav menu jitter in old
 documentation
Message-ID: <1513810852.69.0.213398074469.issue32393@psf.upfronthosting.co.za>


New submission from Joseph Hendrey <jhendrey at condense.com.au>:

The sidebar navigation menu jitters when scrolling on the 2.7 documentation pages (at least in Chrome).

A seemingly unrelated issue is that the collapse symbol '<<' is a fixed distance from the top of the page rather than staying in the centre (height-wise) of the screen (it should always be visible).

It seems it has been fixed for newer documentation, but since the fix is so simple it would be nice to fix it for the old documentation too. Setting the position property of the span element seems to fix both issues for me (see attached screenshot)

----------
assignee: docs at python
components: Documentation
files: screenshot.JPG
messages: 308834
nosy: Joseph Hendrey, docs at python
priority: normal
severity: normal
status: open
title: nav menu jitter in old documentation
type: behavior
versions: Python 2.7
Added file: https://bugs.python.org/file47343/screenshot.JPG

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32393>
_______________________________________

From report at bugs.python.org  Wed Dec 20 19:12:44 2017
From: report at bugs.python.org (Kamil)
Date: Thu, 21 Dec 2017 00:12:44 +0000
Subject: [New-bugs-announce] [issue32394] socket lib beahavior change in
 3.6.4
Message-ID: <1513815164.25.0.213398074469.issue32394@psf.upfronthosting.co.za>


New submission from Kamil <skn78 at mail.ru>:

On Windows, python 3.6.3 code "hasattr(socket, 'TCP_KEEPCNT')" gives False, python 3.6.4 gives True. This behavior breaks many libraries that i use.

----------
components: Library (Lib)
messages: 308837
nosy: skn78
priority: normal
severity: normal
status: open
title: socket lib beahavior change in 3.6.4
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32394>
_______________________________________

From report at bugs.python.org  Thu Dec 21 00:52:54 2017
From: report at bugs.python.org (Bruce Merry)
Date: Thu, 21 Dec 2017 05:52:54 +0000
Subject: [New-bugs-announce] [issue32395] asyncio.StreamReader.readuntil is
 not general enough
Message-ID: <1513835574.11.0.213398074469.issue32395@psf.upfronthosting.co.za>


New submission from Bruce Merry <bmerry at gmail.com>:

I'd proposed one specific solution in Issue 32052 which asvetlov didn't like, so as requested I'm filing a bug about the problem rather than the solution.

The specific case I have is reading a protocol in which either \r or \n can be used to terminate lines. With StreamReader.readuntil, it's only possible to specify one separator, so it can't easily be used (*).

Some nice-to-have features, from specific to general:
1. Specify multiple alternate separators.
2. Specify a regex for a separator.
3. Specify a regex for the line.
4. Specify a callback that takes a string and returns the position of the end of the line, if any.

Of course, some of these risk quadratic-time behaviour if they have to check the whole buffer every time the buffer is extended, so that would need to be considered in the design. In the last case, the callback could take care of it itself by maintaining internal state.


(*) I actually have a solution for this case (https://github.com/ska-sa/aiokatcp/blob/bd8263cefe213003a218fac0dd8c5207cc76aeef/aiokatcp/connection.py#L44-L52), but it only works because \r and \n are semantically equivalent in the particular protocol I'm parsing.

----------
components: asyncio
messages: 308852
nosy: Bruce Merry, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.StreamReader.readuntil is not general enough
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32395>
_______________________________________

From report at bugs.python.org  Thu Dec 21 07:42:09 2017
From: report at bugs.python.org (jabdoa)
Date: Thu, 21 Dec 2017 12:42:09 +0000
Subject: [New-bugs-announce] [issue32396] Implement method to write/read to
 serials without blocking on windows with asyncio
Message-ID: <1513860129.41.0.213398074469.issue32396@psf.upfronthosting.co.za>


New submission from jabdoa <jan-python at kantert.net>:

This is a follow up to Issue30539. The main issue is that serial ports on windows do not behave like socket on unix. Therefore, pyserial-asyncio cannot use the asyncio socket api.

Can we implement serial_recv and serial_send in asyncio? This would help to create a true platform independent implementation. On Linux and Mac serial_send/recv could probably just call to socket_sendall/recv. On Windows this would map to ProactorEventLoop.send/recv.

----------
components: asyncio
messages: 308869
nosy: asvetlov, jabdoa, yselivanov
priority: normal
severity: normal
status: open
title: Implement method to write/read to serials without blocking on windows with asyncio
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32396>
_______________________________________

From report at bugs.python.org  Thu Dec 21 09:10:43 2017
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 21 Dec 2017 14:10:43 +0000
Subject: [New-bugs-announce] [issue32397] textwrap output may change if you
 wrap a paragraph twice
Message-ID: <1513865443.17.0.213398074469.issue32397@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

If you word-wrap a paragraph twice with textwrap, you may get different results.  Specifically, you *will* get different results when:
* the original text has a line that is too long by one character,
* the last word on the line is the first word in a new sentence, and
* there are two spaces after the period.

The first textwrap will replace the two spaces after the period with a newline; the second textwrap will replace the newline with a single space.

Attached is a test case demonstrating the problem.

It's not a big problem, but it did cause an assertion failure in blurb.  The workaround was to word-wrap all paragraphs twice, which works but is kind of dumb.

----------
components: Library (Lib)
files: textwrap.isnt.stable.py
messages: 308872
nosy: larry
priority: low
severity: normal
status: open
title: textwrap output may change if you wrap a paragraph twice
versions: Python 3.7
Added file: https://bugs.python.org/file47344/textwrap.isnt.stable.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32397>
_______________________________________

From report at bugs.python.org  Thu Dec 21 12:22:59 2017
From: report at bugs.python.org (Eduardo Suarez-Santana)
Date: Thu, 21 Dec 2017 17:22:59 +0000
Subject: [New-bugs-announce] [issue32398] GDAL compilation error
Message-ID: <1513876979.22.0.213398074469.issue32398@psf.upfronthosting.co.za>


New submission from Eduardo Suarez-Santana <e.suarezsantana at gmail.com>:

When compiling GDAL with python support, under certain build chain environment variables, next error may appear when building and linking python extensions (https://www.mail-archive.com/freebsd-ports at freebsd.org/msg41030.html):

/bin/sh: -d: invalid option

See the Github PR for proposed solution.

----------
components: Distutils
messages: 308887
nosy: dstufft, eric.araujo, esuarezsantana
priority: normal
pull_requests: 4857
severity: normal
status: open
title: GDAL compilation error
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32398>
_______________________________________

From report at bugs.python.org  Thu Dec 21 13:49:07 2017
From: report at bugs.python.org (Michael Felt)
Date: Thu, 21 Dec 2017 18:49:07 +0000
Subject: [New-bugs-announce] [issue32399] _uuidmodule.c cannot build on AIX
 - different typedefs of uuid_t, etc..
Message-ID: <1513882147.82.0.213398074469.issue32399@psf.upfronthosting.co.za>


New submission from Michael Felt <michael at felt.demon.nl>:

I was hoping for something simple - as in:

    +1  #define PY_SSIZE_T_CLEAN
    +2
    +3  #include "Python.h"
    +4  #ifndef _AIX
    +5  #include <uuid/uuid.h>
    +6  #else
    +7  #include <uuid.h>
    +8  #endif

However, it dies - instantly.

       11 | static PyObject *
       12 | py_uuid_generate_time_safe(void)
       13 | {
       14 | #ifdef HAVE_UUID_GENERATE_TIME_SAFE
       15 |     uuid_t out;
       16 |     int res;
       17 |
       18 |     res = uuid_generate_time_safe(out);
       19 |     return Py_BuildValue("y#i", (const char *) out, sizeof(out), res);
       20 | #else
       21 |     uuid_t out;
       22 |     uuid_generate_time(out);
       23 |     return Py_BuildValue("y#O", (const char *) out, sizeof(out), Py_None);
       23 +     return _Py_BuildValue_SizeT("y#O", (const char *) out, sizeof(out), (&_Py_NoneStruct));
"/data/prj/python/git/python3-3.7.0.a3/Modules/_uuidmodule.c", line 23.48: 1506-117 (S) Operand must be a scalar type.
       24 | #endif
       25 | }
       26 |

On a linux system I see:

typedef unsigned char uuid_t[16];

while on AIX the typedef is:

/*
 * Universal Unique Identifier (UUID) types.
 */
typedef struct _uuid_t
{
    unsigned32          time_low;
    unsigned16          time_mid;
    unsigned16          time_hi_and_version;
    unsigned8           clock_seq_hi_and_reserved;
    unsigned8           clock_seq_low;
    byte               node[6];
} uuid_t, *uuid_p_t;

So, mentioning this for now - as I do not yet know the module. If someone with intimate knowledge of the current implementation is willing to help me - I'll dabble and learn - and see if we can make it work on AIX as well.

p.s. - guessing on the "Extension Modules" label. If not the right choice, please update.

----------
components: Extension Modules
messages: 308894
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: _uuidmodule.c cannot build on AIX - different typedefs of uuid_t, etc..
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32399>
_______________________________________

From report at bugs.python.org  Thu Dec 21 13:57:05 2017
From: report at bugs.python.org (Lior Cohen)
Date: Thu, 21 Dec 2017 18:57:05 +0000
Subject: [New-bugs-announce] [issue32400] inspect.isdatadescriptor fasle
 negative
Message-ID: <1513882624.99.0.213398074469.issue32400@psf.upfronthosting.co.za>


New submission from Lior Cohen <chnlior at gmail.com>:

According to the c code in Include/descrobject.h

#define PyDescr_IsData(d) (Py_TYPE(d)->tp_descr_set != NULL)

and according to the "data model" chapter,
a data descriptor is an object who has __set__ and /or __delete__.

the "inspect.isdatadescriptor" checks for existence of __get__ and __set__ which IMHO is wrong. an object with __set__/__delete__ only will return falsely False (should be True).  

This is related to @Serhiy Storchaka comment in issue 26103 opened by @Aaron Hall.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 308895
nosy: chnlior, docs at python
priority: normal
severity: normal
status: open
title: inspect.isdatadescriptor  fasle negative
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32400>
_______________________________________

From report at bugs.python.org  Thu Dec 21 14:25:03 2017
From: report at bugs.python.org (YoSTEALTH)
Date: Thu, 21 Dec 2017 19:25:03 +0000
Subject: [New-bugs-announce] [issue32401] No module named '_ctypes'
Message-ID: <1513884303.03.0.213398074469.issue32401@psf.upfronthosting.co.za>


New submission from YoSTEALTH <ritesh at stealthcentral.com>:

I tried to install python3.7.0a3 just to test it out and i keep getting error:

Traceback (most recent call last):
  File "/tmp/psi/Python-3.7.0a3/Lib/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/tmp/psi/Python-3.7.0a3/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/tmp/psi/Python-3.7.0a3/Lib/ensurepip/__main__.py", line 5, in <module>
    sys.exit(ensurepip._main())
  File "/tmp/psi/Python-3.7.0a3/Lib/ensurepip/__init__.py", line 204, in _main
    default_pip=args.default_pip,
  File "/tmp/psi/Python-3.7.0a3/Lib/ensurepip/__init__.py", line 117, in _bootstrap
    return _run_pip(args + [p[0] for p in _PROJECTS], additional_paths)
  File "/tmp/psi/Python-3.7.0a3/Lib/ensurepip/__init__.py", line 27, in _run_pip
    import pip
  File "/tmp/tmpuwh0fjm1/pip-9.0.1-py2.py3-none-any.whl/pip/__init__.py", line 28, in <module>
  File "/tmp/tmpuwh0fjm1/pip-9.0.1-py2.py3-none-any.whl/pip/vcs/mercurial.py", line 9, in <module>
  File "/tmp/tmpuwh0fjm1/pip-9.0.1-py2.py3-none-any.whl/pip/download.py", line 36, in <module>
  File "/tmp/tmpuwh0fjm1/pip-9.0.1-py2.py3-none-any.whl/pip/utils/glibc.py", line 4, in <module>
  File "/tmp/psi/Python-3.7.0a3/Lib/ctypes/__init__.py", line 7, in <module>
    from _ctypes import Union, Structure, Array
ModuleNotFoundError: No module named '_ctypes'
Makefile:1108: recipe for target 'install' failed
make: *** [install] Error 1

System:
Linux (4.10.0-42-generic) 64bit

I have installed 3.6.0 and 3.6.4 without any problems.

----------
components: Installation
messages: 308897
nosy: YoSTEALTH
priority: normal
severity: normal
status: open
title: No module named '_ctypes'
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32401>
_______________________________________

From report at bugs.python.org  Thu Dec 21 15:50:02 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Dec 2017 20:50:02 +0000
Subject: [New-bugs-announce] [issue32402] Coverity: CID 1426868/1426867:
 Null pointer dereferences in textio.c
Message-ID: <1513889402.22.0.213398074469.issue32402@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

The following warning may have been introduced by the commit 507434fd504f3ebc1da72aa77544edc0d73f136e from bpo-15216.

New defect(s) Reported-by: Coverity Scan
Showing 2 of 2 defect(s)


** CID 1426868:  Null pointer dereferences  (NULL_RETURNS)
/Modules/_io/textio.c: 1251 in textiowrapper_change_encoding()

________________________________________________________________________________________________________
*** CID 1426868:  Null pointer dereferences  (NULL_RETURNS)
/Modules/_io/textio.c: 1251 in textiowrapper_change_encoding()
1245             encoding = self->encoding;
1246             if (errors == Py_None) {
1247                 errors = self->errors;
1248             }
1249         }
1250         else if (errors == Py_None) {
>>>     CID 1426868:  Null pointer dereferences  (NULL_RETURNS)
>>>     Assigning: "errors" = null return value from "_PyUnicode_FromId".
1251             errors = _PyUnicode_FromId(&PyId_strict);
1252         }
1253
1254         const char *c_errors = PyUnicode_AsUTF8(errors);
1255         if (c_errors == NULL) {
1256             return -1;

** CID 1426867:  Null pointer dereferences  (NULL_RETURNS)
/Modules/_io/textio.c: 1153 in _io_TextIOWrapper___init___impl()


________________________________________________________________________________________________________
*** CID 1426867:  Null pointer dereferences  (NULL_RETURNS)
/Modules/_io/textio.c: 1153 in _io_TextIOWrapper___init___impl()
1147         }
1148
1149         /* XXX: Failures beyond this point have the potential to leak elements
1150          * of the partially constructed object (like self->encoding)
1151          */
1152
>>>     CID 1426867:  Null pointer dereferences  (NULL_RETURNS)
>>>     Dereferencing a null pointer "errors".
1153         Py_INCREF(errors);
1154         self->errors = errors;
1155         self->chunk_size = 8192;
1156         self->line_buffering = line_buffering;
1157         self->write_through = write_through;
1158         if (set_newline(self, newline) < 0) {

----------
components: IO
messages: 308903
nosy: inada.naoki, vstinner
priority: normal
severity: normal
status: open
title: Coverity: CID 1426868/1426867:  Null pointer dereferences in textio.c
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32402>
_______________________________________

From report at bugs.python.org  Thu Dec 21 16:51:14 2017
From: report at bugs.python.org (Paul Ganssle)
Date: Thu, 21 Dec 2017 21:51:14 +0000
Subject: [New-bugs-announce] [issue32403] date,
 time and datetime alternate constructors should take fast
 construction path
Message-ID: <1513893074.5.0.213398074469.issue32403@psf.upfronthosting.co.za>


New submission from Paul Ganssle <p.ganssle at gmail.com>:

In the addition of the `fromisoformat()` alternate constructor (bpo-15873: https://github.com/python/cpython/pull/4699), I noted that I was able to get some significant speedup by special-casing the `datetime` baseclass in the C code so that it bypasses the Python constructor, by replacing code that looks like this:

    return PyObject_CallFunction(cls, "iii", year, month, day);

With code that looks like this:

    PyObject *result;
    if ( (PyTypeObject *)cls == & PyDateTime_DateType ) {
        result = new_date_ex(year, month, day, (PyTypeObject *)cls);
    } else {
        result = PyObject_CallFunction(cls, "iii", year, month, day);
    }

    return result;

(This is for `date`, but the results are even more striking for `datetime`).

In my initial proof of concept implementation of a `new_date_subclass_ex` method, I've seen (this is not compiled with optimizations on, mind you) speedups for the other constructors as well:

    Old constructor:
    ================
    Class: date
    constructor:        940.5ns
    date.fromordinal:   1544.8ns
    date.fromtimestamp: 1941.9ns

    Class: DateSubclass
    constructor:        1016.6ns
    date.fromordinal:   1760.3ns
    date.fromtimestamp: 2295.3ns


    With fastpath:
    ==============
    Class: date
    constructor:        964.3ns
    date.fromordinal:   997.6ns
    date.fromtimestamp: 1130.2ns

    Class: DateSubclass
    constructor:        1086.9ns
    date.fromordinal:   1818.5ns
    date.fromtimestamp: 2129.9ns

As you can see, this is a fairly significant speedup in the common case with no cost in the unusual case and no change in behavior. I propose that we switch over all the C constructors where it makes sense to do so in date, time and datetime.

I'll have a PR forthcoming soon.

----------
messages: 308907
nosy: belopolsky, p-ganssle
priority: normal
severity: normal
status: open
title: date, time and datetime alternate constructors should take fast construction path
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32403>
_______________________________________

From report at bugs.python.org  Thu Dec 21 16:54:13 2017
From: report at bugs.python.org (Paul Ganssle)
Date: Thu, 21 Dec 2017 21:54:13 +0000
Subject: [New-bugs-announce] [issue32404] fromtimestamp does not call
 __new__ in datetime subclasses
Message-ID: <1513893253.21.0.213398074469.issue32404@psf.upfronthosting.co.za>


New submission from Paul Ganssle <p.ganssle at gmail.com>:

In writing some tests for the alternate date constructors as part of my PR for issue 32403 (https://bugs.python.org/issue32403), I noticed that for `datetime`, the `fromtimestamp` bypasses the `__new__` call on the subclass:

    from datetime import datetime

    args = (2003, 4, 14)
    ts = 1050292800.0           # Equivalent timestamp
    d_ord = 731319              # Equivalent ordinal date


    class DatetimeSubclass(datetime):
        def __new__(cls, *args, **kwargs):
            result = datetime.__new__(cls, *args, **kwargs)
            result.extra = 7
            return result


    base_d = DatetimeSubclass(*args)
    assert isinstance(base_d, DatetimeSubclass)         # Passes
    assert base_d.extra == 7                            # Passes

    ord_d = DatetimeSubclass.fromordinal(d_ord)
    assert isinstance(ord_d, DatetimeSubclass)          # Passes
    assert ord_d.extra == 7                             # Passes

    ts_d = DatetimeSubclass.fromtimestamp(ts)
    assert isinstance(ts_d, DatetimeSubclass)           # Passes
    assert ts_d.extra == 7                              # Fails

Replacing `datetime` with `date` in the above code we don't get a failure, but with `datetime`, it fails with:

    AttributeError: 'DatetimeSubclass' object has no attribute 'extra'

Regardless of the status of 32403, I think this should be fixed (though I can try to fix them both at the same time).

----------
messages: 308908
nosy: belopolsky, p-ganssle
priority: normal
severity: normal
status: open
title: fromtimestamp does not call __new__ in datetime subclasses
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32404>
_______________________________________

From report at bugs.python.org  Thu Dec 21 16:58:48 2017
From: report at bugs.python.org (Ranya)
Date: Thu, 21 Dec 2017 21:58:48 +0000
Subject: [New-bugs-announce] [issue32405] clr: AttributeError: 'module'
 object has no attribute 'AddReference'
Message-ID: <1513893528.75.0.213398074469.issue32405@psf.upfronthosting.co.za>


New submission from Ranya <ranyafafi93 at gmail.com>:

Am trying to use clr.AddReference and clr.AddReferenceToFile to import an assembly, but python(2.7) keeps making this error:

Traceback (most recent call last):
  File "<pyshell#5>", line 1, in <module>
    clr.AddReference("UnityEngine")
AttributeError: 'module' object has no attribute 'AddReference'

Can anyone tell me how to fix this.

----------
assignee: terry.reedy
components: IDLE
messages: 308909
nosy: Rany, terry.reedy
priority: normal
severity: normal
status: open
title: clr: AttributeError: 'module' object has no attribute 'AddReference'
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32405>
_______________________________________

From report at bugs.python.org  Thu Dec 21 18:37:58 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Dec 2017 23:37:58 +0000
Subject: [New-bugs-announce] [issue32406] Doc: The new dataclasses module is
 not documented
Message-ID: <1513899478.4.0.213398074469.issue32406@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

bpo-32214 "Implement PEP 557: Data Classes" added a new dataclasses module and was closed, but the new module is not documented:
https://docs.python.org/dev/library/dataclasses.html

And it's also missing from What's New in Python 3.7:
https://docs.python.org/dev/whatsnew/3.7.html

----------
assignee: docs at python
components: Documentation
messages: 308918
nosy: docs at python, eric.smith, vstinner
priority: normal
severity: normal
status: open
title: Doc: The new dataclasses module is not documented
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32406>
_______________________________________

From report at bugs.python.org  Fri Dec 22 00:49:46 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 22 Dec 2017 05:49:46 +0000
Subject: [New-bugs-announce] [issue32407] lib2to3 doesn't work when zipped
Message-ID: <1513921786.02.0.213398074469.issue32407@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

2to3 pokes around on the file system to find the grammar files it needs in source or pickled form. This makes it not work if lib2to3 is running from a zip file. lib2to3 should use pkgutil.get_data() instead to load grammar files.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 308923
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: lib2to3 doesn't work when zipped
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32407>
_______________________________________

From report at bugs.python.org  Fri Dec 22 01:14:04 2017
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 22 Dec 2017 06:14:04 +0000
Subject: [New-bugs-announce] [issue32408] Performance regression in
 urllib.proxy_bypass_environment
Message-ID: <1513923244.99.0.213398074469.issue32408@psf.upfronthosting.co.za>


New submission from Xiang Zhang <angwerzx at 126.com>:

Recently we update our environment from Python2.7.5 to Python2.7.13. Then one process's CPU usage grow from 15% to 70%. The cause is urllib.proxy_bypass_environment, the commit I wrote in #26864. Our environments get a no_proxy environment variable which contains 4000+ items. See the performance difference:

cascading-controller:~ # time python2 -c 'import urllib; urllib.proxy_bypass_environment("1.1.1.1")'

real	0m1.134s
user	0m1.126s
sys	0m0.007s
cascading-controller:~ # time python2 -c 'import urllib; urllib.proxy_bypass_environment("1.1.1.1")'

real	0m0.037s
user	0m0.024s
sys	0m0.013s

Temporarily I increased regex cache size to 6000 and the CPU usage and time return to a reasonable range.

----------
components: Library (Lib)
messages: 308924
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: Performance regression in urllib.proxy_bypass_environment
type: performance
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32408>
_______________________________________

From report at bugs.python.org  Fri Dec 22 05:36:15 2017
From: report at bugs.python.org (Jaakko Roponen)
Date: Fri, 22 Dec 2017 10:36:15 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue32409=5D_venv_activation_d?=
 =?utf-8?q?oesn=27t_work=2C_if_project_is_in_a_Windows_folder_that_has_lat?=
 =?utf-8?b?aW4tMSBzdXBwbGVtZW50IGNoYXJhY3RlcnMgKHN1Y2ggYXMgw6Qsw7Ysw6Up?=
 =?utf-8?q?_in_its_path?=
Message-ID: <1513938975.69.0.213398074469.issue32409@psf.upfronthosting.co.za>


New submission from Jaakko Roponen <roponenjaakko at gmail.com>:

Let's say I have a folder c:\test-? in Windows

Now if I run: py -m venv env
and activate: env\scripts\activate
and check: where python

the result is incorrectly just: C:\Users\Username\AppData\Local\Programs\Python\Python36\python.exe

If I run: path 
the result is: PATH=C:\test-??\env\Scripts;...

So clearly the encoding is broken for the folder name.

I can fix this by changing activate.bat character encoding to OEM-US and then replacing "test-??" by "test-?".

If I now activate and run: where python
the result is (as should be): 
C:\test-?\env\Scripts\python.exe
C:\Users\Username\AppData\Local\Programs\Python\Python36\python.exe

By running: path
I get: PATH=C:\test-?\env\Scripts;...

So looks good here as well.

I suggest that what ever is creating activate.bat file, is using incorrect character encoding for the creation of the file. If this is somehow platform specific, there could be a guide in the venv documentation about how to fix this.

----------
components: Extension Modules
messages: 308931
nosy: Jac0
priority: normal
severity: normal
status: open
title: venv activation doesn't work, if project is in a Windows folder that has latin-1 supplement characters (such as ?,?,?) in its path
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32409>
_______________________________________

From report at bugs.python.org  Fri Dec 22 08:07:13 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 22 Dec 2017 13:07:13 +0000
Subject: [New-bugs-announce] [issue32410] Implement loop.sock_sendfile method
Message-ID: <1513948033.17.0.213398074469.issue32410@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

The method should be low-level coroutine, implemented on loops with native sendfile support only (UnixEventLoop).

The signature should be close to socket.sendfile() method

Next step is implementing loop.sendfile(transport, ...) with fallback to sending by chunks if sendfile is not supported.

----------
components: Library (Lib), asyncio
messages: 308932
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Implement loop.sock_sendfile method
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32410>
_______________________________________

From report at bugs.python.org  Fri Dec 22 21:41:09 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Dec 2017 02:41:09 +0000
Subject: [New-bugs-announce] [issue32411] Idlelib.browser: stop sorting
 dicts created by pyclbr
Message-ID: <1513996869.13.0.213398074469.issue32411@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

pyclbr does a linear scan of a file and returns a dict, and Class objects have a dict of children. For objects in the file being scanned, insertion order is the same as line number order.  idlelib.browser.transform children filters out objects not in the file, changes the .name of some objects in the file, appends to a list, and sorts by line number.  (I should have done the sort in place.)  For insertion order dicts, the sort does nothing. In 3.7, insertion order is a language guarantee, not just a (current) CPython implementation detail.  The sort does not change the order and is therefore no longer needed. We can reduce
    return sorted(obs, key=lambda o: o.lineno)
to
    return obs

However, I do want to make sure that there is at least one test that will break if there is a bug somewhere.

----------
assignee: terry.reedy
components: IDLE
messages: 308945
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Idlelib.browser: stop sorting dicts created by pyclbr
type: performance
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32411>
_______________________________________

From report at bugs.python.org  Fri Dec 22 23:35:29 2017
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 23 Dec 2017 04:35:29 +0000
Subject: [New-bugs-announce] [issue32412] help() of bitwise operators should
 mention sets as well
Message-ID: <1514003729.76.0.213398074469.issue32412@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve+python at pearwood.info>:

If you ask for help on the set operators ^ & and | then help docs only talk about them as bitwise operators.

Since sets and frozensets are important, built-in types, the help should mention them as well.

----------
assignee: docs at python
components: Documentation
messages: 308946
nosy: docs at python, steven.daprano
priority: normal
severity: normal
status: open
title: help() of bitwise operators should mention sets as well
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32412>
_______________________________________

From report at bugs.python.org  Sat Dec 23 00:52:42 2017
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 23 Dec 2017 05:52:42 +0000
Subject: [New-bugs-announce] [issue32413] Document that locals() may return
 globals()
Message-ID: <1514008362.41.0.213398074469.issue32413@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve+python at pearwood.info>:

The obvious documentation for locals() fails to mention that when called from the top level of a module (outside of a function or class body) it returns the same dict as globals().

https://docs.python.org/2/library/functions.html#locals

----------
assignee: docs at python
components: Documentation
messages: 308947
nosy: docs at python, steven.daprano
priority: normal
severity: normal
status: open
title: Document that locals() may return globals()
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32413>
_______________________________________

From report at bugs.python.org  Sat Dec 23 04:47:09 2017
From: report at bugs.python.org (lekma)
Date: Sat, 23 Dec 2017 09:47:09 +0000
Subject: [New-bugs-announce] [issue32414] PyCapsule_Import fails when name
 is in the form 'package.module.capsule'
Message-ID: <1514022429.41.0.213398074469.issue32414@psf.upfronthosting.co.za>


New submission from lekma <lekmalek at gmail.com>:

When capsule name is in the form 'package.module.capsule', PyCapsule_Import fails with an AttributeError (module is never an attribute of package).

----------
components: Interpreter Core
messages: 308950
nosy: lekma
priority: normal
severity: normal
status: open
title: PyCapsule_Import fails when name is in the form 'package.module.capsule'
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32414>
_______________________________________

From report at bugs.python.org  Sat Dec 23 11:59:11 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 23 Dec 2017 16:59:11 +0000
Subject: [New-bugs-announce] [issue32415] Add Task.get_loop() and
 Future.get_loop()
Message-ID: <1514048351.13.0.213398074469.issue32415@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

Currently, asyncio code accesses Future._loop and Task._loop property to validate the event loop and implement functions like "Task.all_tasks()".  So the "_loop" is a semi-official public API that other Task & Future implementations must follow in order to be compatible with asyncio code.

I propose to add Future.get_loop() and Task.get_loop() methods, and soft-deprecate ._loop property.

----------
assignee: yselivanov
components: asyncio
messages: 308957
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Add Task.get_loop() and Future.get_loop()
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32415>
_______________________________________

From report at bugs.python.org  Sat Dec 23 12:14:03 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 23 Dec 2017 17:14:03 +0000
Subject: [New-bugs-announce] [issue32416] Refactor and add new tests for the
 f_lineno setter
Message-ID: <1514049243.28.0.213398074469.issue32416@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Proposed PR refactors existing tests for the f_lineno setter and adds few new tests. This will help to avoid regressions in issue17611.

I have found that some illegal jumps are not prohibited. They can lead to crashes or weird behavior. For example jumps to or from the bare except block. This will be fixed in a separate issue.

----------
components: Tests
messages: 308959
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Refactor and add new tests for the f_lineno setter
type: enhancement
versions: Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32416>
_______________________________________

From report at bugs.python.org  Sat Dec 23 13:15:39 2017
From: report at bugs.python.org (Paul Ganssle)
Date: Sat, 23 Dec 2017 18:15:39 +0000
Subject: [New-bugs-announce] [issue32417] fromutc does not respect datetime
 subclasses
Message-ID: <1514052939.19.0.213398074469.issue32417@psf.upfronthosting.co.za>


New submission from Paul Ganssle <p.ganssle at gmail.com>:

When preparing some tests for how subclasses of date and datetime react as part of a fix for issue 32403, I noticed a fairly big example of where subclass is not preserved - `tzinfo.fromutc`:

    from datetime import datetime, timezone

    class DateTimeSubclass(datetime):
        pass

    dt = DateTimeSubclass(2012, 1, 1)
    dt2 = dt.astimezone(timezone.utc)

    print(type(dt))
    print(type(dt2))

    # Result:
    # <class '__main__.DateTimeSubclass'>
    # <class 'datetime.datetime'>

This also affects `datetime.fromtimestamp` and `datetime.now`, since both of these, when passed a time zone argument, will call `fromutc` internally. I personally think that Python's `tzinfo.fromutc` should preserve the object's class, but this *is* counter to the current API.

And either way, it's quite inconsistent to have `DateTimeSubclass.now()` return `DateTimeSubclass` but have `DateTimeSubclass.now(timezone.utc)` return `datetime.datetime`.

There is probably a somewhat inelegant way to get the alternate constructors working properly (ignore the type of the argument up until the last return and then construct the subclass from the components of the datetime), but I think it might be better to fix the behavior of tzinfo.fromutc.

Somewhat related to issue 32404 and 31222, in that this concerns which operations preserve type in subclasses.

----------
messages: 308961
nosy: belopolsky, p-ganssle
priority: normal
severity: normal
status: open
title: fromutc does not respect datetime subclasses
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32417>
_______________________________________

From report at bugs.python.org  Sat Dec 23 14:10:59 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 23 Dec 2017 19:10:59 +0000
Subject: [New-bugs-announce] [issue32418] Implement Server.get_loop() method
Message-ID: <1514056259.94.0.213398074469.issue32418@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Future and Task will have the method (bpo-32415)
AbstractServer and Server should support it too.

----------
components: Library (Lib), asyncio
messages: 308963
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Implement Server.get_loop() method
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32418>
_______________________________________

From report at bugs.python.org  Sat Dec 23 16:26:00 2017
From: report at bugs.python.org (Bassem Girgis)
Date: Sat, 23 Dec 2017 21:26:00 +0000
Subject: [New-bugs-announce] [issue32419] Add unittest support for pyc
 projects
Message-ID: <1514064360.62.0.213398074469.issue32419@psf.upfronthosting.co.za>


New submission from Bassem Girgis <brgirgis at gmail.com>:

This PR makes it possible to "unittest" projects that are all pyc with no __init__.py which is hardcoded in few checks in unittest.loader

----------
components: Extension Modules
messages: 308970
nosy: brgirgis
priority: normal
pull_requests: 4888
severity: normal
status: open
title: Add unittest support for pyc projects
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32419>
_______________________________________

From report at bugs.python.org  Sat Dec 23 21:20:37 2017
From: report at bugs.python.org (Kaoru Kitamura)
Date: Sun, 24 Dec 2017 02:20:37 +0000
Subject: [New-bugs-announce] [issue32420] LookupError : unknown encoding :
 [0x7FF092395AD0] ANOMALY
Message-ID: <1514082037.96.0.213398074469.issue32420@psf.upfronthosting.co.za>


New submission from Kaoru Kitamura <kkaoru1981 at gmail.com>:

I tried to activate tensorflow after creating tensorflow environment with Anaconda Prompt.
Then, Python clashed in fatal error as attached.

I searched this kind of issues and made environment variable for UTF-8 , but it did not work.

Does anyone have any suggestions?

----------
components: Windows
files: error_capture.png
messages: 308977
nosy: Kitamura, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: LookupError : unknown encoding : [0x7FF092395AD0] ANOMALY
type: crash
versions: Python 3.6
Added file: https://bugs.python.org/file47346/error_capture.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32420>
_______________________________________

From report at bugs.python.org  Sat Dec 23 21:27:03 2017
From: report at bugs.python.org (Yonatan Zunger)
Date: Sun, 24 Dec 2017 02:27:03 +0000
Subject: [New-bugs-announce] [issue32421] Keeping an exception in cache can
 segfault the interpreter
Message-ID: <1514082423.32.0.213398074469.issue32421@psf.upfronthosting.co.za>


New submission from Yonatan Zunger <zunger at gmail.com>:

Using the following decorator to memoize a function causes the interpreter to segfault on exit if any exceptions were stored in the cache. Changing the bad line to instead store copy.copy(e) makes the problem go away.

Almost certainly some kind of problem with the GC of the traceback not happening at the moment the interpreter expects it, but I haven't had time to investigate any more deeply yet.

def memoize(keyFunc=lambda x: x, cacheExceptions: bool=True):
    def wrapper(func):
        return _Memo(func, keyFunc, cacheExceptions)
    return wrapper

class _Memo(object):
    def __init__(self, func, keyFunc, cacheExceptions: bool) -> None:
        self.func = func
        self.keyFunc = keyFunc
        self.cacheExceptions = cacheExceptions
        self.lock = threading.Lock()
        self.cache = {}

    def __call__(self, *args, **kwargs) -> Any:
        key = self.keyFunc(*args, **kwargs)
        assert isinstance(key, collections.Hashable)
        with self.lock:
            if key in self.cache:
                value = self.cache[key]
                if isinstance(value, BaseException):
                    raise value
                return value

        try:
            result = self.func(*args, **kwargs)
        except BaseException as e:
            if self.cacheExceptions:
                with self.lock:
                    self.cache[key] = e   # BAD LINE
            six.reraise(*sys.exc_info())
        else:
            with self.lock:
                self.cache[key] = result
            return result

----------
components: Interpreter Core
messages: 308978
nosy: zunger
priority: normal
severity: normal
status: open
title: Keeping an exception in cache can segfault the interpreter
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32421>
_______________________________________

From report at bugs.python.org  Sun Dec 24 00:19:02 2017
From: report at bugs.python.org (INADA Naoki)
Date: Sun, 24 Dec 2017 05:19:02 +0000
Subject: [New-bugs-announce] [issue32422] Make OrderedDict can be used for
 LRU from C
Message-ID: <1514092742.06.0.213398074469.issue32422@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

Currently, functools.lru_cache implement own doubly-linked list.

But it is inefficient than OrderedDict because each link node is GC object.
So it may eat more memory and take longer GC time.

I added two private C API for OrderedDict and make lru_cache use it.

* _PyODict_LRUGetItem(): Similar to PyDict_GetItemWithHash() + od.move_to_end(last=True).
* _PyODict_PopItem():  Similar to odict.popitem().

Why I didn't implement C version of move_to_end() is to reduce lookup.
 _PyODict_LRUGetItem(key) lookup key once while
od[key]; od.move_to_end(key) lookup key twice.

I'll benchmark it and report result here.

----------
components: Interpreter Core
messages: 308980
nosy: inada.naoki
priority: normal
severity: normal
status: open
title: Make OrderedDict can be used for LRU from C
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32422>
_______________________________________

From report at bugs.python.org  Sun Dec 24 00:40:15 2017
From: report at bugs.python.org (Isuru Fernando)
Date: Sun, 24 Dec 2017 05:40:15 +0000
Subject: [New-bugs-announce] [issue32423] The Windows SDK version
 10.0.15063.0 was not found
Message-ID: <1514094015.43.0.213398074469.issue32423@psf.upfronthosting.co.za>


New submission from Isuru Fernando <isuruf at gmail.com>:

When compiling python 3.6.4 on appveyor using MSVC 2015 following error occurs.

(C:\bld\python_1514037886491\_b_env) C:\bld\python_1514037886491\work\Python-3.6.4\PCbuild>"C:\Program Files (x86)\MSBuild\14.0\Bin\amd64\MSBuild.exe"  "C:\bld\python_1514037886491\work\Python-3.6.4\PCbuild\pcbuild.proj" /t:Build /m /nologo /v:m /p:Configuration=Release /p:Platform=x64 /p:IncludeExternals=true /p:IncludeSSL=true /p:IncludeTkinter=true /p:UseTestMarker= /p:GIT="C:\Program Files\Git\cmd\git.exe"          
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\x64\PlatformToolsets\v140\Toolset.targets(36,5): error MSB8036: The Windows SDK version 10.0.15063.0 was not found. Install the required version of Windows SDK or change the SDK version in the project property pages or by right-clicking the solution and selecting "Retarget solution". [C:\bld\python_1514037886491\work\Python-3.6.4\PCbuild\pythoncore.vcxproj]

Note that appveyor Visual Studio 2015 image has only 10.0.10586, 10.0.14393 and 10.0.26624

Here's a simple patch that fixes this on 3.6 branch. 
https://github.com/isuruf/cpython/commit/9432a2c7f63b3bb55e8066e91eade81321154476
I haven't checked that the patch works on a machine with 10.0.15063

----------
components: Windows
messages: 308982
nosy: Isuru Fernando, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: The Windows SDK version 10.0.15063.0 was not found
type: compile error
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32423>
_______________________________________

From report at bugs.python.org  Sun Dec 24 13:51:40 2017
From: report at bugs.python.org (Gordon P. Hemsley)
Date: Sun, 24 Dec 2017 18:51:40 +0000
Subject: [New-bugs-announce] [issue32424] Rename copy() to __copy__() in
 xml.etree.ElementTree.Element Python implementation
Message-ID: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za>


New submission from Gordon P. Hemsley <gphemsley at gphemsley.org>:

Currently, the Python implementation of the Element class in xml.etree.ElementTree defines a method called copy() which the C implementation does not define, whereas the C implementation defines a __copy__() method (and a __deepcopy__() method) which the Python implementation does not define.

Given that the documentation makes no mention of a copy() method and that its definition would be masked by a standard import of xml.etree.ElementTree, I propose that it be renamed to __copy__() so that copy.copy() can make use of it.

----------
components: Library (Lib), XML
messages: 309010
nosy: eli.bendersky, gphemsley, scoder
priority: normal
severity: normal
status: open
title: Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32424>
_______________________________________

From report at bugs.python.org  Sun Dec 24 14:08:23 2017
From: report at bugs.python.org (Gordon P. Hemsley)
Date: Sun, 24 Dec 2017 19:08:23 +0000
Subject: [New-bugs-announce] [issue32425] Allow non-default XML parsers to
 take advantage of a _parse_whole definition in
 xml.etree.ElementTree.ElementTree.parse()
Message-ID: <1514142503.5.0.213398074469.issue32425@psf.upfronthosting.co.za>


New submission from Gordon P. Hemsley <gphemsley at gphemsley.org>:

Currently, ElementTree.parse() in xml.etree.ElementTree only invokes _parse_whole() on the parser if no parser is specified and it falls back to the built-in XMLParser.

This has two drawbacks:
* If the built-in XMLParser is specified explicitly, it does not get the advantage of using its _parse_whole() method.
* If another XML parser is specified, it does not have the option to define a _parse_whole() method.

In both cases, the parser parses in chunks (of 16 KiB), which is potentially slower.

I propose allowing any parser to take advantage of _parse_whole() if it has defined such a method. (This would also have the benefit of eliminating some minor code duplication--two return branches could become one.)

----------
components: Library (Lib), XML
messages: 309011
nosy: eli.bendersky, gphemsley, scoder
priority: normal
severity: normal
status: open
title: Allow non-default XML parsers to take advantage of a _parse_whole definition in xml.etree.ElementTree.ElementTree.parse()
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32425>
_______________________________________

From report at bugs.python.org  Mon Dec 25 17:37:11 2017
From: report at bugs.python.org (Alessandro Piccione)
Date: Mon, 25 Dec 2017 22:37:11 +0000
Subject: [New-bugs-announce] [issue32426] Tkinter.ttk Widget does not define
 wich option exists to set the cursor
Message-ID: <1514241431.48.0.213398074469.issue32426@psf.upfronthosting.co.za>


New submission from Alessandro Piccione <alessandro.piccione.75 at gmail.com>:

In the documentation of Tkinter.ttk Widget it is defined the "cursor" parameter. It is:
cursor	
Specifies the mouse cursor to be used for the widget. If set to the empty string (the default), the cursor is inherited for the parent widget.

There is not ANY way to knok wich value this parameter accept.
Searching "cursor" in the documentation does not find nothing, apart database cursor and this page (Tkinter.ttk.Widget).

Thanks,

Alessandro

----------
components: Tkinter
messages: 309045
nosy: alex.75
priority: normal
severity: normal
status: open
title: Tkinter.ttk Widget does not define wich option exists to set the cursor
type: resource usage
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32426>
_______________________________________

From report at bugs.python.org  Tue Dec 26 07:43:46 2017
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 26 Dec 2017 12:43:46 +0000
Subject: [New-bugs-announce] [issue32427] Rename and expose
 dataclasses._MISSING
Message-ID: <1514292226.17.0.213398074469.issue32427@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

There are occasions where you want to know the missing value, such as introspection and in cases like: Field(default=a if a is not None else _MISSING).

I'll rename _MISSING to MISSING.

----------
assignee: eric.smith
components: Library (Lib)
messages: 309063
nosy: eric.smith
priority: normal
severity: normal
status: open
title: Rename and expose dataclasses._MISSING
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32427>
_______________________________________

From report at bugs.python.org  Tue Dec 26 13:34:08 2017
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 26 Dec 2017 18:34:08 +0000
Subject: [New-bugs-announce] [issue32428] dataclasses: make it an error to
 have initialized non-fields in a dataclass
Message-ID: <1514313248.8.0.213398074469.issue32428@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

For this class:

@dataclass
class C:
   x: int = 0
   y = 0

Generate a TypeError. 'y' is not a field (as defined by @dataclass). It should either be a regular field (by giving it a type annotation) or a ClassVar field.

----------
assignee: eric.smith
components: Library (Lib)
messages: 309065
nosy: eric.smith
priority: normal
severity: normal
status: open
title: dataclasses: make it an error to have initialized non-fields in a dataclass
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32428>
_______________________________________

From report at bugs.python.org  Tue Dec 26 17:10:38 2017
From: report at bugs.python.org (Julien Palard)
Date: Tue, 26 Dec 2017 22:10:38 +0000
Subject: [New-bugs-announce] [issue32429] Outdated Modules/Setup warning is
 invisible
Message-ID: <1514326238.69.0.213398074469.issue32429@psf.upfronthosting.co.za>


New submission from Julien Palard <julien+python at palard.fr>:

The devguide advise to run `make -j`, why not, but in any cases between `make -j4` and `make -j` the warning:

    -----------------------------------------------
    Modules/Setup.dist is newer than Modules/Setup;
    check to make sure you have all the updates you
    need in your Modules/Setup file.
    Usually, copying Modules/Setup.dist to Modules/Setup will work.
    -----------------------------------------------

is invisible (gets on screen first, and get kicked real quick by the compilation lines).

This got me once, and I'm not alone: https://bugs.python.org/issue32335 (And I suspect we're more than just two).

I propose to make this stop the compilation, proposing two cases:

- You modified the file? Touch it so it gets seen as up to date by makefile
- You didn't modified it? Copy Modules/Setup.dist to Modules/Setup

Something like:

    $ make
    -----------------------------------------------
    Modules/Setup.dist is newer than Modules/Setup;
    check to make sure you have all the updates you
    need in your Modules/Setup file.
    Usually, copying Modules/Setup.dist to Modules/Setup will work.
    Or if you want to keep your modifications, touch Modules/Setup
    to skip this warning.
    -----------------------------------------------
    Makefile:703: recipe for target 'Modules/Setup' failed
    make: *** [Modules/Setup] Error 1

----------
assignee: mdk
components: Build
messages: 309066
nosy: mdk, xdegaye
priority: low
severity: normal
status: open
title: Outdated Modules/Setup warning is invisible
type: enhancement
versions: Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32429>
_______________________________________

From report at bugs.python.org  Wed Dec 27 06:15:03 2017
From: report at bugs.python.org (Julien Palard)
Date: Wed, 27 Dec 2017 11:15:03 +0000
Subject: [New-bugs-announce] [issue32430] Simplify Modules/Setup{, .dist,
 .local}
Message-ID: <1514373303.98.0.213398074469.issue32430@psf.upfronthosting.co.za>


New submission from Julien Palard <julien+python at palard.fr>:

Related to: https://bugs.python.org/issue32429 

The bahavior of Modules/Setup{,.dist,.local} looks inherited from an old time:

- A Setup.dist exist
- ./configure copies it to Setup (cp $srcdir/Modules/Setup.dist Modules/Setup)
- ./configure installs a dummy Modules/Setup.local file
- One can add an optional things to Setup.local
- One can have to modify Setup itself (to modify things)

>From this point in time, Setup is newer than Setup.dist (as copied from it), the following can happen:

- The Setup file is manually modified, it's still newer than Setup.dist, it does not change the situation
- The Setup.dist file gets updated (via a git checkout or git merge), the Makefile detects it and warn the user:
  - Either the user modified the Setup file and don't want it to be overridden
  - Either the user didn't modified it and just want the updated version

We don't know, so the Makefile is printing a warning telling he don't know and we have to fix the situation. First problem is: this warning is invisible due to the high load of Makefile prints, this is the issue https://bugs.python.org/issue32429.

Proposed solutions are:

- Xavier de Gaye: Use Setup.dist instead of Setup when Setup is missing (https://bugs.python.org/issue32429#msg309078)
- Just keep a single versionned Setup file, let those who modify it use branches to commit their modifications

Marc-Andre Lemburg noted that for those using a sources tarballs, in the single Setup file case, it's not nice for them to loose the original content of Setup when modifying it, and being able to do a `cp Modules/Setup.dist Modules/Setup` to restore it is nice.

Personally I'll go for a single Setup file (No .dist, no .local, no copy), that one can modify and commit, delegating the pain of merging to git, as I prefer simple solutions.

I don't think the importance of keeping a ".dist" backup is worth the pain and we're not doing it for other files (If one using a source tarball is modifying a .c file, the original content is lost too, and we'll not provide .c.dist files).

----------
messages: 309079
nosy: mdk
priority: normal
severity: normal
status: open
title: Simplify Modules/Setup{,.dist,.local}

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32430>
_______________________________________

From report at bugs.python.org  Wed Dec 27 10:17:14 2017
From: report at bugs.python.org (Jonathan Underwood)
Date: Wed, 27 Dec 2017 15:17:14 +0000
Subject: [New-bugs-announce] [issue32431] Two bytes objects of zero length
 don't compare equal
Message-ID: <1514387834.13.0.213398074469.issue32431@psf.upfronthosting.co.za>


New submission from Jonathan Underwood <jonathan.underwood at gmail.com>:

With the current logic in Objects/bytesobject.c in the function bytes_compare_eq it can be the case that zero length bytes object object created in an extension module like this:

val = PyBytes_FromStringAndSize (NULL, 20);
Py_SIZE(val) = 0;

won't compare equal to b'' because the memory is not initialized, so the first two bytes won't be equal. Nonetheless, the Python interpreter does return b'' for print(repr(val)), so this behaviour is very confusing. To get the correct behaviour, one would have to initialize the memory:

val = PyBytes_FromStringAndSize (NULL, 20);
c = PyBytes_AS_STRING (val);
c[0] = '\0';
Py_SIZE(val) = 0;

However, it would be more sensible to fix the logic in bytes_compare_eq in my opinion. That function should return true for two zero length bytes objects, irrespective of the memory contents.

----------
components: Interpreter Core
messages: 309086
nosy: jonathanunderwood
priority: normal
severity: normal
status: open
title: Two bytes objects of zero length don't compare equal
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32431>
_______________________________________

From report at bugs.python.org  Wed Dec 27 12:26:56 2017
From: report at bugs.python.org (Felipe Filgueira Barral)
Date: Wed, 27 Dec 2017 17:26:56 +0000
Subject: [New-bugs-announce] [issue32432] [BUG] Python vs Macbook High
 Sierra 10.13.2
Message-ID: <1514395616.6.0.213398074469.issue32432@psf.upfronthosting.co.za>


New submission from Felipe Filgueira Barral <felipefb15 at gmail.com>:

When i open the IDLE and try include ' or " in any script, the python closes alone! Does anyone know what might be happening? I use mac, version high sierra...

Process: Python [1048]
Path: /Applications/Python 3.6/IDLE.app/Contents/MacOS/Python
Identifier: org.python.IDLE
Version: 3.6.4 (3.6.4)
Code Type: X86 (Native)
Parent Process: ??? [1]
Responsible: Python [1048]
User ID: 501

Date/Time: 2017-12-27 14:12:58.552 -0200
OS Version: Mac OS X 10.13.2 (17C88)
Report Version: 12
Anonymous UUID: 0681CD4F-4E3E-670B-B04B-6F062C271803

Time Awake Since Boot: 3800 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Illegal instruction: 4
Termination Reason: Namespace SIGNAL, Code 0x4
Terminating Process: exc handler [0]

Application Specific Information:
*** Terminating app due to uncaught exception 'NSRangeException', reason: '-[__NSCFConstantString characterAtIndex:]: Range or index out of bounds'

Application Specific Backtrace 1:
0 CoreFoundation 0x93a5f0e2 __raiseError + 178
1 libobjc.A.dylib 0xa6aaa346 objc_exception_throw + 273
2 CoreFoundation 0x93a5f005 +[NSException raise:format:] + 101
3 CoreFoundation 0x9394de6d -[__NSCFString characterAtIndex:] + 93
4 Tk 0x9d5c486a TkpInitKeymapInfo + 609
5 Tk 0x9d5c0cb7 TkpRedirectKeyEvent + 1098
6 Tk 0x9d5ca1f6 Tk_MacOSXSetupTkNotifier + 744
7 Tcl 0x9d4ca37e Tcl_DoOneEvent + 269
8 _tkinter.cpython-36m-darwin.so 0x003ee679 _tkinter_tkapp_mainloop + 233
9 Python 0x0006c566 _PyCFunction_FastCallDict + 582
10 Python 0x000f5e75 call_function + 629
11 Python 0x000fbd89 _PyEval_EvalFrameDefault + 23241
12 Python 0x000f51bf _PyEval_EvalCodeWithName + 2367
13 Python 0x000f59f9 fast_function + 249
14 Python 0x000f5e50 call_function + 592
15 Python 0x000fbd89 _PyEval_EvalFrameDefault + 23241
16 Python 0x000f51bf _PyEval_EvalCodeWithName + 2367
17 Python 0x000f59f9 fast_function + 249
18 Python 0x000f5e50 call_function + 592
19 Python 0x000fbd89 _PyEval_EvalFrameDefault + 23241
20 Python 0x000f51bf _PyEval_EvalCodeWithName + 2367
21 Python 0x000f5383 PyEval_EvalCode + 115
22 Python 0x0013090e PyRun_FileExFlags + 206
23 Python 0x00130c39 PyRun_SimpleFileExFlags + 505
24 Python 0x0014b3fb Py_Main + 4139
25 Python 0x00001e62 main + 498
26 Python 0x00001c65 start + 53
27 ??? 0x00000002 0x0 + 2

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.apple.CoreFoundation 0x93a5f3e3 TERMINATING_DUE_TO_UNCAUGHT_EXCEPTION + 3
1 com.apple.CoreFoundation 0x93a5f381 __raiseError + 849
2 libobjc.A.dylib 0xa6aaa346 objc_exception_throw + 273
3 com.apple.CoreFoundation 0x93a5f005 +[NSException raise:format:] + 101
4 com.apple.CoreFoundation 0x9394de6d -[__NSCFString characterAtIndex:] + 93
5 Tk 0x9d5c486a 0x9d518000 + 706666
6 Tk 0x9d5c0cb7 0x9d518000 + 691383
7 Tk 0x9d5ca1f6 0x9d518000 + 729590
8 Tcl 0x9d4ca37e Tcl_DoOneEvent + 269
9 _tkinter.cpython-36m-darwin.so	0x003ee679 _tkinter_tkapp_mainloop + 233
10 org.python.python 0x0006c566 _PyCFunction_FastCallDict + 582
11 org.python.python 0x000f5e75 call_function + 629
12 org.python.python 0x000fbd89 _PyEval_EvalFrameDefault + 23241
13 org.python.python 0x000f51bf _PyEval_EvalCodeWithName + 2367
14 org.python.python 0x000f59f9 fast_function + 249
15 org.python.python 0x000f5e50 call_function + 592
16 org.python.python 0x000fbd89 _PyEval_EvalFrameDefault + 23241
17 org.python.python 0x000f51bf _PyEval_EvalCodeWithName + 2367
18 org.python.python 0x000f59f9 fast_function + 249
19 org.python.python 0x000f5e50 call_function + 592
20 org.python.python 0x000fbd89 _PyEval_EvalFrameDefault + 23241
21 org.python.python 0x000f51bf _PyEval_EvalCodeWithName + 2367
22 org.python.python 0x000f5383 PyEval_EvalCode + 115
23 org.python.python 0x0013090e PyRun_FileExFlags + 206
24 org.python.python 0x00130c39 PyRun_SimpleFileExFlags + 505
25 org.python.python 0x0014b3fb Py_Main + 4139
26 Python 0x00001e62 main + 498
27 Python 0x00001c65 start + 53

Thread 1:
0 libsystem_kernel.dylib 0xa76ad6ee __workq_kernreturn + 10
1 libsystem_pthread.dylib 0xa77dae70 _pthread_wqthread + 992
2 libsystem_pthread.dylib 0xa77daa6a start_wqthread + 34

Thread 2:
0 libsystem_kernel.dylib 0xa76ad6ee __workq_kernreturn + 10
1 libsystem_pthread.dylib 0xa77db090 _pthread_wqthread + 1536
2 libsystem_pthread.dylib 0xa77daa6a start_wqthread + 34

Thread 3:
0 libsystem_kernel.dylib 0xa76ad07e __select + 10
1 Tcl 0x9d4fa09e 0x9d454000 + 680094
2 libsystem_pthread.dylib 0xa77db50d _pthread_body + 347
3 libsystem_pthread.dylib 0xa77db3b2 _pthread_start + 357
4 libsystem_pthread.dylib 0xa77daa8e thread_start + 34

Thread 4:: com.apple.NSEventThread
0 libsystem_kernel.dylib 0xa76a3742 mach_msg_trap + 10
1 libsystem_kernel.dylib 0xa76a2d7f mach_msg + 47
2 com.apple.CoreFoundation 0x9394d3b8 __CFRunLoopServiceMachPort + 296
3 com.apple.CoreFoundation 0x9394c3a6 __CFRunLoopRun + 2262
4 com.apple.CoreFoundation 0x9394b7a1 CFRunLoopRunSpecific + 641
5 com.apple.CoreFoundation 0x9394b50a CFRunLoopRunInMode + 122
6 com.apple.AppKit 0x914a1614 _NSEventThread + 165
7 libsystem_pthread.dylib 0xa77db50d _pthread_body + 347
8 libsystem_pthread.dylib 0xa77db3b2 _pthread_start + 357
9 libsystem_pthread.dylib 0xa77daa8e thread_start + 34

Thread 5:
0 libsystem_kernel.dylib 0xa76ad6ee __workq_kernreturn + 10
1 libsystem_pthread.dylib 0xa77dae9b _pthread_wqthread + 1035
2 libsystem_pthread.dylib 0xa77daa6a start_wqthread + 34

Thread 6:
0 libsystem_pthread.dylib 0xa77daa48 start_wqthread + 0
1 org.python.python 0x00040003 PyFloat_GetInfo + 275

Thread 0 crashed with X86 Thread State (32-bit):
eax: 0x5ad6001b ebx: 0x0059e590 ecx: 0x00000000 edx: 0x00000000
edi: 0x93a5f03e esi: 0x01416400 ebp: 0xbfffe1d8 esp: 0xbfffe1d8
ss: 0x00000023 efl: 0x00010282 eip: 0x93a5f3e3 cs: 0x0000001b
ds: 0x00000023 es: 0x00000023 fs: 0x00000000 gs: 0x0000000f
cr2: 0xa7f97ecc

Logical CPU: 0
Error Code: 0x00000000
Trap Number: 6

Binary Images:
0x1000 - 0x1ff7 +Python (???) /Applications/Python 3.6/IDLE.app/Contents/MacOS/Python
0x4000 - 0x1f1fff +org.python.python (3.6.4, [c] 2001-2017 Python Software Foundation. - 3.6.4) /Library/Frameworks/Python.framework/Versions/3.6/Python
0x3e6000 - 0x3e7ff7 +_heapq.cpython-36m-darwin.so (???) <5A29681A-FD13-A85B-42F3-0897C55A0F96> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_heapq.cpython-36m-darwin.so
0x3eb000 - 0x3f2ff7 +_tkinter.cpython-36m-darwin.so (???) /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_tkinter.cpython-36m-darwin.so
0x7f7000 - 0x7f8ff7 +_posixsubprocess.cpython-36m-darwin.so (???) /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_posixsubprocess.cpython-36m-darwin.so
0x7fb000 - 0x7fbff7 +_opcode.cpython-36m-darwin.so (???) <9B012FE1-6DE8-BAED-D91C-2979B28D8AA2> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_opcode.cpython-36m-darwin.so
0x2afb000 - 0x2afcff7 +_bz2.cpython-36m-darwin.so (???) <80FCCD7B-886A-9D06-5680-6E17B2AF9D16> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_bz2.cpython-36m-darwin.so
0x2d00000 - 0x2d04ff7 +_struct.cpython-36m-darwin.so (???) <3095297A-8F67-6764-A633-9CCF6097917C> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_struct.cpython-36m-darwin.so
0x2d0b000 - 0x2d0eff7 +select.cpython-36m-darwin.so (???) <069CC8D2-F791-F5CF-E895-87CABD8D52B1> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/select.cpython-36m-darwin.so
0x2d14000 - 0x2d19fe7 +math.cpython-36m-darwin.so (???) <6BEDA9EC-9730-7381-D95C-2619361ECF64> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/math.cpython-36m-darwin.so
0x2d20000 - 0x2d2aff7 +_socket.cpython-36m-darwin.so (???) /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_socket.cpython-36m-darwin.so
0x2d35000 - 0x2d38ff7 +zlib.cpython-36m-darwin.so (???) /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/zlib.cpython-36m-darwin.so
0x2d3d000 - 0x2d3dff7 +grp.cpython-36m-darwin.so (???) /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/grp.cpython-36m-darwin.so
0x47c7000 - 0x47ecff7 +_lzma.cpython-36m-darwin.so (???) <5C81CC46-1F73-F635-1584-A438E5DF5C92> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_lzma.cpython-36m-darwin.so
0x47f5000 - 0x47f7ff7 +_hashlib.cpython-36m-darwin.so (???) <1F407598-2886-0DF1-78E1-FF12A926664A> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_hashlib.cpython-36m-darwin.so
0x47fb000 - 0x47fbff7 +_bisect.cpython-36m-darwin.so (???) <200AEE40-86B4-F4C5-3903-968586AB7A49> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_bisect.cpython-36m-darwin.so
0x4ad1000 - 0x4b1ffff +libssl.1.0.0.dylib (1) <49DC030B-D0EF-37B6-F345-BC6FFBE25541> /Library/Frameworks/Python.framework/Versions/3.6/lib/libssl.1.0.0.dylib
0x4b39000 - 0x4c84fff +libcrypto.1.0.0.dylib (1) /Library/Frameworks/Python.framework/Versions/3.6/lib/libcrypto.1.0.0.dylib
0x4ce5000 - 0x4cf1ff7 +_blake2.cpython-36m-darwin.so (???) <7F9E2841-944F-20F0-E6F2-A7FF74C1A5EA> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_blake2.cpython-36m-darwin.so
0x4cf6000 - 0x4cfbff7 +_sha3.cpython-36m-darwin.so (???) /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_sha3.cpython-36m-darwin.so
0x4d00000 - 0x4d01ff7 +_random.cpython-36m-darwin.so (???) <86D566CD-DF59-C2D8-B5F0-6E08368673A0> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_random.cpython-36m-darwin.so
0x4d44000 - 0x4d54ff7 +_pickle.cpython-36m-darwin.so (???) <3455B4C8-D4B0-3F44-A0CB-5B0566769416> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_pickle.cpython-36m-darwin.so
0x7800000 - 0x7d3efff com.apple.driver.AppleIntelHD4000GraphicsGLDriver (10.30.12 - 10.3.0) <3A85569D-C753-365C-AEF0-67704DB7CB96> /System/Library/Extensions/AppleIntelHD4000GraphicsGLDriver.bundle/Contents/MacOS/AppleIntelHD4000GraphicsGLDriver
0x90298000 - 0x90298fff com.apple.Accelerate (1.11 - Accelerate 1.11) /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
0x90299000 - 0x902afffb libCGInterfaces.dylib (417) <92B03F58-1974-35E7-BC7F-28B6B285A860> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/Libraries/libCGInterfaces.dylib
0x902b0000 - 0x909f1fdf com.apple.vImage (8.1 - ???) <591C941E-6475-347E-89DA-F541E88F949A> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
0x909f2000 - 0x90b2dff7 libBLAS.dylib (1211.30.1) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
0x90b2e000 - 0x90b5bffb libBNNS.dylib (37) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBNNS.dylib
0x90b5c000 - 0x90ecffff libLAPACK.dylib (1211.30.1) <2DDDE838-0FF1-3679-8E62-9C09923ECB7E> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
0x90ed0000 - 0x90ee6ffb libLinearAlgebra.dylib (1211.30.1) <8A120E75-CAF4-3CAE-BBE6-E2F5FAE44DB8> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLinearAlgebra.dylib
0x90ee7000 - 0x90f00ff7 libSparseBLAS.dylib (1211.30.1) <0C5E0EF4-E9A5-3FC4-B7A3-1FE59DB4A2AA> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparseBLAS.dylib
0x90f01000 - 0x9105ffc7 libvDSP.dylib (622.20.8) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
0x91060000 - 0x9113effb libvMisc.dylib (622.20.8) <1C8D5D80-F32C-3853-8309-57C8A82B7DA5> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
0x9113f000 - 0x9113ffff com.apple.Accelerate.vecLib (3.11 - vecLib 3.11) <7A0D5DD6-C302-390D-9178-0B2EA94BB5ED> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
0x91333000 - 0x920f4ffb com.apple.AppKit (6.9 - 1561.20.106) <5EC573DC-BD5D-3901-AC06-65690425A1B1> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
0x92146000 - 0x92146fff com.apple.ApplicationServices (48 - 50) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
0x92147000 - 0x921adff3 com.apple.ApplicationServices.ATS (377 - 445) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
0x921b0000 - 0x922d4ff3 libFontParser.dylib (222.1.2) <8F7D388A-299C-3C6D-9864-40EC0914A96B> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
0x922d5000 - 0x92321ffb libFontRegistry.dylib (221) <8D81FDCF-F05D-3556-AB6D-090F9508C25E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib
0x92370000 - 0x923a3ff3 libTrueTypeScaler.dylib (222.1.2) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libTrueTypeScaler.dylib
0x9240f000 - 0x92414fff com.apple.ColorSyncLegacy (4.13.0 - 1) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSyncLegacy.framework/Versions/A/ColorSyncLegacy
0x924be000 - 0x92515ff7 com.apple.HIServices (1.22 - 622) <8544026A-17BE-301D-BA2A-782F3AD864DA> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
0x92516000 - 0x92525ff7 com.apple.LangAnalysis (1.7.0 - 1.7.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
0x92526000 - 0x9257effb com.apple.print.framework.PrintCore (13 - 503) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
0x9257f000 - 0x92615ffb com.apple.QD (3.12 - 403) <372AFF26-17D1-3C6F-9E47-17C955C2045B> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
0x92616000 - 0x92622ff3 com.apple.speech.synthesis.framework (7.2.1 - 7.2.1) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
0x92623000 - 0x9286fff3 com.apple.audio.toolbox.AudioToolbox (1.14 - 1.14) <489BC806-28CC-3340-BB52-D37A65CADEC9> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
0x92871000 - 0x92871fff com.apple.audio.units.AudioUnit (1.14 - 1.14) <3CF15BE4-B8D9-3D92-AB17-B613CD0BFBFE> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
0x92b8f000 - 0x92efcffb com.apple.CFNetwork (893.13.1 - 893.13.1) <960BA636-F94A-3DF7-B587-3165654BF020> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
0x92f11000 - 0x92f11fff com.apple.Carbon (158 - 158) <1545E2E8-F562-33D6-8DA7-5FD34045B314> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
0x92f12000 - 0x92f1bff3 com.apple.audio.SoundManager (4.2 - 4.2) <83AE7AA9-8661-3449-99F4-291A42640692> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/A/CarbonSound
0x92f1c000 - 0x92f20fff com.apple.CommonPanels (1.2.6 - 98) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
0x92f21000 - 0x932b7ffb com.apple.HIToolbox (2.1.1 - 910.4) <16D13C1E-B4A1-3AF0-A7A3-B3AC344D25F6> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
0x932b8000 - 0x9330cffb com.apple.htmlrendering (77 - 1.1.4) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering
0x9330d000 - 0x93310fff com.apple.help (1.3.8 - 64) <1E913488-5D7B-388E-904D-64EF8C99E704> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
0x93311000 - 0x93316ffb com.apple.ImageCapture (9.0 - 9.0) <1887749B-D641-3057-B91F-3C2D8E990115> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
0x93317000 - 0x933b1ffb com.apple.ink.framework (10.9 - 220) <5340E055-BD3D-35AD-9797-F22E1ECEDAC6> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
0x933b2000 - 0x933ecfff com.apple.NavigationServices (3.8 - 227) <6B1000C3-9C00-33F5-88D5-62F6BD5DD7F8> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/Versions/A/NavigationServices
0x933ed000 - 0x93408ffb com.apple.openscripting (1.7 - 174) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
0x93409000 - 0x9340efff com.apple.print.framework.Print (12 - 267) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
0x9340f000 - 0x93411fff com.apple.securityhi (9.0 - 55006) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
0x93412000 - 0x93418fff com.apple.speech.recognition.framework (6.0.3 - 6.0.3) <1C27FB7B-A467-3171-A73B-8C9B403028E1> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
0x93419000 - 0x93419fff com.apple.Cocoa (6.11 - 22) <299860CC-316E-3580-B0A3-3BF73B6E80E8> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
0x93426000 - 0x934e5ff7 com.apple.ColorSync (4.13.0 - 546) /System/Library/Frameworks/ColorSync.framework/Versions/A/ColorSync
0x934e6000 - 0x93581fff com.apple.audio.CoreAudio (4.3.0 - 4.3.0) /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
0x935df000 - 0x935e4fff com.apple.CoreBluetooth (1.0 - 1) /System/Library/Frameworks/CoreBluetooth.framework/Versions/A/CoreBluetooth
0x935e5000 - 0x938c5fff com.apple.CoreData (120 - 849.2) /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
0x938c6000 - 0x938ccff3 com.apple.CoreDisplay (1.0 - 81.7) /System/Library/Frameworks/CoreDisplay.framework/Versions/A/CoreDisplay
0x938cd000 - 0x93d57ff3 com.apple.CoreFoundation (6.9 - 1450.16) <5FAD88AF-D901-3D54-9480-BFD8BBB95A09> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x93d59000 - 0x94388ffb com.apple.CoreGraphics (2.0 - 1129.5) <20752785-E9DA-3CC6-ACDD-5A82AD344209> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
0x9438a000 - 0x94600ffb com.apple.CoreImage (13.0.0 - 579.2.9) /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage
0x947f1000 - 0x947f1fff com.apple.CoreServices (822.19 - 822.19) <5BEC50B1-0B38-3237-8D48-7858156721F5> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
0x947f2000 - 0x94864ff3 com.apple.AE (735.1 - 735.1) <3E1B0CED-0AC3-3252-AEDD-5D8F91E3AAA7> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
0x94865000 - 0x94b43ffb com.apple.CoreServices.CarbonCore (1178.2 - 1178.2) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
0x94b44000 - 0x94b78ff3 com.apple.DictionaryServices (1.2 - 284) <56BEF6B8-50D2-38A0-9EF2-D7093E9AAB56> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
0x94b79000 - 0x94b81fff com.apple.CoreServices.FSEvents (1239 - 1239) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/FSEvents.framework/Versions/A/FSEvents
0x94b82000 - 0x94ce0fff com.apple.LaunchServices (822.19 - 822.19) <44D623FB-2F50-3322-BEEC-A6A2DD3CD9E6> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
0x94ce1000 - 0x94d8dff7 com.apple.Metadata (10.7.0 - 1191.2.6) <6CE69880-6AF3-3A1A-A8E0-F89FC750EE4C> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
0x94d8e000 - 0x94decff7 com.apple.CoreServices.OSServices (822.19 - 822.19) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
0x94ded000 - 0x94e5eff3 com.apple.SearchKit (1.4.0 - 1.4.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
0x94e5f000 - 0x94e82fff com.apple.coreservices.SharedFileList (71.4 - 71.4) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SharedFileList.framework/Versions/A/SharedFileList
0x94e83000 - 0x94fceffb com.apple.CoreText (352.0 - 578.12) <6389222B-6B26-3F46-93C2-ABE07168227F> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText
0x94fcf000 - 0x95009ff3 com.apple.CoreVideo (1.8 - 279.2) <0D75C395-3C86-3539-9206-C7A330BE3551> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
0x9500a000 - 0x95090ff3 com.apple.framework.CoreWLAN (13.0 - 1339) /System/Library/Frameworks/CoreWLAN.framework/Versions/A/CoreWLAN
0x952e4000 - 0x952edff7 com.apple.DiskArbitration (2.7 - 2.7) /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
0x952fe000 - 0x9566dffb com.apple.Foundation (6.9 - 1450.16) <3838D116-6432-30EE-8C80-68FE79D28DE5> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x956ae000 - 0x956ddff3 com.apple.GSS (4.0 - 2.0) <78C94D11-21DF-34C6-B4E8-88564551D67E> /System/Library/Frameworks/GSS.framework/Versions/A/GSS
0x9570a000 - 0x95822ff3 com.apple.Bluetooth (6.0.2 - 6.0.2f2) <48DCB862-4D56-3D7A-83BF-F182D238090A> /System/Library/Frameworks/IOBluetooth.framework/Versions/A/IOBluetooth
0x95888000 - 0x95929ffb com.apple.framework.IOKit (2.0.2 - 1445.31.1) <22A82C10-B391-3359-B23A-053108AE9EB1> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x9592b000 - 0x95932fff com.apple.IOSurface (209.2.2 - 209.2.2) <0CCA9904-FCBB-3278-96A1-714BDB961D8A> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
0x95987000 - 0x95b0bff3 com.apple.ImageIO.framework (3.3.0 - 1713) <3A5C1E33-7CCC-3537-819B-53F39F70F034> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
0x95b0c000 - 0x95b10ffb libGIF.dylib (1713) <47A6BFCC-6651-3AAE-A70C-7BA3717B13BB> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
0x95b11000 - 0x95c02fff libJP2.dylib (1713) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib
0x95c03000 - 0x95c25ff7 libJPEG.dylib (1713) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
0x95f06000 - 0x95f2cff7 libPng.dylib (1713) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
0x95f2d000 - 0x95f2fffb libRadiance.dylib (1713) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
0x95f30000 - 0x95f7afff libTIFF.dylib (1713) <7A56E3C4-9965-3471-8E98-5F6B28D68FBF> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
0x9686f000 - 0x96887fff com.apple.Kerberos (3.0 - 1) <8A399DB7-5440-3EC0-A241-3DD10E82DDB2> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
0x96efd000 - 0x96f73fff com.apple.Metal (124.7 - 124.7) <30F249EE-27E6-3C0F-AD33-792A2E77D75B> /System/Library/Frameworks/Metal.framework/Versions/A/Metal
0x96f75000 - 0x96f81fff com.apple.NetFS (6.0 - 4.0) /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
0x99c45000 - 0x99c4dff7 libcldcpuengine.dylib (2.8.7) /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libcldcpuengine.dylib
0x99c4e000 - 0x99c99fff com.apple.opencl (2.8.12 - 2.8.12) /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
0x99c9a000 - 0x99cb6fff com.apple.CFOpenDirectory (10.13 - 207) /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
0x99cb7000 - 0x99cc2fff com.apple.OpenDirectory (10.13 - 207) <86931646-B3A1-3200-A3CB-35005468F987> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
0x9aecc000 - 0x9aecdfff libCVMSPluginSupport.dylib (16.4.2) <909D788E-692E-3FF1-AFF0-2AB4609C53D7> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib
0x9aece000 - 0x9aed2fff libCoreFSCache.dylib (162.4) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreFSCache.dylib
0x9aed3000 - 0x9aed7fff libCoreVMClient.dylib (162.4) <19767FEB-6A89-3892-8F18-1F9E73463050> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
0x9aed8000 - 0x9aee0ff7 libGFXShared.dylib (16.4.2) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
0x9aee1000 - 0x9aeedfff libGL.dylib (16.4.2) <028B909B-DD19-388B-8113-1850DFAD3DCA> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
0x9aeee000 - 0x9af29ffb libGLImage.dylib (16.4.2) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
0x9af2a000 - 0x9b0a2ffb libGLProgrammability.dylib (16.4.2) <141160DE-8DB1-3A9C-95CA-0167D90B0A5A> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib
0x9b0a3000 - 0x9b0e5ff7 libGLU.dylib (16.4.2) <9E1283AA-A7E0-37BA-BDEB-EE5256D677C7> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
0x9ba8c000 - 0x9ba9afff com.apple.opengl (16.4.2 - 16.4.2) <40645026-52DC-3CFC-8308-EFA2FA79D5A0> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
0x9ba9b000 - 0x9bc28ffb GLEngine (16.4.2) /System/Library/Frameworks/OpenGL.framework/Versions/A/Resources/GLEngine.bundle/GLEngine
0x9bc29000 - 0x9bc53fff GLRendererFloat (16.4.2) /System/Library/Frameworks/OpenGL.framework/Versions/A/Resources/GLRendererFloat.bundle/GLRendererFloat
0x9c7ff000 - 0x9ca35ff7 com.apple.QuartzCore (1.11 - 584.8.94) /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
0x9cece000 - 0x9d1faff3 com.apple.security (7.0 - 58286.31.2) /System/Library/Frameworks/Security.framework/Versions/A/Security
0x9d1fb000 - 0x9d282ff3 com.apple.securityfoundation (6.0 - 55185.30.4) <54362CD6-89D0-3328-9915-EC2F74748529> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
0x9d2ae000 - 0x9d2b2fff com.apple.xpc.ServiceManagement (1.0 - 1) /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
0x9d3dd000 - 0x9d44dff3 com.apple.SystemConfiguration (1.17 - 1.17) <318C287A-BB41-3F72-9095-9DFF0382CB77> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
0x9d454000 - 0x9d517fff Tcl (8.5.9 - 8.5.9) <52C2FC7F-5020-3E3F-BEB4-78B817A09234> /System/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl
0x9d518000 - 0x9d5f5ff3 Tk (8.5.9 - 8.5.9) <685D4DD3-670A-33EB-88F3-9657C167A3F1> /System/Library/Frameworks/Tk.framework/Versions/8.5/Tk
0x9f221000 - 0x9f2b8ff7 com.apple.APFS (1.0 - 1) /System/Library/PrivateFrameworks/APFS.framework/Versions/A/APFS
0x9f8cc000 - 0x9f8f7ff3 com.apple.framework.Apple80211 (13.0 - 1345) <6805C16F-21E5-3758-B77C-29870A7C6627> /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Apple80211
0x9f8f9000 - 0x9f903fff com.apple.AppleFSCompression (96.30.2 - 1.0) /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression
0x9f9fc000 - 0x9fa39ff3 com.apple.AppleJPEG (1.0 - 1) /System/Library/PrivateFrameworks/AppleJPEG.framework/Versions/A/AppleJPEG
0x9fb8c000 - 0x9fb93fff com.apple.coreservices.BackgroundTaskManagement (1.0 - 57.1) <71FD5EA2-8D0B-3E21-94E4-6D5BD45005E7> /System/Library/PrivateFrameworks/BackgroundTaskManagement.framework/Versions/A/BackgroundTaskManagement
0x9fb94000 - 0x9fc1fff7 com.apple.backup.framework (1.9.2 - 1.9.2) <19BE4138-61BB-33C8-80C5-0309B58CA16A> /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup
0x9fd63000 - 0x9fd6cffb com.apple.CommonAuth (4.0 - 2.0) <424B8D39-396A-3A78-84C1-5161B54A8F5B> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth
0xa01de000 - 0xa01eeff7 com.apple.CoreEmoji (1.0 - 69.3) <165A133F-DED4-3B24-A9BF-6EA6F3F7A152> /System/Library/PrivateFrameworks/CoreEmoji.framework/Versions/A/CoreEmoji
0xa0376000 - 0xa03a9ff7 com.apple.CoreServicesInternal (309.1 - 309.1) <1F73ECC7-F09F-3730-A290-472B89788807> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal
0xa03aa000 - 0xa0440ff3 com.apple.CoreSymbolication (63075) <6223068D-FCD8-39C1-841D-834EF0AC6445> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication
0xa0441000 - 0xa0567fe3 com.apple.coreui (2.1 - 492.2) <4B915963-6D32-3D89-B585-94094ACCF2E8> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
0xa0568000 - 0xa0603ff3 com.apple.CoreUtils (5.3 - 530.57) <21D34447-A1FC-31C4-BE73-F61577ABB2F5> /System/Library/PrivateFrameworks/CoreUtils.framework/Versions/A/CoreUtils
0xa0654000 - 0xa06b1ff3 com.apple.framework.CoreWiFi (13.0 - 1339) <5434C7AB-A80A-3DD3-B0F1-4EFEA912B16B> /System/Library/PrivateFrameworks/CoreWiFi.framework/Versions/A/CoreWiFi
0xa06b2000 - 0xa06c2fff com.apple.CrashReporterSupport (10.13 - 1) <86DA5C7B-BA5E-3182-A787-28B6F580FF38> /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport
0xa0730000 - 0xa073dfff com.apple.framework.DFRFoundation (1.0 - 191.1) <8EF25CE9-3ED3-3E20-A4A2-20743EA32265> /System/Library/PrivateFrameworks/DFRFoundation.framework/Versions/A/DFRFoundation
0xa0789000 - 0xa07fafff com.apple.datadetectorscore (7.0 - 590.3) <2210A987-9208-3E20-8425-90180C57DE8C> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore
0xa07fb000 - 0xa083bffb com.apple.DebugSymbols (141 - 141) <96BB879B-1A83-3622-BB02-1DDA5C4FD939> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols
0xa083c000 - 0xa097bff7 com.apple.desktopservices (1.12.2 - 1.12.2) /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
0xa0c47000 - 0xa1077ff7 com.apple.vision.FaceCore (3.3.2 - 3.3.2) /System/Library/PrivateFrameworks/FaceCore.framework/Versions/A/FaceCore
0xa2e23000 - 0xa2e2dfff libGPUSupportMercury.dylib (16.4.2) /System/Library/PrivateFrameworks/GPUSupport.framework/Versions/A/Libraries/libGPUSupportMercury.dylib
0xa3a1b000 - 0xa3a8eff3 com.apple.Heimdal (4.0 - 2.0) <560C8A98-E261-39C9-9862-3340EC6ABC9C> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal
0xa3a8f000 - 0xa3abefff com.apple.HelpData (2.3 - 158) <8FFBF281-4DDA-330B-898E-3E8C4D70E8F6> /System/Library/PrivateFrameworks/HelpData.framework/Versions/A/HelpData
0xa3d40000 - 0xa3d46fff com.apple.IOAccelerator (376.6 - 376.6) <4EFED596-8863-35F6-8EA3-CB11C5D9D157> /System/Library/PrivateFrameworks/IOAccelerator.framework/Versions/A/IOAccelerator
0xa3d47000 - 0xa3d5fffb com.apple.IOPresentment (1.0 - 32.1) /System/Library/PrivateFrameworks/IOPresentment.framework/Versions/A/IOPresentment
0xa3dbc000 - 0xa3ddbff3 com.apple.IconServices (97.4 - 97.4) <3F593C33-E45D-3D77-B82C-F811428C4901> /System/Library/PrivateFrameworks/IconServices.framework/Versions/A/IconServices
0xa3e13000 - 0xa3f07ff7 com.apple.LanguageModeling (1.0 - 159.3.1) /System/Library/PrivateFrameworks/LanguageModeling.framework/Versions/A/LanguageModeling
0xa3f08000 - 0xa3f49ff7 com.apple.Lexicon-framework (1.0 - 33.2) <13FAB8A2-507A-3AEA-A571-27BDDFD96B31> /System/Library/PrivateFrameworks/Lexicon.framework/Versions/A/Lexicon
0xa3f4d000 - 0xa3f53ff3 com.apple.LinguisticData (1.0 - 238.3) /System/Library/PrivateFrameworks/LinguisticData.framework/Versions/A/LinguisticData
0xa4301000 - 0xa432affb com.apple.MultitouchSupport.framework (1204.13 - 1204.13) <01BDF9A5-8C83-3611-A999-F43F9121A173> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
0xa4449000 - 0xa4453fff com.apple.NetAuth (6.2 - 6.2) <52F67DC1-8C96-3944-8E54-C02DD51FD9FC> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth
0xa44fb000 - 0xa4537fff com.apple.PerformanceAnalysis (1.183.1 - 183.1) /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis
0xa45d6000 - 0xa45f2ff7 com.apple.ProtocolBuffer (1 - 259) /System/Library/PrivateFrameworks/ProtocolBuffer.framework/Versions/A/ProtocolBuffer
0xa46de000 - 0xa4700fff com.apple.RemoteViewServices (2.0 - 125) <5720B413-E761-3368-964F-7FEAC5535669> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices
0xa47b6000 - 0xa47e3ffb com.apple.Sharing (972.6 - 972.6) <94426AD7-4302-3870-9D7B-F5ED6900BBCE> /System/Library/PrivateFrameworks/Sharing.framework/Versions/A/Sharing
0xa47e4000 - 0xa4801ff3 com.apple.shortcut (2.16 - 98) <5AC8A175-06FF-39B8-98A9-9AD32B1D4AC5> /System/Library/PrivateFrameworks/Shortcut.framework/Versions/A/Shortcut
0xa4802000 - 0xa4803fff com.apple.performance.SignpostNotification (1.0 - 1) <9AD547F6-ED5A-3AC8-BF4C-811C69801CDF> /System/Library/PrivateFrameworks/SignpostNotification.framework/Versions/A/SignpostNotification
0xa4804000 - 0xa4889ffb com.apple.SkyLight (1.600.0 - 312.23.4) /System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/SkyLight
0xa48b9000 - 0xa48c6ffb com.apple.SpeechRecognitionCore (4.0.13 - 4.0.13) /System/Library/PrivateFrameworks/SpeechRecognitionCore.framework/Versions/A/SpeechRecognitionCore
0xa4b93000 - 0xa4c14ff3 com.apple.Symbolication (9.0 - 63079.1) <97DA4973-352E-3CBA-9B4A-BC22C3AFD597> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication
0xa4c67000 - 0xa4c6efff com.apple.TCC (1.0 - 1) <4B76752A-36A0-3175-87C7-CB42E33CCB5A> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC
0xa4c6f000 - 0xa4c86ff3 com.apple.TextureIO (3.7 - 3.7) /System/Library/PrivateFrameworks/TextureIO.framework/Versions/A/TextureIO
0xa4cae000 - 0xa4caffff com.apple.TrustEvaluationAgent (2.0 - 31) <185BD5A9-5A2D-3317-B7FE-9B67F14C4D2C> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
0xa4cb0000 - 0xa4e3afff com.apple.UIFoundation (1.0 - 546.1.1) /System/Library/PrivateFrameworks/UIFoundation.framework/Versions/A/UIFoundation
0xa5408000 - 0xa540afff com.apple.loginsupport (1.0 - 1) <086FAE1B-87E2-324A-AE76-E6EC0B5F1517> /System/Library/PrivateFrameworks/login.framework/Versions/A/Frameworks/loginsupport.framework/Versions/A/loginsupport
0xa5495000 - 0xa54c8ff7 libclosured.dylib (519.2.2) /usr/lib/closure/libclosured.dylib
0xa5518000 - 0xa554fff3 libCRFSuite.dylib (41) <7F584902-74F1-3362-935D-95F5E735F5E7> /usr/lib/libCRFSuite.dylib
0xa5550000 - 0xa555affb libChineseTokenizer.dylib (28) <1FF5A32D-E012-3E76-B738-FAC26AD2A39B> /usr/lib/libChineseTokenizer.dylib
0xa55f6000 - 0xa55f7fff libDiagnosticMessagesClient.dylib (104) <6829B180-2556-3A7E-A2E6-BD4859DF30A7> /usr/lib/libDiagnosticMessagesClient.dylib
0xa5629000 - 0xa5813ff7 libFosl_dynamic.dylib (17.7) /usr/lib/libFosl_dynamic.dylib
0xa581b000 - 0xa581bfff libOpenScriptingUtil.dylib (174) /usr/lib/libOpenScriptingUtil.dylib
0xa5865000 - 0xa5869fff libScreenReader.dylib (562.13) /usr/lib/libScreenReader.dylib
0xa586a000 - 0xa586bfff libSystem.B.dylib (1252) <334D9E12-F209-3C28-875B-77E0FD623AD7> /usr/lib/libSystem.B.dylib
0xa587a000 - 0xa588fff7 libapple_nghttp2.dylib (1.24) <480C0C04-2533-3D44-8232-006B6CBA7758> /usr/lib/libapple_nghttp2.dylib
0xa5890000 - 0xa58bbfff libarchive.2.dylib (54) /usr/lib/libarchive.2.dylib
0xa58bc000 - 0xa5a0bffb libate.dylib (1.13.1) /usr/lib/libate.dylib
0xa5a0f000 - 0xa5a0fff3 libauto.dylib (187) /usr/lib/libauto.dylib
0xa5a10000 - 0xa5a20fff libbsm.0.dylib (39) <067E9003-0673-32A3-9B40-492323182C5C> /usr/lib/libbsm.0.dylib
0xa5a21000 - 0xa5a2dff7 libbz2.1.0.dylib (38) <77C24A36-BE84-3702-A786-935C597A0A86> /usr/lib/libbz2.1.0.dylib
0xa5a2e000 - 0xa5a87ffb libc++.1.dylib (400.9) /usr/lib/libc++.1.dylib
0xa5a88000 - 0xa5aa9fff libc++abi.dylib (400.7) <41323E53-C7EA-3E9A-BD30-38E82399F843> /usr/lib/libc++abi.dylib
0xa5aab000 - 0xa5abcff7 libcmph.dylib (6) /usr/lib/libcmph.dylib
0xa5abd000 - 0xa5ad0ff7 libcompression.dylib (47) /usr/lib/libcompression.dylib
0xa5ad1000 - 0xa5ae8ffb libcoretls.dylib (155) /usr/lib/libcoretls.dylib
0xa5ae9000 - 0xa5aeafff libcoretls_cfhelpers.dylib (155) <8B8ABC2C-F251-3C80-9747-88C05A2CBE64> /usr/lib/libcoretls_cfhelpers.dylib
0xa5c6b000 - 0xa5e12fff libcrypto.35.dylib (22) /usr/lib/libcrypto.35.dylib
0xa5fd2000 - 0xa6029fff libcups.2.dylib (462.1) <0180AE97-A19F-3D49-9838-06995E73F572> /usr/lib/libcups.2.dylib
0xa613f000 - 0xa613ffff libenergytrace.dylib (16) <34FC43C7-D9B6-3C01-8B65-E49059D31279> /usr/lib/libenergytrace.dylib
0xa6173000 - 0xa6177fff libheimdal-asn1.dylib (520.30.1) /usr/lib/libheimdal-asn1.dylib
0xa61a3000 - 0xa6293ff3 libiconv.2.dylib (51) /usr/lib/libiconv.2.dylib
0xa6294000 - 0xa64b6ff7 libicucore.A.dylib (59152.0.1) <1048B064-30DD-30CA-BB7D-41F0F3159DA9> /usr/lib/libicucore.A.dylib
0xa64fe000 - 0xa64fffff liblangid.dylib (128) <120FE992-47E4-3A73-A039-1B401F5696DC> /usr/lib/liblangid.dylib
0xa6500000 - 0xa6518ff7 liblzma.5.dylib (10) <8A5C9679-430A-3A19-AF68-9D21BAC442C7> /usr/lib/liblzma.5.dylib
0xa6519000 - 0xa652efff libmarisa.dylib (9) <805453EE-B829-3DA5-8DF3-5132D03D5B74> /usr/lib/libmarisa.dylib
0xa65e3000 - 0xa6800fff libmecabra.dylib (779.7.6) <08A39874-BF80-3A92-A088-C494C518218A> /usr/lib/libmecabra.dylib
0xa69c7000 - 0xa6a9bfff libnetwork.dylib (1229.30.11) <86111B18-D03B-3F4F-ACD8-9D9C510058F3> /usr/lib/libnetwork.dylib
0xa6a9c000 - 0xa6e7c0fb libobjc.A.dylib (723) <4AF346B8-C1A8-3199-B1BB-ADEDD64D5C1A> /usr/lib/libobjc.A.dylib
0xa6e80000 - 0xa6e83fff libpam.2.dylib (22) <7106F43C-84DD-3F26-905A-B52780AFEB3E> /usr/lib/libpam.2.dylib
0xa6e86000 - 0xa6eb7fff libpcap.A.dylib (79.20.1) <154889CF-5F83-3012-953E-0FC8FEE50FF8> /usr/lib/libpcap.A.dylib
0xa6ef5000 - 0xa6f10ffb libresolv.9.dylib (65) <65A43F5B-CF88-3948-AE5C-D7CA02D814A1> /usr/lib/libresolv.9.dylib
0xa6f5b000 - 0xa70e5ff7 libsqlite3.dylib (274.5) /usr/lib/libsqlite3.dylib
0xa7289000 - 0xa72c3ffb libusrtcp.dylib (1229.30.11) <39D76669-A48B-3BAC-8F45-1D6CA87E9B4B> /usr/lib/libusrtcp.dylib
0xa72c4000 - 0xa72c7ff7 libutil.dylib (51.20.1) <86BD9675-16A2-345D-9B8D-E8A3397F2365> /usr/lib/libutil.dylib
0xa72c8000 - 0xa72d6ff7 libxar.1.dylib (400) <4B664A7E-EC05-34AD-ACC6-C879B69DBA7C> /usr/lib/libxar.1.dylib
0xa72d7000 - 0xa73b5ff7 libxml2.2.dylib (31.7) <3E1F9E3D-6C44-3437-AB2B-E5ACE1927F81> /usr/lib/libxml2.2.dylib
0xa73b6000 - 0xa73deff3 libxslt.1.dylib (15.10) <1A3DC7B8-7C92-3D73-BF82-D60E64BC3DF0> /usr/lib/libxslt.1.dylib
0xa73df000 - 0xa73eeff7 libz.1.dylib (70) <588F445F-0065-3D77-8002-BA9411DA1D70> /usr/lib/libz.1.dylib
0xa7428000 - 0xa742cfff libcache.dylib (80) <5D011637-CADA-38A1-A695-CE049657FD9D> /usr/lib/system/libcache.dylib
0xa742d000 - 0xa7437fff libcommonCrypto.dylib (60118.30.2) <38B2C15B-D27F-3106-A337-F72F29844825> /usr/lib/system/libcommonCrypto.dylib
0xa7438000 - 0xa743dfff libcompiler_rt.dylib (62) /usr/lib/system/libcompiler_rt.dylib
0xa743e000 - 0xa7447ff3 libcopyfile.dylib (146.30.2) /usr/lib/system/libcopyfile.dylib
0xa7448000 - 0xa74b0ff7 libcorecrypto.dylib (562.30.10) <0D8A61F8-2D7D-31F1-93AB-0597D80CCA85> /usr/lib/system/libcorecrypto.dylib
0xa751b000 - 0xa7550fff libdispatch.dylib (913.30.4) /usr/lib/system/libdispatch.dylib
0xa7551000 - 0xa756efff libdyld.dylib (519.2.2) /usr/lib/system/libdyld.dylib
0xa756f000 - 0xa756ffff libkeymgr.dylib (28) /usr/lib/system/libkeymgr.dylib
0xa7570000 - 0xa757cff7 libkxld.dylib (4570.31.3) <17609EC4-47F0-39C9-8F90-5F07FF52F217> /usr/lib/system/libkxld.dylib
0xa757d000 - 0xa757dfff liblaunch.dylib (1205.30.29) <0F3BF17D-FCFA-3692-8A6E-FDE5C58DB3B7> /usr/lib/system/liblaunch.dylib
0xa757e000 - 0xa7583fff libmacho.dylib (900.0.1) /usr/lib/system/libmacho.dylib
0xa7584000 - 0xa7586fff libquarantine.dylib (86) <68DE2EB2-7911-304D-89D6-1517CA689001> /usr/lib/system/libquarantine.dylib
0xa7587000 - 0xa7588fff libremovefile.dylib (45) /usr/lib/system/libremovefile.dylib
0xa7589000 - 0xa75a0ff7 libsystem_asl.dylib (356.1.1) /usr/lib/system/libsystem_asl.dylib
0xa75a1000 - 0xa75a1fff libsystem_blocks.dylib (67) <32CE9BB7-E047-3568-981E-4EA94D3DCBB5> /usr/lib/system/libsystem_blocks.dylib
0xa75a2000 - 0xa762efff libsystem_c.dylib (1244.30.3) <8BCBF89D-5CE7-3950-884A-86E37DBF2660> /usr/lib/system/libsystem_c.dylib
0xa762f000 - 0xa7632fff libsystem_configuration.dylib (963.30.1) <0F30DC5A-F39F-32C9-BA01-05AAC699713A> /usr/lib/system/libsystem_configuration.dylib
0xa7633000 - 0xa7636fff libsystem_coreservices.dylib (51) /usr/lib/system/libsystem_coreservices.dylib
0xa7637000 - 0xa7638fff libsystem_darwin.dylib (1244.30.3) <83B1D06A-9FA5-3F0B-A223-0659F4248E51> /usr/lib/system/libsystem_darwin.dylib
0xa7639000 - 0xa763fff3 libsystem_dnssd.dylib (878.30.4) <3C4400C4-C531-3653-872B-E22892D7B29A> /usr/lib/system/libsystem_dnssd.dylib
0xa7640000 - 0xa768fffb libsystem_info.dylib (517.30.1) /usr/lib/system/libsystem_info.dylib
0xa7690000 - 0xa76b3ff7 libsystem_kernel.dylib (4570.31.3) /usr/lib/system/libsystem_kernel.dylib
0xa76b4000 - 0xa7703fdb libsystem_m.dylib (3146) /usr/lib/system/libsystem_m.dylib
0xa7704000 - 0xa771efff libsystem_malloc.dylib (140.1.1) /usr/lib/system/libsystem_malloc.dylib
0xa771f000 - 0xa77bcffb libsystem_network.dylib (1229.30.11) <84B584A7-7583-31E7-8A39-64B4A5AD643B> /usr/lib/system/libsystem_network.dylib
0xa77bd000 - 0xa77c7fff libsystem_networkextension.dylib (767.30.7) /usr/lib/system/libsystem_networkextension.dylib
0xa77c8000 - 0xa77d0ff3 libsystem_notify.dylib (172) <63E3CF8C-4F15-3D45-84A6-1218352031E9> /usr/lib/system/libsystem_notify.dylib
0xa77d1000 - 0xa77d7ffb libsystem_platform.dylib (161.20.1) <82782E0E-7264-3CB4-AE69-571EDB5E7A24> /usr/lib/system/libsystem_platform.dylib
0xa77d8000 - 0xa77e2ff3 libsystem_pthread.dylib (301.30.1) <7409C1E5-F3BA-3AB3-ADC1-9DCD356C6C13> /usr/lib/system/libsystem_pthread.dylib
0xa77e3000 - 0xa77e6ff3 libsystem_sandbox.dylib (765.30.4) <8226258C-47FE-30A9-AE91-C13DE173E368> /usr/lib/system/libsystem_sandbox.dylib
0xa77e7000 - 0xa77e9fff libsystem_secinit.dylib (30) /usr/lib/system/libsystem_secinit.dylib
0xa77ea000 - 0xa77f2ff7 libsystem_symptoms.dylib (820.30.7) <0283BDB3-16A2-371E-A25C-A26F076C24A5> /usr/lib/system/libsystem_symptoms.dylib
0xa77f3000 - 0xa7805fff libsystem_trace.dylib (829.30.14) <79446DE0-89F6-3979-B14C-7B463AD70351> /usr/lib/system/libsystem_trace.dylib
0xa7807000 - 0xa780dfff libunwind.dylib (35.3) <642BBA03-0411-3FAA-A421-D79A9156AB1C> /usr/lib/system/libunwind.dylib
0xa780e000 - 0xa7836ff7 libxpc.dylib (1205.30.29) /usr/lib/system/libxpc.dylib
0xc0036000 - 0xc007bfdf dyld (519.2.2) <7B7B05B7-204A-38FF-BD32-4CBB51752DD4> /usr/lib/dyld

External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 2328
thread_create: 0
thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=216.9M resident=0K(0%) swapped_out_or_unallocated=216.9M(100%)
Writable regions: Total=96.3M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=96.3M(100%)

                            VIRTUAL   REGION 
REGION TYPE SIZE COUNT (non-coalesced)
=========== ======= =======
Accelerate framework 256K 3
Activity Tracing 256K 2
CG backing stores 3384K 6
CG image 184K 2
CoreAnimation 20K 4
CoreImage 12K 4
CoreUI image data 636K 5
CoreUI image file 180K 3
Kernel Alloc Once 8K 2
MALLOC 72.0M 48
MALLOC guard page 48K 13
MALLOC_LARGE (reserved) 512K 3 reserved VM address space (unallocated)
Memory Tag 242 12K 2
OpenGL GLSL 128K 3
Stack 2644K 7
Stack Guard 24K 7
VM_ALLOCATE 204K 29
__DATA 10.1M 241
__FONT_DATA 4K 2
__GLSLBUILTINS 2588K 2
__LINKEDIT 76.3M 26
__OBJC 3176K 80
__TEXT 140.6M 245
__UNICODE 560K 2
__UNIXSTACK 16.0M 2
mapped file 323.6M 193
shared memory 2728K 12
=========== ======= =======
TOTAL 655.7M 921
TOTAL, minus reserved VM space 655.2M 921

Model: MacBookPro9,2, BootROM MBP91.00D7.B00, 2 processors, Intel Core i7, 2,9 GHz, 8 GB, SMC 2.2f44
Graphics: Intel HD Graphics 4000, Intel HD Graphics 4000, Built-In
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x484D54333531533643465238432D50422020
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x484D54333531533643465238432D50422020
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xF5), Broadcom BCM43xx 1.0 (7.21.190.16.1a2)
Bluetooth: Version 6.0.2f2, 3 services, 27 devices, 1 incoming serial ports
Network Service: iPhone, Ethernet, en4
Network Service: Wi-Fi, AirPort, en1
Serial ATA Device: KINGSTON SHSS37A120G, 120,03 GB
Serial ATA Device: MATSHITADVD-R UJ-8A8
USB Device: USB 2.0 Bus
USB Device: Hub
USB Device: FaceTime HD Camera (Built-in)
USB Device: USB 2.0 Bus
USB Device: Hub
USB Device: Hub
USB Device: Apple Internal Keyboard / Trackpad
USB Device: IR Receiver
USB Device: BRCM20702 Hub
USB Device: Bluetooth USB Host Controller
USB Device: USB 3.0 Bus
USB Device: iPhone
Thunderbolt Bus: MacBook Pro, Apple Inc., 25.1

----------
messages: 309092
nosy: Felipe Filgueira Barral
priority: normal
severity: normal
status: open
title: [BUG] Python vs Macbook High Sierra 10.13.2
type: crash
versions: Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32432>
_______________________________________

From report at bugs.python.org  Wed Dec 27 14:00:28 2017
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 27 Dec 2017 19:00:28 +0000
Subject: [New-bugs-announce] [issue32433] Provide optimized HMAC digest
Message-ID: <1514401228.33.0.213398074469.issue32433@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

hmac.HMAC's flexibility comes with a cost. To create the MAC of a message, it has to create between three and four hash instances (inner, outer, key for long keys, result), multiple bound method objects and other temporary objects. For short messages, memory allocation, object handling and GIL release/acquire operations dominate the performance.

I propose to provide a fast one-shot HMAC function: hmac.digest(key, msg, digstmod) -> bytes function. A PoC implementation based on OpenSSL's HMAC() function and a pure Python implementation as inlined HMAC showed promising performance improvements. The C implementation is 3 times faster.

Standard HMAC:
$ ./python -m timeit -n200000 -s "import hmac" -- "hmac.HMAC(b'key', b'message', 'sha256').digest()"
200000 loops, best of 5: 5.38 usec per loop

Optimized Python code:
$ ./python -m timeit -n 200000 -s "import hmac; hmac._hashopenssl = None" -- "hmac.digest(b'key', b'message', 'sha256')"
200000 loops, best of 5: 3.87 usec per loop

OpenSSL HMAC()
$ ./python -m timeit -n 200000 -s "import hmac" -- "hmac.digest(b'key', b'message', 'sha256')"
200000 loops, best of 5: 1.82 usec per loop

----------
components: Extension Modules
messages: 309097
nosy: christian.heimes, gregory.p.smith
priority: normal
severity: normal
stage: patch review
status: open
title: Provide optimized HMAC digest
type: performance
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32433>
_______________________________________

From report at bugs.python.org  Wed Dec 27 15:13:36 2017
From: report at bugs.python.org (Martin Liska)
Date: Wed, 27 Dec 2017 20:13:36 +0000
Subject: [New-bugs-announce] [issue32434]
 pathlib.WindowsPath.reslove(strict=False) returns absoulte path only if at
 least one component exists
Message-ID: <1514405616.88.0.213398074469.issue32434@psf.upfronthosting.co.za>


New submission from Martin Liska <juggzor at gmail.com>:

The documentation for pathlib.Path.resolve says: "Make the path absolute, resolving any symlinks."

On Windows, the behavior doesn't always match the first part of the statement.

Example:
On a system with an existing, but empty directory C:\Test.
Running the interpreter at C:\ resolve behaves like so:

>>> os.path.realpath(r'Test\file')
'C:\\Test\\file'
>>> WindowsPath(r'Test\file').resolve(strict=False)
WindowsPath('C:/Test/file')

When running the interpreter inside C:\Test it instead behaves in the following manner:

>>> os.path.realpath('file')
'C:\\Test\\file'
>>> WindowsPath('file').resolve(strict=False)
WindowsPath('file')

Resolving a path object specifying a non-existent relative path results in an identical (relative) path object.
This is also inconsistent with the behavior of os.path.realpath as demonstrated.

The root of the issue is in the pathlib._WindowsFlavour.resolve method at lines 193, 199 and 201.
If at least one component of the path gets resolved at line 193 by the expression self._ext_to_normal(_getfinalpathname(s)), the path returned at line 201 will be joined from the absolute, resolved part and the unresolved remained.
If none of the components get resolved then the path will be returned at line 199 as passed into the function.

----------
components: Library (Lib)
messages: 309102
nosy: mliska
priority: normal
severity: normal
status: open
title: pathlib.WindowsPath.reslove(strict=False) returns absoulte path only if at least one component exists
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32434>
_______________________________________

From report at bugs.python.org  Wed Dec 27 16:56:20 2017
From: report at bugs.python.org (Sergey Petrunin)
Date: Wed, 27 Dec 2017 21:56:20 +0000
Subject: [New-bugs-announce] [issue32435] tarfile recognizes .gz file as tar
Message-ID: <1514411780.55.0.213398074469.issue32435@psf.upfronthosting.co.za>


New submission from Sergey Petrunin <sergey.petrunin at nih.gov>:

Library's function 'tarfile.is_tarfile' returns 'True' on GZip file (9.7 megabytes see attachment), that is a file with 10 gigabytes of '0' character compressed with 'gzip' utility (no 'tar' whatsoever).

Desired result: this function should return False in this case, b.c. this file is not a tar file.

----------
components: Library (Lib)
files: big_0_file_1.gz
messages: 309106
nosy: spetrunin
priority: normal
severity: normal
status: open
title: tarfile recognizes .gz file as tar
versions: Python 2.7, Python 3.6
Added file: https://bugs.python.org/file47353/big_0_file_1.gz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32435>
_______________________________________

From report at bugs.python.org  Thu Dec 28 00:20:05 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 28 Dec 2017 05:20:05 +0000
Subject: [New-bugs-announce] [issue32436] Implement PEP 567
Message-ID: <1514438405.44.0.213398074469.issue32436@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
assignee: yselivanov
components: Interpreter Core, Library (Lib)
nosy: gvanrossum, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Implement PEP 567
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32436>
_______________________________________

From report at bugs.python.org  Thu Dec 28 03:48:55 2017
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Thu, 28 Dec 2017 08:48:55 +0000
Subject: [New-bugs-announce] [issue32437] UnicodeError: 'IDNA does not
 round-trip'
Message-ID: <1514450935.58.0.213398074469.issue32437@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

First: This is the bug:

In [1]: 'gro?handel-shop'.encode('idna')
Out[1]: b'grosshandel-shop'

This lead to this:

'xn--einla-pqa'.decode('idna')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.6/encodings/idna.py", line 214, in decode
    result.append(ToUnicode(label))
  File "/usr/lib/python3.6/encodings/idna.py", line 139, in ToUnicode
    raise UnicodeError("IDNA does not round-trip", label, label2)
UnicodeError: ('IDNA does not round-trip', b'xn--einla-pqa', b'einlass')


https://stackoverflow.com/questions/9806036/idna-does-not-round-trip


xn--grohandel-shop-2fb has been correctly encoded by IDNA 2008 (which is correct in Germany/DENIC since a while). Your Python very likely tries to decode it using the old IDNA 2003, which doesn't know '?'. see denic.de/en/know-how/idn-domains

----------
components: Unicode
messages: 309117
nosy: ezio.melotti, socketpair, vstinner
priority: normal
severity: normal
status: open
title: UnicodeError: 'IDNA does not round-trip'
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32437>
_______________________________________

From report at bugs.python.org  Thu Dec 28 05:19:25 2017
From: report at bugs.python.org (Erik Bray)
Date: Thu, 28 Dec 2017 10:19:25 +0000
Subject: [New-bugs-announce] [issue32438] PyLong_ API cleanup
Message-ID: <1514456365.15.0.213398074469.issue32438@psf.upfronthosting.co.za>


New submission from Erik Bray <erik.m.bray at gmail.com>:

Per Serhiy's comment in this thread https://mail.python.org/pipermail/python-ideas/2017-December/048413.html (which I agree with), several of the PyLong_ functions have behavior carried over from Python 2 of calling __int__ on their arguments if the input is not a PyLongObject:

PyLong_AsLong
PyLong_AsLongAndOverflow
PyLong_AsLongLong
PyLong_AsLongLongAndOverflow
PyLong_AsUnsignedLongMask
PyLong_AsUnsignedLongLongMask

This behavior should probably be deprecated, and eventually removed.  Interfaces that should accept generic number-like objects should use the PyNumber API instead.

----------
components: Interpreter Core
messages: 309119
nosy: erik.bray
priority: normal
severity: normal
status: open
title: PyLong_ API cleanup
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32438>
_______________________________________

From report at bugs.python.org  Thu Dec 28 06:23:41 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Dec 2017 11:23:41 +0000
Subject: [New-bugs-announce] [issue32439] Clean up the code for compiling
 comparison expressions
Message-ID: <1514460221.23.0.213398074469.issue32439@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The proposed PR cleans up the code for compiling comparison expressions. It makes it similar to specialized copy added in bpo-30501.

----------
assignee: serhiy.storchaka
components: Interpreter Core
messages: 309123
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Clean up the code for compiling comparison expressions
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32439>
_______________________________________

From report at bugs.python.org  Thu Dec 28 07:08:12 2017
From: report at bugs.python.org (Old K)
Date: Thu, 28 Dec 2017 12:08:12 +0000
Subject: [New-bugs-announce] [issue32440] Use HTTPS in help()
Message-ID: <1514462892.59.0.213398074469.issue32440@psf.upfronthosting.co.za>


New submission from Old K <oldk1331 at gmail.com>:

In python3, in the output of help(), there is link
http://docs.python.org/3.6/tutorial/.
It should be made into https.

There are already some issues about changing http links to https:
https://bugs.python.org/issue25910
https://bugs.python.org/issue26736

But this link is still unchanged.

----------
assignee: docs at python
components: Documentation
messages: 309127
nosy: Old K, docs at python
priority: normal
severity: normal
status: open
title: Use HTTPS in help()
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32440>
_______________________________________

From report at bugs.python.org  Thu Dec 28 12:44:43 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 28 Dec 2017 17:44:43 +0000
Subject: [New-bugs-announce] [issue32441] os.dup2 should return the new fd
Message-ID: <1514483083.55.0.213398074469.issue32441@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

os.dup2 currently always None. However, the underlying standard Unix function returns the new file descriptor (i.e., the second argument) on success. We should follow that convention, too.

----------
components: Extension Modules
keywords: easy
messages: 309135
nosy: benjamin.peterson
priority: low
severity: normal
stage: needs patch
status: open
title: os.dup2 should return the new fd
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32441>
_______________________________________

From report at bugs.python.org  Thu Dec 28 14:09:57 2017
From: report at bugs.python.org (Tzu-ping Chung)
Date: Thu, 28 Dec 2017 19:09:57 +0000
Subject: [New-bugs-announce] [issue32442] Result of pathlib.Path.resolve()
 with UNC path is not very useful
Message-ID: <1514488197.55.0.213398074469.issue32442@psf.upfronthosting.co.za>


New submission from Tzu-ping Chung <uranusjr at gmail.com>:

The behaviour of os.path.abspath() and pathlib.Path.resolve() is a different when dealing with a path on a UNC share (on Windows):

    >>> import os, pathlib
    >>> path = pathlib.Path('Z:\foo')
    >>> path.resolve()
    WindowsPath('//host/share/foo')
    >>> os.path.abspath(path)
    'Z:\\foo'

This is not necessarily a problem by itself, just a consequence of calling different APIs underneath (although it probably worths a mention in documentation). The real problem is that the UNC path is not really useful anywhere in the Python standard library (AFAIK), and there?s no way to turn the it (back) into network drive once you call resolve(). The only way to get a network drive path is to

    >>> pathlib.Path(os.path.abspath(path))

Some possibile solutions:

1. Change the behaviour of resolve() to return the network drive path instead. This would be the most straightforward, API-wise, but is backward-incompatible, and maybe the original implementation did this on purpose?
2. Add a as_absolute() to pathlib.Path. On Windows this would mirror the result of os.path.abspath(); on POSIX this would probably be identical to resolve().
3. Add an argument to resolve()? This is essentially the same as 2., just interfaced differently.

----------
components: Library (Lib), Windows
messages: 309137
nosy: paul.moore, steve.dower, tim.golden, uranusjr, zach.ware
priority: normal
severity: normal
status: open
title: Result of pathlib.Path.resolve() with UNC path is not very useful
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32442>
_______________________________________

From report at bugs.python.org  Thu Dec 28 20:27:20 2017
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 29 Dec 2017 01:27:20 +0000
Subject: [New-bugs-announce] [issue32443] Add Linux's signalfd() to the
 signal module
Message-ID: <1514510840.93.0.213398074469.issue32443@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

We should add a wrapper for both signalfd() and a function to read and decode the structure from the fd into a dataclass.

The code we need to build such a thing from appears to exist in BSD & MIT licensed form in:

PyPI contains two extension module wrappers of just the system call:
 https://pypi.python.org/pypi/signalfd/
 https://pypi.python.org/pypi/python-signalfd

Why add this Linux specific API to the standard library?  I believe I could use signalfd() within the subprocess module to get rid of the need to busy-loop-poll to see when children have exited on subprocess.Popen.wait() calls with a timeout.  [a proof of concept using the above modules would be a good idea first]

----------
components: Library (Lib)
messages: 309151
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: Add Linux's signalfd() to the signal module
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32443>
_______________________________________

From report at bugs.python.org  Thu Dec 28 21:48:17 2017
From: report at bugs.python.org (Corey Seliger)
Date: Fri, 29 Dec 2017 02:48:17 +0000
Subject: [New-bugs-announce] [issue32444] python -m venv has incongruous
 behavor creating binaries
Message-ID: <1514515697.43.0.213398074469.issue32444@psf.upfronthosting.co.za>


New submission from Corey Seliger <corey at seligerfamily.org>:

The venv module does not evenly create the necessary binaries/symlinks when building virtualenvs. If you call venv like this:

seliger at core:~/venvs$ python3 -m venv venvA

seliger at core:~/venvs$ ls -l venvA/bin/
total 32
-rw-r--r-- 1 seliger seliger 2143 Dec 28 21:29 activate
-rw-r--r-- 1 seliger seliger 1259 Dec 28 21:29 activate.csh
-rw-r--r-- 1 seliger seliger 2397 Dec 28 21:29 activate.fish
-rwxrwxr-x 1 seliger seliger  254 Dec 28 21:29 easy_install
-rwxrwxr-x 1 seliger seliger  254 Dec 28 21:29 easy_install-3.5
-rwxrwxr-x 1 seliger seliger  226 Dec 28 21:29 pip
-rwxrwxr-x 1 seliger seliger  226 Dec 28 21:29 pip3
-rwxrwxr-x 1 seliger seliger  226 Dec 28 21:29 pip3.5
lrwxrwxrwx 1 seliger seliger    7 Dec 28 21:29 python -> python3
lrwxrwxrwx 1 seliger seliger   16 Dec 28 21:29 python3 -> /usr/bin/python3

...you do not end up with a "python3.5" binary. 

However, if you call venv like this:

seliger at core:~/venvs$ python3.5 -m venv venvB

seliger at core:~/venvs$ ls -l venvB/bin
total 32
-rw-r--r-- 1 seliger seliger 2143 Dec 28 21:29 activate
-rw-r--r-- 1 seliger seliger 1259 Dec 28 21:29 activate.csh
-rw-r--r-- 1 seliger seliger 2397 Dec 28 21:29 activate.fish
-rwxrwxr-x 1 seliger seliger  256 Dec 28 21:29 easy_install
-rwxrwxr-x 1 seliger seliger  256 Dec 28 21:29 easy_install-3.5
-rwxrwxr-x 1 seliger seliger  228 Dec 28 21:29 pip
-rwxrwxr-x 1 seliger seliger  228 Dec 28 21:29 pip3
-rwxrwxr-x 1 seliger seliger  228 Dec 28 21:29 pip3.5
lrwxrwxrwx 1 seliger seliger    9 Dec 28 21:29 python -> python3.5
lrwxrwxrwx 1 seliger seliger    9 Dec 28 21:29 python3 -> python3.5
lrwxrwxrwx 1 seliger seliger   18 Dec 28 21:29 python3.5 -> /usr/bin/python3.5

...you DO get the necessary python3.5 binary. Some vendors are making it a requirement to call a specific pythonX.Y binary to ensure compatibility. One such example is the serverless framework when deploying to Amazon Web Services. Another example is the useful pyenv utility that manages full Python builds and virtualenvs. When it depends upon venv, it exhibits the same behavior. I submitted a patch workaround to force calling venv using pythonX.Y, but this really seems like an issue with the venv module itself.

The expected behavior should be that venv generates all three binaries (python, python3, and python3.5) regardless of how the python command was invoked.

I am able to reproduce this on Python 3.5 and 3.6. I could not find any other similar references in searching the bug system.

----------
components: Library (Lib)
messages: 309157
nosy: seliger
priority: normal
severity: normal
status: open
title: python -m venv has incongruous behavor creating binaries
type: behavior
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32444>
_______________________________________

From report at bugs.python.org  Fri Dec 29 08:37:44 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 29 Dec 2017 13:37:44 +0000
Subject: [New-bugs-announce] [issue32445] Skip creating redundant wrapper
 functions in ExitStack.callback
Message-ID: <1514554664.91.0.213398074469.issue32445@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

While discussing https://bugs.python.org/issue32145, I noticed that ExitStack.callback *always* adds a wrapper function, even when the `args` and `kwds` parameters are both empty.

For plain callbacks that aren't receiving any extra arguments, it would be better to skip adding the redundant wrapper function.

----------
messages: 309171
nosy: barry, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Skip creating redundant wrapper functions in ExitStack.callback
type: performance
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32445>
_______________________________________

From report at bugs.python.org  Fri Dec 29 10:33:19 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 29 Dec 2017 15:33:19 +0000
Subject: [New-bugs-announce] [issue32446] ResourceLoader.get_data() should
 accept a PathLike
Message-ID: <1514561599.46.0.213398074469.issue32446@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

Currently get_data() only accepts a string.  It should also accept a os.PathLike

----------
messages: 309178
nosy: barry, brett.cannon
priority: normal
severity: normal
status: open
title: ResourceLoader.get_data() should accept a PathLike
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32446>
_______________________________________

From report at bugs.python.org  Fri Dec 29 11:43:59 2017
From: report at bugs.python.org (Steve Margetts)
Date: Fri, 29 Dec 2017 16:43:59 +0000
Subject: [New-bugs-announce] [issue32447] IDLE shell won't open on Mac OS
 10.13.1
Message-ID: <1514565839.68.0.213398074469.issue32447@psf.upfronthosting.co.za>


New submission from Steve Margetts <stevemargetts at me.com>:

I am trying to install Python on a Max running OS 10.13.1 (so my son can use a 'Coding for Beginners' book). Both 2.7 and 3.6 have the same problem: Clicking on IDLE leads to the icon bouncing a couple of times in the dock, but not opening a shell. I have tried re-installing and restarting post install. Typing python or python3.6 into the terminal seems to launch Python successfully (details below). I am as new to coding as my son, please phrase any advice accordingly!

Thank you.

Last login: Fri Dec 29 16:26:57 on ttys000
mkdir: /Users/Steve Margetts/.bash_sessions: Permission denied
touch: /Users/Steve Margetts/.bash_sessions/79B2448C-E769-409D-A67D-7A96F8C3C348.historynew: No such file or directory
iMac:~ Steve Margetts$ python
Python 2.7.14 (v2.7.14:84471935ed, Sep 16 2017, 12:01:12) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> help
Type help() for interactive help, or help(object) for help about object.
>>>

Last login: Fri Dec 29 16:30:16 on ttys000
mkdir: /Users/Steve Margetts/.bash_sessions: Permission denied
touch: /Users/Steve Margetts/.bash_sessions/5A516AB8-0481-4D55-A2BD-1B1017E52147.historynew: No such file or directory
iMac:~ Steve Margetts$ python3.6
Python 3.6.4 (v3.6.4:d48ecebad5, Dec 18 2017, 21:07:28) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

----------
assignee: terry.reedy
components: IDLE
messages: 309180
nosy: sm1979, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE shell won't open on Mac OS 10.13.1
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32447>
_______________________________________

From report at bugs.python.org  Fri Dec 29 13:59:48 2017
From: report at bugs.python.org (Alexander Mohr)
Date: Fri, 29 Dec 2017 18:59:48 +0000
Subject: [New-bugs-announce] [issue32448] subscriptable
Message-ID: <1514573988.38.0.213398074469.issue32448@psf.upfronthosting.co.za>


New submission from Alexander Mohr <thehesiod at gmail.com>:

Currently subscriting a attribute that's None reports the following:
>>> class Foo: pass
>>> Foo.organizer = None
>>> Foo.organizer['start']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object is not subscriptable

What would be nice is if it were to report the name of the attribute that is not subscriptable as it would greatly help in the logs, something like:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object of attribute 'organizer' is not subscriptable

just a thought.  Otherwise one would need to sprinkle their code with asserts, especially if it's a compound statement like:
Foo.organizer.blah[0], you wouldn't know which attribute wasn't None

----------
components: Interpreter Core
messages: 309187
nosy: thehesiod
priority: normal
severity: normal
status: open
title: subscriptable
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32448>
_______________________________________

From report at bugs.python.org  Fri Dec 29 16:59:35 2017
From: report at bugs.python.org (Yahya Abou Imran)
Date: Fri, 29 Dec 2017 21:59:35 +0000
Subject: [New-bugs-announce] [issue32449] MappingView must inherit from
 Collection instead of Sized
Message-ID: <1514584775.87.0.213398074469.issue32449@psf.upfronthosting.co.za>


New submission from Yahya Abou Imran <yahya-abou-imran at protonmail.com>:

Quoting my own post on python-ideas:

After I generate an UML diagram from collections.abc, I found very strange that MappingView inherit from Sized instead of Collection (new in python 3.6).

Yes, MappingView only define __len__ and not __iter__ and __contains__, but all of its subclasses define them (KeysView, ValuesView and ItemViews).

I tried to run the tests in test/test_collections.py after making this change and on only one fail :

Traceback (most recent call last):
  File "/usr/lib/python3.6/test/test_collections.py", line 789, in test_Collection
    self.assertNotIsInstance(x, Collection)
AssertionError: dict_values([]) is an instance of <class 'collections.abc.Collection'>

Wich is absolutely wrong, since in reality a dict_values instance has the behaviour of a Collection:

>>> vals = {1:'a', 2: 'b'}.values()
>>> 'a' in vals
True
>>> 'c' in vals
False
>>> len(vals)
2
>>> for val in vals:
...     print(val)
...    
a
b

The only lack is that it doesn't define a __contains__ method:

>>> '__contains__' in vals
False

It uses __iter__ to find the presence of the value.

But, hey: we have register() for this cases! In fact, when MappingView inherit from Collection, dict_values is considered as a subclass of Collection since it's in the register of ValuesView, causing the above bug...
So, the test have to be changed, and dict_values must be placed in the samples that pass the test, and not in the ones that fail it.

----------
messages: 309200
nosy: yahya-abou-imran at protonmail.com
priority: normal
severity: normal
status: open
title: MappingView must inherit from Collection instead of Sized
type: enhancement
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32449>
_______________________________________

From report at bugs.python.org  Fri Dec 29 20:49:41 2017
From: report at bugs.python.org (Yuri Kanivetsky)
Date: Sat, 30 Dec 2017 01:49:41 +0000
Subject: [New-bugs-announce] [issue32450] non-descriptive variable name
Message-ID: <1514598581.85.0.213398074469.issue32450@psf.upfronthosting.co.za>


New submission from Yuri Kanivetsky <yuri.kanivetsky at gmail.com>:

Not a big issue, really. At some point the code switches from "ndots" name:

https://github.com/python/cpython/blob/v3.7.0a3/Python/ast.c#L3385

to "level" name:

https://github.com/python/cpython/blob/v3.7.0a3/Python/Python-ast.c#L1671

Be it "ndots" everywhere, it could save me some time.

----------
messages: 309212
nosy: Yuri Kanivetsky
priority: normal
severity: normal
status: open
title: non-descriptive variable name
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32450>
_______________________________________

From report at bugs.python.org  Fri Dec 29 23:13:49 2017
From: report at bugs.python.org (Kevin)
Date: Sat, 30 Dec 2017 04:13:49 +0000
Subject: [New-bugs-announce] [issue32451] python -m venv activation issue
 when using cygwin on windows
Message-ID: <1514607229.33.0.213398074469.issue32451@psf.upfronthosting.co.za>


New submission from Kevin <ksw33n3y at gmail.com>:

attempts from within cygwin:

1. The Posix way:

$ python -m venv taco
$ cd taco
$ source bin/activate
-bash: $'\r': command not found
-bash: Scripts/activate: line 4: syntax error near unexpected token `$'{\r''
'bash: Scripts/activate: line 4: `deactivate () {

2. The windows way:

$ python -m venv taco
$ cd taco
$ /full/path/to/venv/taco/scripts/activate.bat
$


3. the only solution from cygwin (still not 100% functional):

$ python -m venv taco
$ cd taco
$ cd Scripts
$ cmd
C:\taco\Scripts\> activate.bat

(taco) C:\taco\Scripts\>




HOWEVER. when running "pip freeze" in number 3 it returns the system packages despite the "include-system-site-packages = False" in pyvenv.cfg 
When #3 is run inside command prompt "pip freeze" returns nothing correctly.


Come on guys, please don't make me use command prompt or powershell.

----------
messages: 309215
nosy: Kevin
priority: normal
severity: normal
status: open
title: python -m venv activation issue when using cygwin on windows
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32451>
_______________________________________

From report at bugs.python.org  Sat Dec 30 00:11:56 2017
From: report at bugs.python.org (kandhan)
Date: Sat, 30 Dec 2017 05:11:56 +0000
Subject: [New-bugs-announce] [issue32452] Brackets and Parentheses used in
 an ambiguous way
Message-ID: <1514610716.34.0.213398074469.issue32452@psf.upfronthosting.co.za>


New submission from kandhan <kandhan.kuhan at gmail.com>:

https://docs.python.org/3/tutorial/classes.html

9.10. Generator Expressions

Some simple generators can be coded succinctly as expressions using a syntax similar to list comprehensions but with "parentheses instead of brackets"

Since parentheses comes under brackets, brackets could be changed to "Square Brackets"

----------
assignee: docs at python
components: Documentation
messages: 309216
nosy: docs at python, kandhan
priority: normal
severity: normal
status: open
title: Brackets and Parentheses used in an ambiguous way
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32452>
_______________________________________

From report at bugs.python.org  Sat Dec 30 00:15:09 2017
From: report at bugs.python.org (=?utf-8?q?Niklas_Hamb=C3=BCchen?=)
Date: Sat, 30 Dec 2017 05:15:09 +0000
Subject: [New-bugs-announce] [issue32453] shutil.rmtree can have O(n^2)
 performance on large dirs
Message-ID: <1514610909.88.0.213398074469.issue32453@psf.upfronthosting.co.za>


New submission from Niklas Hamb?chen <nh2 at deditus.de>:

See http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=24412edeaf556a for the explanation and equivalent fix in coreutils.

The gist ist that deleting entries in inode order can improve deletion performance dramatically.

To obtain inode numbers and sort by them, one needs to `getdents()` all the entries ahead of time, but rmtree() already gets all dirents ahead of the deletion. https://bugs.python.org/issue28564 recently improved shutil.rmtree() performance by using scandir(), but nevertheless the returned generator is list()ed, so we already have all necessary informtaion in memory and would just have to perform an O(n) integer sort.

I propose we check if the improvements made to `rm -r` in coreutils should be ported to shutil.rmtree().

----------
components: Library (Lib)
messages: 309217
nosy: nh2
priority: normal
severity: normal
status: open
title: shutil.rmtree can have O(n^2) performance on large dirs
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32453>
_______________________________________

From report at bugs.python.org  Sat Dec 30 04:37:23 2017
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 30 Dec 2017 09:37:23 +0000
Subject: [New-bugs-announce] [issue32454] Add socket.close(fd) function
Message-ID: <1514626643.82.0.213398074469.issue32454@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

os.close(fd) of a socket fd does not work some platforms, e.g. Windows. In the past we have used socket.socket(fileno=fd).close() to close a socket in a platform independent way. With #28134 it may no longer work in all cases, most noticeable when the socket has neither been connected nor bound yet and auto-detection of type and family is used.

Instead of adding more hacks, I propose to add a socket.close(fd) function as cross-platform way to close a socket fd. It won't be the first function that mimics an o' module function. The socket module already has the undocumented socket.dup(fd) function.

----------
messages: 309224
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Add socket.close(fd) function
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32454>
_______________________________________

From report at bugs.python.org  Sat Dec 30 09:05:46 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Dec 2017 14:05:46 +0000
Subject: [New-bugs-announce] [issue32455] PyCompile_OpcodeStackEffect() and
 dis.stack_effect() are not particularly useful
Message-ID: <1514642746.19.0.213398074469.issue32455@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The information provided by PyCompile_OpcodeStackEffect() and dis.stack_effect() (added in issue19722) is not enough for practical use.

1. Some opcodes (like JUMP_IF_TRUE_OR_POP or FOR_ITER) have different stack effect when when execution is continued from the following opcode or jumped to the address specified by oparg. Thus there are two different values for stack effect of these opcodes.

2. Some opcodes (RETURN_VALUE, RAISE_VARARGS) stops execution. Their stack effect doesn't have meaning, and the following opcodes should be ignored.

3. Some opcodes (JUMP_ABSOLUTE, JUMP_RELATIVE) always jump. The opcodes following them should be ignored.

4. Some opcodes (like SETUP_FINALLY or SETUP_WITH) need additional space on the stack for raised exceptions. Their stack effect is virtual. Its value can't be used for calculating the actual position on the stack. This isn't documented.

The possible solution is to add a boolean flag for distinguishing the stack effects in case of consequent execution and jumping. Return a special sentinel or raise an exception if the opcode doesn't pass execution in this direction.

----------
components: Interpreter Core, Library (Lib)
messages: 309232
nosy: eric.snow, larry, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
status: open
title: PyCompile_OpcodeStackEffect() and dis.stack_effect() are not particularly useful
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32455>
_______________________________________

From report at bugs.python.org  Sat Dec 30 11:26:14 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Dec 2017 16:26:14 +0000
Subject: [New-bugs-announce] [issue32456] PYTHONIOENCODING=undefined doesn't
 work in Python 3
Message-ID: <1514651174.11.0.213398074469.issue32456@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

In Python 2.7 setting PYTHONIOENCODING=undefined mostly works as expected.

$ PYTHONIOENCODING=undefined python -c 'print(123)'
123
$ PYTHONIOENCODING=undefined python -c 'print("abc")'
abc
$ PYTHONIOENCODING=undefined python -c 'print(u"abc")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/encodings/undefined.py", line 19, in encode
    raise UnicodeError("undefined encoding")
UnicodeError: undefined encoding

Most tests (except test_doctest and test_gdb) are passed with PYTHONIOENCODING=undefined.

But in Python 3 setting PYTHONIOENCODING=undefined seems just silently terminates the interpreter (exited with code 1).

----------
components: IO, Interpreter Core, Unicode
messages: 309237
nosy: benjamin.peterson, ezio.melotti, lemburg, ncoghlan, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: PYTHONIOENCODING=undefined doesn't work in Python 3
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32456>
_______________________________________

From report at bugs.python.org  Sat Dec 30 13:58:32 2017
From: report at bugs.python.org (Ray Donnelly)
Date: Sat, 30 Dec 2017 18:58:32 +0000
Subject: [New-bugs-announce] [issue32457] Windows Python cannot handle an
 early PATH entry containing ".." and python.exe
Message-ID: <1514660312.79.0.213398074469.issue32457@psf.upfronthosting.co.za>


New submission from Ray Donnelly <rdonnelly at anaconda.com>:

Over on the Anaconda Distribution we received a (private) bug report about a crash when trying to use scons. I thought initially it was due to one of our patches but I tested it out with official CPython and also with WinPython and ran into the same crash.

To reproduce this, from cmd.exe on CPython (here I installed CPython as part of Visual Studio 2017, then updated it to the latest 3.6.4 release):

```
set "PATH=C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python36_64\Scripts\..;%PATH%"

python.exe

..

python
Fatal Python error: Py_Initialize: unable to load the file system codec
ModuleNotFoundError: No module named 'encodings'

Current thread 0x00000328 (most recent call first):
```

The trigger for this bug is the following batch code in scons.bat:

https://bitbucket.org/scons/scons/src/c0172db149b1a151eeb76910d55c81746bfede05/src/script/scons.bat?at=default&fileviewer=file-view-default#scons.bat-19

My current thinking is that the best fix here is to modify get_progpath()/get_program_full_path() so that it uses PathCchCanonicalizeEx() at https://github.com/python/cpython/blob/9bee329130aae5a13050c08dab9d349b76e66835/PC/getpathp.c#L558-L559

----------
components: Windows
messages: 309242
nosy: Ray Donnelly, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows Python cannot handle an early PATH entry containing ".." and python.exe
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32457>
_______________________________________

From report at bugs.python.org  Sat Dec 30 14:20:50 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Dec 2017 19:20:50 +0000
Subject: [New-bugs-announce] [issue32458] test_asyncio failures on Windows
Message-ID: <1514661650.99.0.213398074469.issue32458@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

It seems test_asyncio fails sporadically on AppVeyor:
https://ci.appveyor.com/project/python/cpython/build/3.7.0a0.10081#L2650

======================================================================
ERROR: test_start_tls_server_1 (test.test_asyncio.test_sslproto.ProactorStartTLS)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\projects\cpython\lib\test\test_asyncio\test_sslproto.py", line 284, in test_start_tls_server_1
    asyncio.wait_for(main(), loop=self.loop, timeout=10))
  File "C:\projects\cpython\lib\asyncio\base_events.py", line 440, in run_until_complete
    return future.result()
  File "C:\projects\cpython\lib\asyncio\tasks.py", line 398, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
======================================================================
FAIL: test_start_tls_server_1 (test.test_asyncio.test_sslproto.ProactorStartTLS)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\projects\cpython\lib\test\test_asyncio\functional.py", line 43, in tearDown
    self.fail('unexpected calls to loop.call_exception_handler()')
AssertionError: unexpected calls to loop.call_exception_handler()

----------
components: Library (Lib), Tests
messages: 309244
nosy: asvetlov, giampaolo.rodola, pitrou, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio failures on Windows
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32458>
_______________________________________

From report at bugs.python.org  Sun Dec 31 00:27:01 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 31 Dec 2017 05:27:01 +0000
Subject: [New-bugs-announce] [issue32459] Capsule API usage docs are
 incompatible with module reloading (etc)
Message-ID: <1514698021.73.0.467229070634.issue32459@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

After commenting [1] on the fact that the current datetime module C API [2] is problematic due to its reliance on C level global variables, I discovered that this is actually the outcome of our recommended approach to using capsules to export a C API as function pointers: https://docs.python.org/3/extending/extending.html#providing-a-c-api-for-an-extension-module

So we first need to fix the documentation to propose a reloading friendly way of using capsules in other extension modules, and then we can then propose updating the public datetime C API accordingly (probably by defining new macros that accept the capsule reference as their first argument).

[1] https://bugs.python.org/issue10381#msg309214
[2] https://docs.python.org/3/c-api/datetime.html
[3] https://docs.python.org/3/extending/extending.html#providing-a-c-api-for-an-extension-module

----------
messages: 309266
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Capsule API usage docs are incompatible with module reloading (etc)
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32459>
_______________________________________

From report at bugs.python.org  Sun Dec 31 00:32:37 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 31 Dec 2017 05:32:37 +0000
Subject: [New-bugs-announce] [issue32460] don't use tentative declarations
Message-ID: <1514698357.94.0.467229070634.issue32460@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

Tentative declarations (non-extern declarations without initializers) are legacy C-ism that we should eschew by ensuring all our declarations have initializers.

----------
components: Build
messages: 309269
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: don't use tentative declarations
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32460>
_______________________________________

From report at bugs.python.org  Sun Dec 31 02:53:32 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 31 Dec 2017 07:53:32 +0000
Subject: [New-bugs-announce] [issue32461] the first build after a change to
 Makefile.pre.in uses the old Makefile
Message-ID: <1514706812.13.0.467229070634.issue32461@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

After applying the attached Makefile.pre.in.diff that changes the text of the message printed by the 'Makefile' target, the make command gives:

$ make
CONFIG_FILES=Makefile.pre CONFIG_HEADERS= /bin/sh config.status
config.status: creating Makefile.pre
make -f Makefile.pre Makefile
make[1]: Entering directory '/path/to/master'
/bin/sh ./Modules/makesetup -c ./Modules/config.c.in \
                        -s Modules \
                        Modules/Setup.local \
                        Modules/Setup
This is the new Makefile. The Makefile was updated, you may need to re-run make.  <--- new Makefile
make[1]: Leaving directory '/path/to/master'
/bin/sh ./Modules/makesetup -c ./Modules/config.c.in \
                        -s Modules \
                        Modules/Setup.local \
                        Modules/Setup
The Makefile was updated, you may need to re-run make.                            <--- old Makefile
gcc -pthread -c -Wno-unused-result -Wsign-compare -g -Og -Wall -Wstrict-prototypes    -std=c99 -Wext
ra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-functio
n-declaration   -I. -I./Include    -DPy_BUILD_CORE \
        -DABIFLAGS='"dm"' \
        -DMULTIARCH=\"x86_64-linux-gnu\" \
        -o Python/sysmodule.o ./Python/sysmodule.c
....


The two messages printed by the 'Makefile' target show that make is still running the previous Makefile after completing the sub-make (i.e. after the line "make[1]: Leaving directory '/path/to/master'").

----------
components: Build
files: Makefile.pre.in.diff
keywords: patch
messages: 309270
nosy: xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: the first build after a change to Makefile.pre.in uses the old Makefile
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47356/Makefile.pre.in.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32461>
_______________________________________

From report at bugs.python.org  Sun Dec 31 06:07:49 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 31 Dec 2017 11:07:49 +0000
Subject: [New-bugs-announce] [issue32462] mimetypes.guess_type() might be
 return None or a tuple with (type/subtype, encoding)
Message-ID: <1514718469.31.0.467229070634.issue32462@psf.upfronthosting.co.za>


New submission from Cheryl Sabella <chekat2 at gmail.com>:

On a Windows 7 system, entering the following:

    >>> mime, encoding = mimetypes.guess_type('Untitled.sql')
    >>> mime
    'text\\plain'

Meaning, the return value is 'text\\plain' instead of 'text/plain'.  Tracking this down, it's due to .sql being loaded from the Windows registry and the registry is using the wrong slash.

The mimetypes.guess_type() documentation states:
> The return value is a tuple (type, encoding) where type is None if    > the type can?t be guessed (missing or unknown suffix) or a string of
> the form 'type/subtype', usable for a MIME content-type header.

I don't know if guess_type() (or add_types) should check for a valid types, if .sql should be added to the valid types (it's on the IANA page), or if the documentation should be fixed so it doesn't look like a guarantee.  Or all three.  :-)

----------
components: Library (Lib)
messages: 309275
nosy: csabella
priority: normal
severity: normal
status: open
title: mimetypes.guess_type() might be return None or a tuple with (type/subtype, encoding)
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32462>
_______________________________________

From report at bugs.python.org  Sun Dec 31 06:12:31 2017
From: report at bugs.python.org (Nick McElwaine)
Date: Sun, 31 Dec 2017 11:12:31 +0000
Subject: [New-bugs-announce] [issue32463] problems with shutil.py and
 os.get_terminal_size
Message-ID: <1514718751.47.0.467229070634.issue32463@psf.upfronthosting.co.za>


New submission from Nick McElwaine <nmcelwaine at gmail.com>:

os.get_terminal_size() fails with () or (0) or (1)

shutil.sys fails calling it with (sys.__stdout__.fileno())
 because sys.__stdout__ is type None

----------
components: Windows
messages: 309276
nosy: Dhruve, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: problems with shutil.py and os.get_terminal_size
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32463>
_______________________________________

From report at bugs.python.org  Sun Dec 31 06:44:32 2017
From: report at bugs.python.org (Srinivas Reddy T)
Date: Sun, 31 Dec 2017 11:44:32 +0000
Subject: [New-bugs-announce] [issue32464] raise NotImplemented vs return
 NotImplemented
Message-ID: <1514720672.06.0.467229070634.issue32464@psf.upfronthosting.co.za>


New submission from Srinivas  Reddy T <thatiparthysreenivas at gmail.com>:

I ran these queries on cpython repo.

?  cpython git:(master) ? grep -r . -e return  --include=\*.py  | grep NotImplemented | wc -l
196

?  cpython git:(master) ? grep -r . -e raise   --include=\*.py  | grep NotImplemented | wc -l
295

I have always used raise NotImplemented or raise NotImplementedError. But when does it make sense to return NotImplemented?

----------
messages: 309277
nosy: thatiparthy
priority: normal
severity: normal
status: open
title: raise NotImplemented vs return NotImplemented
type: resource usage
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32464>
_______________________________________

From report at bugs.python.org  Sun Dec 31 09:01:24 2017
From: report at bugs.python.org (chansol kim)
Date: Sun, 31 Dec 2017 14:01:24 +0000
Subject: [New-bugs-announce] [issue32465] [urllib] proxy_bypass_registry -
 extra error handling required for ProxyOverride,
 Windows under proxy environment
Message-ID: <1514728884.14.0.467229070634.issue32465@psf.upfronthosting.co.za>


New submission from chansol kim <chansoli at gmail.com>:

[Problem]
- String value from registry Proxy override is read and incorrectly decides the current connection requires not to use proxy.

[Setup]
- Using urllib under proxy environment.
- Proxy bypass settings are in place. ProxyOverride string value in registry ends with ;

[Detail]
https://github.com/python/cpython/blob/2.7/Lib/urllib.py
proxy_bypass_registry has an issue
1. It gets registry value from HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings ProxyEnable string value.
2. Splits the string with ;. And as the registry value ends with ; the split list contains a zero length string at the end.
3. Use the split string to re.match. And as there is zero length string at the end it, and the result of re.match('', 'anystring', re.I) is always not None.
4. Afterwards connection is attempted without using the proxy, hence connection cannot be made

>From line 1617

        proxyOverride = proxyOverride.split(';')
        # now check if we match one of the registry values.
        for test in proxyOverride:
            if test == '<local>':
                if '.' not in rawHost:
                    return 1
            test = test.replace(".", r"\.")     # mask dots
            test = test.replace("*", r".*")     # change glob sequence
            test = test.replace("?", r".")      # change glob char
            for val in host:
                # print "%s <--> %s" %( test, val )
                if re.match(test, val, re.I):
                    return 1

----------
components: Library (Lib)
messages: 309284
nosy: chansol kim
priority: normal
severity: normal
status: open
title: [urllib] proxy_bypass_registry - extra error handling required for ProxyOverride, Windows under proxy environment
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32465>
_______________________________________

From report at bugs.python.org  Sun Dec 31 09:53:55 2017
From: report at bugs.python.org (Gordon P. Hemsley)
Date: Sun, 31 Dec 2017 14:53:55 +0000
Subject: [New-bugs-announce] [issue32466] Remove fractions._gcd()
Message-ID: <1514732035.0.0.467229070634.issue32466@psf.upfronthosting.co.za>


New submission from Gordon P. Hemsley <gphemsley at gphemsley.org>:

I noticed that there was a single line of Lib/fractions.py that did not have test coverage: the normalize step for fractions with non-integer numerators and/or denominators.

I initially was going to implement a test for that line, but upon further reflection, I cannot envision a scenario where that would be possible. The code already requires its initial parameters to be numbers.Rational and then normalizes their numerators and denominators to be integers.

So, instead, I propose to remove this check, first introduced in issue22486, and to roll the fractions._gcd() function up into the deprecated fractions.gcd().

----------
components: Library (Lib), Tests
messages: 309288
nosy: gphemsley, mark.dickinson, rhettinger
priority: normal
severity: normal
status: open
title: Remove fractions._gcd()
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32466>
_______________________________________

From report at bugs.python.org  Sun Dec 31 10:36:24 2017
From: report at bugs.python.org (Yahya Abou Imran)
Date: Sun, 31 Dec 2017 15:36:24 +0000
Subject: [New-bugs-announce] [issue32467] dict_values isn't considered a
 Collection nor a Container
Message-ID: <1514734584.09.0.467229070634.issue32467@psf.upfronthosting.co.za>


New submission from Yahya Abou Imran <yahya-abou-imran at protonmail.com>:

a `dict_values` instance behaves like a Collection (a Sized Iterable Container):

>>> values = {1: 'one', 2: 'two'}.values()
>>> 'two' in values
True
>>> 'three' in values
False
>>> for value in values: print(value)
one
two
>>> len(values)
2

But...

>>> isinstance(values, abc.Collection)
False
>>> isinstance(values, abc.Container)
False

The reason is the lack of __contains__():

>>> '__contains__' in dir(values)
False

The 'in' operator works above because it uses __iter__() to check the presence of the value.

I think it's inconsistent with the fact that dict_values is in the registry of ValuesView witch passes the test:

>>> issubclass(abc.ValuesView, abc.Collection)
True

A class passed in the registry of ValuesView should guarantee this behaviour (witch is the case here by the way, but informally).


I can think about several solutions for this:

1. add a __contains__() to the dict_values class;
2. if an ABC is considered a subclass of another ABC, all the classes in  the registry of the first (and recursively all of their subclasses) should be too;
3. pass dict_values in the registry of Container or Collection;
4. make ValuesView inherit from Container or Collection.


IMHO:

1 is out.
2 makes sense, but may be difficult to implement since it implies that a class has to know all the registries it's been passed in.
3 and 4 are by far the easiest ways to do it.


I think the inheritance from Collection is the best solution, because KeysView and ItemsView are already Collections by inheriting from Set witch inherits from Collection. The only fondamental difference between the three views (in terms of protocol and API), it's that ValuesView is not a Set.

----------
messages: 309289
nosy: yahya-abou-imran
priority: normal
severity: normal
status: open
title: dict_values isn't considered a Collection nor a Container
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32467>
_______________________________________

From report at bugs.python.org  Sun Dec 31 14:14:55 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 Dec 2017 19:14:55 +0000
Subject: [New-bugs-announce] [issue32468] Frame repr should be more helpful
Message-ID: <1514747695.25.0.467229070634.issue32468@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Currently a frame's repr looks like this:

>>> f
<frame object at 0x7f7b8a8ecb08>

It would be more helpful if it displayed something like:

>>> f
<frame object at 0x7f7b8a8ecb08, file "/home/antoine/cpython/default/Lib/logging/__init__.py", line 123, code getLogger>

----------
components: Interpreter Core
messages: 309298
nosy: pitrou, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Frame repr should be more helpful
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32468>
_______________________________________

From report at bugs.python.org  Sun Dec 31 14:53:29 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 Dec 2017 19:53:29 +0000
Subject: [New-bugs-announce] [issue32469] Generator and coroutine repr could
 be more helpful
Message-ID: <1514750009.12.0.467229070634.issue32469@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Currently, a generator or coroutine's repr looks like this:

>>> gen
<coroutine object f at 0x7f86c9733790>

It could instead be something like:

>>> gen
<coroutine at 0x7f86c9733790, suspended, file "/home/antoine/cpython/default/Lib/logging/__init__.py", line 123, code getLogger>

(replace "suspended" with "running" or "closed" depending on the generator's status -- i.e. gi_running and gi_frame attributes)

----------
messages: 309302
nosy: benjamin.peterson, pitrou, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Generator and coroutine repr could be more helpful
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32469>
_______________________________________

From report at bugs.python.org  Sun Dec 31 16:56:30 2017
From: report at bugs.python.org (Luka Malisa)
Date: Sun, 31 Dec 2017 21:56:30 +0000
Subject: [New-bugs-announce] [issue32470] Unexpected behavior of struct.pack
Message-ID: <1514757390.54.0.467229070634.issue32470@psf.upfronthosting.co.za>


Change by Luka Malisa <luka.malisha at gmail.com>:


----------
components: Library (Lib)
nosy: Luka Malisa
priority: normal
severity: normal
status: open
title: Unexpected behavior of struct.pack
type: behavior
versions: Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32470>
_______________________________________