[issue31839] datetime: add method to parse isoformat() output

New submission from Oren Tirosh : The object types in the datetime module can produce a standard string representation (rfc3339, a subset of iso8601) but they do not provide a method to parse it. Proposed method names: isoparse or fromisoformat. In addition, a constructor

[issue25083] Python can sometimes create incorrect .pyc files

Nick Coghlan added the comment: Adding a couple of Red Hat folks to the nosy list, as even though this was originally reported for Windows, the reproducers show that it's a cross-platform issue. tzickel would you mind signing the Python CLA and turning your patch into a

[issue31831] EmailMessage.add_attachment(filename="long or spécial") crashes or produces invalid output

calimeroteknik added the comment: Eventually there is no bug, I was just confused at the output of print() on the EmailMessage. I noticed that in email/_header_value_parser.py policy.utf8 was True. The reason is found in email/message.py line 970 (class MIMEPart):

[issue31838] Python 3.4 supported SSL version

New submission from Mauro : Hello and sorry to bother. This is my first message to the list. I'm trying to build python 3.4.7 downloaded from python.org (released in August this year) and while following the exact same steps detailed in

[issue25083] Python can sometimes create incorrect .pyc files

Gregory P. Smith added the comment: I'm un-cc'ing myself as I don't use Python 2 in an environment where we allow it to write .pyc files at application runtime. -- ___ Python tracker

[issue25083] Python can sometimes create incorrect .pyc files

Change by Gregory P. Smith : -- nosy: -gregory.p.smith ___ Python tracker ___ ___

[issue6721] Locks in the standard library should be sanitized on fork

Antoine Pitrou added the comment: Actually, we already have a doubly-linked list of buffered IO objects (for another purpose), so we can reuse that and register a single set of global callbacks. -- ___ Python tracker

[issue6721] Locks in the standard library should be sanitized on fork

Gregory P. Smith added the comment: logging is pretty easy to deal with so I created a PR. bufferedio.c is a little more work as we either need to use the posixmodule.c os.register_at_fork API or expose it as an internal C API to be able to call it to add acquires and

[issue6721] Locks in the standard library should be sanitized on fork

Change by Gregory P. Smith : -- pull_requests: +4042 ___ Python tracker ___ ___

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

Xavier de Gaye added the comment: > Ah, the discussion restarted on the other issue: > http://bugs.python.org/issue20210#msg287516 Issue 20210 has ended up as a change in the build system eventually and not the installation process, only a tiny step towards the

[issue31836] test_code_module fails after test_idle

Terry J. Reedy added the comment: Running test_code_module afte test_idle, which somewhere executes idle code that sets sys.ps1, exposed a deficiency in test_code_module. TestInteractiveConsole.test_ps1 is intended to test this code in InteractiveConsole.interact.

[issue31836] test_code_module fails after test_idle

Change by Terry J. Reedy : -- keywords: +patch pull_requests: +4041 stage: -> patch review ___ Python tracker ___

[issue31827] Remove os.stat_float_times()

Serhiy Storchaka added the comment: stat_result is a named 10-tuple, containing several additional attributes. The last three items are st_atime, st_mtime and st_ctime as integers. Accessing them by name returns floats. Isn't a time to make them floats when access

[issue29802] A possible null-pointer dereference in struct.s_unpack_internal()

Serhiy Storchaka added the comment: New changeset 73c4708630f99b94c35476529748629fff1fc63e by Serhiy Storchaka in branch 'master': Fix bytes warnings in test_struct (added in bpo-29802). (#4068)

[issue31589] Links for French documentation PDF is broken: LaTeX issue with non-ASCII characters?

jfbu added the comment: I have made a PR at https://github.com/python/cpython/pull/4069 which enhances `conf.py` with some pdflatex extra Unicode configuration. I tested it with building PDF English documentation at master (at

[issue31589] Links for French documentation PDF is broken: LaTeX issue with non-ASCII characters?

Change by jfbu : -- pull_requests: +4040 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue28655] Tests altered the execution environment in isolated mode

Change by Serhiy Storchaka : -- dependencies: +ParseError in test_all_project_files() ___ Python tracker ___

[issue31486] calling a _json.Encoder object raises a SystemError in case obj.items() returned a tuple

Change by Serhiy Storchaka : -- stage: -> needs patch versions: +Python 3.6 -Python 3.7 ___ Python tracker ___

[issue28280] Always return a list from PyMapping_Keys/PyMapping_Values/PyMapping_Items

Change by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue6721] Locks in the standard library should be sanitized on fork

Antoine Pitrou added the comment: Oh, I forgot that IO buffered objects also have a lock. So we would have to special-case those as well, unless we take the generic approach... A problem with the generic approach is that it would leave higher-level synchronization objects

[issue29802] A possible null-pointer dereference in struct.s_unpack_internal()

Change by Serhiy Storchaka : -- pull_requests: +4039 ___ Python tracker ___ ___

[issue31837] ParseError in test_all_project_files()

New submission from Serhiy Storchaka : test_all_project_files() in test_lib2to3 emits warnings in verbose mode. /home/serhiy/py/cpython/Lib/lib2to3/tests/test_parser.py:415: UserWarning: ParseError on file /home/serhiy/py/cpython/Lib/lib2to3/main.py (bad input:

[issue6721] Locks in the standard library should be sanitized on fork

Antoine Pitrou added the comment: I think we should somehow move forward on this, at least for logging locks which can be quite an annoyance. There are two possible approaches: - either a generic mechanism as posted by sbt in reinit_locks_2.diff - or a logging-specific fix

[issue28326] multiprocessing.Process depends on sys.stdout being open

Antoine Pitrou added the comment: In issue31804, we see that sys.stdout and sys.stderr can sometimes simply be None, so we must check for that too. -- nosy: +pitrou versions: -Python 3.5 ___ Python tracker

[issue31486] calling a _json.Encoder object raises a SystemError in case obj.items() returned a tuple

Oren Milman added the comment: ISTM that PR 3840 resolved this issue (as part of bpo-28280). -- ___ Python tracker ___

[issue30156] PYTHONDUMPREFS segfaults on exit

Serhiy Storchaka added the comment: Result on the same computer: Mean +- std dev: [python0] 146 ns +- 5 ns -> [python] 206 ns +- 2 ns: 1.41x slower (+41%) The difference now is smaller (41% instead of 58%) because calling with a tuple now is 16% slower.

[issue25083] Python can sometimes create incorrect .pyc files

tzickel added the comment: Added a script to check if the bug exists (provided you have an updated strace 4.15 or above). Without patch: # ./import_io_check.sh strace: Requested path 'tmp.py' resolved into '/root/tmp.py' read(3, 0x55fc3a71cc50, 4096) = -1 ENOSYS

[issue31836] test_code_module fails after test_idle

New submission from Serhiy Storchaka : $ ./python -m test -uall test_idle test_code_module Run tests sequentially 0:00:00 load avg: 0.42 [1/2] test_idle 0:00:02 load avg: 0.42 [2/2] test_code_module test test_code_module failed -- Traceback (most recent call last):

[issue26858] setting SO_REUSEPORT fails

Guido van Rossum added the comment: I assume he means that a similar piece of code should be inserted elsewhere. I am still waiting for Philip's PR though. -- ___ Python tracker

[issue16737] Different behaviours in script run directly and via runpy.run_module

Nick Coghlan added the comment: Yeah, that one I definitely think could be improved. Could you file a separate RFE suggesting that we update sys.path[0] based on __main__.__spec__.origin after we look up __main__.__spec__? That way it will only stay as the current

[issue20210] Support the *disabled* marker in Setup files

Change by Xavier de Gaye : -- pull_requests: -2537 ___ Python tracker ___ ___

[issue31831] EmailMessage.add_attachment(filename="long or spécial") crashes or produces invalid output

R. David Murray added the comment: You are correct, that is a bug. Presumably I forgot to check for non-ascii when the parameter value doesn't need to be folded. I'm not sure when I'll have time to look at this, unfortunately :(. If you can see how to fix it, you

[issue31831] EmailMessage.add_attachment(filename="long or spécial") crashes or produces invalid output

calimeroteknik added the comment: I confirm that as for the crash, the patch in gh-3488 fixes it. The first code excerpt in my initial report now outputs the following, valid headers: Content-Type: text/plain Content-Transfer-Encoding: base64 Content-Disposition:

[issue26858] setting SO_REUSEPORT fails

Xavier de Gaye added the comment: Philip, 9791c5d55f52 was commited in november 2013 and issue19901 was closed in december 2013, so how can they be an appropriate solution for a problem reported on 2017-01-13 in msg285392 ? --

[issue16737] Different behaviours in script run directly and via runpy.run_module

Jason R. Coombs added the comment: The other major difference and the only one that's affected me is the presence of sys.path[0] == ''. -- ___ Python tracker

[issue31835] _PyFunction_FastCallDict and _PyFunction_FastCallKeywords: fast path not used

New submission from Anselm Kruis : Just a minor performance issue. The C functions _PyFunction_FastCallDict() and _PyFunction_FastCallKeywords() (branch 'master', Objects/call.c) and their predecessors fast_function() and _PyFunction_FastCallDict() in

[issue25083] Python can sometimes create incorrect .pyc files

tzickel added the comment: Ignore the hash append / link at the start of each shell command (it's the output from docker, and not related to python commits). BTW, forgot to mention, of course when doing the fault injection on the .py files, the error is bad as well, it

[issue31829] Portability issues with pickle

Serhiy Storchaka added the comment: PR 4067 fixes following issues when unpickle on Unix or in binary mode files written with protocol 0 in text mode on Windows: * ints were unpickled as longs by cPickle. * bools were unpickled as longs by cPickle and as ints by

[issue25083] Python can sometimes create incorrect .pyc files

tzickel added the comment: OK, This issue has been biting me a few more times in production, so for now I've added the environment variable PYTHONDONTWRITEBYTECODE which resolves it (but it's a hack). I'm sure I am not the only one with it (recall that this is happening

[issue31314] email throws exception with oversized header input

Change by Serhiy Storchaka : -- pull_requests: -4037 ___ Python tracker ___

[issue31829] Portability issues with pickle

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +4038 stage: -> patch review ___ Python tracker ___

[issue31314] email throws exception with oversized header input

Change by Serhiy Storchaka : -- pull_requests: +4037 ___ Python tracker ___ ___

[issue31834] BLAKE2: the (pure) SSE2 impl forced on x86_64 is slower than reference

Change by Michał Górny : -- keywords: +patch pull_requests: +4036 stage: -> patch review ___ Python tracker ___

[issue16737] Different behaviours in script run directly and via runpy.run_module

Nick Coghlan added the comment: Is there a relevant discrepancy other than __file__ sometimes being absolute? If code wants to be certain that __file__ is relative to the current directory, they need to run it through os.relpath() - there's no requirement for

[issue31828] Support Py_tss_NEEDS_INIT outside of static initialisation

Nick Coghlan added the comment: Right, the cases we were aiming to cover were: - C variable declarations ("static Py_tss_t tss_key = Py_tss_NEEDS_INIT;") - dynamic allocation with PyThread_tss_alloc - resetting a key back to the uninitialised state with PyThread_tss_delete

[issue31834] BLAKE2: the (pure) SSE2 impl forced on x86_64 is slower than reference

New submission from Michał Górny : The setup.py file for Python states: if (not cross_compiling and os.uname().machine == "x86_64" and sys.maxsize > 2**32): # Every x86_64 machine has at least SSE2. Check for sys.maxsize