[issue37513] Fix a type error in ctypes.rst

hai shi added the comment: or the value error replace type error in struct_init(). -- ___ Python tracker ___ ___ Python-bugs-list

[issue37513] Fix a type error in ctypes.rst

Change by hai shi : -- keywords: +patch pull_requests: +14429 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14615 ___ Python tracker ___

[issue37513] Fix a type error in ctypes.rst

New submission from hai shi : Python 3.9.0a0 (heads/master-dirty:80097e0, Jul 6 2019, 02:14:54) [GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import * >>> class POINT(Structure): ... _fields_ = [("x",

[issue37508] A wrong return type in memory.rst

miss-islington added the comment: New changeset cf294c48e4f97117f708c116362208d28ebfe08f by Miss Islington (bot) in branch '3.8': closes bpo-37508: Fix name of type in memory.rst. (GH-14604) https://github.com/python/cpython/commit/cf294c48e4f97117f708c116362208d28ebfe08f --

[issue37508] A wrong return type in memory.rst

miss-islington added the comment: New changeset af5e62e9e2b56017d3716fce40d959adfb753554 by Miss Islington (bot) in branch '3.7': closes bpo-37508: Fix name of type in memory.rst. (GH-14604) https://github.com/python/cpython/commit/af5e62e9e2b56017d3716fce40d959adfb753554 -- nosy:

[issue37508] A wrong return type in memory.rst

Benjamin Peterson added the comment: New changeset 39a5d17a7f1387582eb484422df450bc09a5543e by Benjamin Peterson (Hai Shi) in branch 'master': closes bpo-37508: Fix name of type in memory.rst. (GH-14604) https://github.com/python/cpython/commit/39a5d17a7f1387582eb484422df450bc09a5543e

[issue37508] A wrong return type in memory.rst

Change by miss-islington : -- pull_requests: +14428 pull_request: https://github.com/python/cpython/pull/14614 ___ Python tracker ___

[issue37508] A wrong return type in memory.rst

Change by miss-islington : -- pull_requests: +14427 pull_request: https://github.com/python/cpython/pull/14613 ___ Python tracker ___

[issue37221] PyCode_New API change breaks backwards compatibility policy

STINNER Victor added the comment: I created https://github.com/cython/cython/issues/3034 "Cython doesn't work on Python 3.8 beta2" -- ___ Python tracker ___

[issue37221] PyCode_New API change breaks backwards compatibility policy

STINNER Victor added the comment: I reopen the issue. Cython 0.29.11 doesn't work on Python 3.8 beta2. Installation fails with a compiler error: Cython-0.29.11/Cython/Plex/Scanners.c:7244:274: error: macro "__Pyx_PyCode_New" requires 16 arguments, but only 15 given Cython commit

[issue37510] argparse removing more "--" than it should

paul j3 added the comment: There are earlier bug/issues about the '--'. Also look at the parser code itself. Keep in mind that parsing is done in two passes - once to identify flags versus arguments ('O/A') and then to allocate strings to arguments. I don't recall when '--' is being

[issue37512] Error in the documentation about string concatenation

Steven D'Aprano added the comment: Eric is correct that this is a CPython optimization, it is not a language feature. Furthermore, it is an optimization that can be affected by rather subtle factors such as the operating system memory management. Here is a thread demonstrating that code

[issue37510] argparse removing more "--" than it should

Change by Karthikeyan Singaravelan : -- nosy: +paul.j3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37367] octal escapes applied inconsistently throughout the interpreter and lib

Jeffrey Kintscher added the comment: Here is the problematic code in _PyBytes_DecodeEscape in Objects/bytesobject.c: c = s[-1] - '0'; if (s < end && '0' <= *s && *s <= '7') { c = (c<<3) + *s++ - '0'; if (s < end && '0' <= *s && *s <=

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: > Which should be fixed, if possible. But, as damage goes - sorry! - it just > seems minimal to me. I think I failed to express myself correctly there :( I have absolutely no problem with the way that behaves currently, I just wanted to point out

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Tim Peters added the comment: > we could say that it does not matter if > > def f(): > if 0: > yield > > should be or not a generator Slippery slope arguments play better if they're made _before_ a decade has passed after the slope was fully greased. There's nothing accidental about

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: > So, to my eyes, absolutely nothing of the optimization remained. At least > not in the example Ned posted here. This is because his example did not include the changes in PR14116 that implemented that. --

[issue37510] argparse removing more "--" than it should

Jorge L. Martinez added the comment: To be clear, my opinion is that a single call of parse_args() should only ever remove the first "--". Right now, it seems that it removes the first of each argument group, as determined by nargs, I guess. --

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Tim Peters added the comment: > Using jumps is not removing the optimization > entirely, is just a weaker and more incomplete > way of doing the same. Sorry, I'm afraid I have no idea what that means. The generated code before and after was wildly different, as shown in Ned's original

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: I think I have found a simple way to make everyone happy: we can add a new field to the compiler that tells it to not emit bytecode. In this way we can detect errors by walking the blocks but no bytecode will be emitted. I have updated PR 14612 to

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: > It's the expected result of fixing a bug _by_ eliminating the optimization > entirely. Using jumps is not removing the optimization entirely, is just a weaker and more incomplete way of doing the same. The optimization introduced the bug in the

[issue17535] IDLE: Add an option to show line numbers along the left side of the editor window, and have it enabled by default.

Tal Einat added the comment: I've made some significant improvements in several aspects: 1. Scrolling: performance and behavior 2. Selection entire lines by dragging over line numbers 3. Color config: a separate highlighting setting for line numbers, which takes effect immediately I've

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: Tim, you made very good points in you email to Python-dev. I am convinced that the better thing to do at this pointis to revert this until we can think this a bit more :) I have made a PR to revert the change, could you review it, please? --

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Tim Peters added the comment: > This is the expected result of fixing a bug that has been > open since 2008 It's the expected result of fixing a bug _by_ eliminating the optimization entirely. It's not an expected result of merely fixing the bug. It's quite obviously _possible_ to note

[issue37512] Error in the documentation about string concatenation

Eric V. Smith added the comment: It's my understanding that this is a quality of implementation issue, and that in other (non-CPython) implementations, the run time for repeated concatenation may indeed be quadratic. The optimization in CPython relies on knowing the reference count is 1. If

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +14426 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14612 ___ Python tracker

[issue37510] argparse removing more "--" than it should

Change by Eric V. Smith : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37478] Docs: Method os.chdir() does not mention errors that can be raised

Kyle Stanley added the comment: Actually, I don't believe that I have the appropriate permissions to manually specify reviewers for PRs in the cpython repository. Do I have to be added a member of the Python organization on GitHub for this? I'm registered as a PSF contributing member, but I

[issue37478] Docs: Method os.chdir() does not mention errors that can be raised

Change by Kyle Stanley : -- keywords: +patch pull_requests: +14425 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14611 ___ Python tracker ___

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: > I see optimizing away 'if __debug__: ...' clauses, when __debug__ is False > (and 0) as currently documented language behavior, not a 'deep implementation > detail'. https://docs.python.org/3/reference/simple_stmts.html#the-assert-statement I don't

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: > In either case, I don't think it should have been applied as is in b2 Just to clarify: this was added before beta2. -- ___ Python tracker

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Ned Deily added the comment: For the record, this change in behavior was originally backported to the 3.7 branch and appeared in 3.7.4rc1 and rc2. Now that the compatibility issues are clearer, it will be reverted for 3.7.4 final and will not be considered for future 3.7.x releases.

[issue37478] Docs: Method os.chdir() does not mention errors that can be raised

Kyle Stanley added the comment: Thanks for the feedback terry. Do you think it would be helpful to work through some of the other commonly used functions in OS, adding condensed explanations of exceptions which can be raised? In general, it seems quite useful for users to be able to figure

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Paul Ganssle added the comment: > CPython has acted the current way for about 15 years (since 2.4 was > released), and this is the first time anyone has raised an objection. This is the expected result of fixing a bug that has been open since 2008 (11 years), which itself was noticed

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Terry J. Reedy added the comment: I agree with Tim. Detect SyntaxErrors in dead code if you can, but don't change the current code deletion, at least not without proper discussion (which Pablo just started on pydev). The latter is what I consider to be a release blocker needing release

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: > CPython has acted the current way for about 15 years (since 2.4 was > released), and this is the first time anyone has raised an objection. Although I tend to agree with your words, I have to insist that correctness in the reference implementation

[issue37130] pathlib.Path.with_name() handles '.' and '..' inconsistently

Brett Cannon added the comment: Thinking about this a bit, I my gut says having Path('.').name == '.' makes more sense than returning ''. My reasoning is that in any case where there's a single value -- e.g. Path('spam') -- you end up with the part returned in `name`. That suggests to me

[issue37512] Error in the documentation about string concatenation

New submission from Dmitriy : There is an error in documentation about string concatenation: https://docs.python.org/3/library/stdtypes.html --- Common Sequence Operations [...] 6. Concatenating immutable sequences always results in a new object. This means that building up a sequence by

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Tim Peters added the comment: There's "correctness" that matters and "correctness" that's merely pedantic ;-) CPython has acted the current way for about 15 years (since 2.4 was released), and this is the first time anyone has raised an objection. That's just not enough harm to justify

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: I have opened a thread in Python dev: https://mail.python.org/archives/list/python-...@python.org/thread/RHP4LTM4MSTAPJHGMQGGHERYI4PZR23R/ -- ___ Python tracker

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Mark Williams added the comment: As a user of Python who maintains at least one large code base, I rely on coverage to limit the damage my changes can inflict. Some of the code I maintain uses __debug__; I would not expect moving to 3.8 to be the cause of reduced line coverage in that

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: CPython being the reference implementation of Python, people could interpret that this optimization is part of the language and its behavior should be mirror in every other implementation. That's why under my understanding, correctness should always

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: > No tests or jumps at all. That made the optim... I understand that, but we would need a way of reporting syntax errors in blocks even if they will not be executed. Although I agree with your analysis, correctness should be prioritized over

[issue37369] Issue with pip in venv on Powershell in Windows

Paul Moore added the comment: On Fri, 5 Jul 2019 at 21:33, Steve Dower wrote: > Yeah. We probably need to be clear about which approaches are actually > supported and which ones are not. > > Ultimately though, I think this is a situation where the breakage is forced > upon us (by the

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Tim Peters added the comment: I hate this change :-( The code generated for something like this today: def f(): if 0: x = 1 elif 0: x = 2 elif 1: x = 3 elif 0: x = 4 else: x = 5 print(x) is the same as for: def f(): x = 3

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: > To add to the confusion, the treatment of "if __debug__:" and "if not > __debug__:" is now asymmetric: After the code in PR 14116 this becomes: 5 0 LOAD_GLOBAL 0 (print) 2 LOAD_CONST 1 ('debug')

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: >Before this change, code could have had an unreported SyntaxError, but it was >code that was being discarded by the optimizer anyway if __debug__ can a valid form of if 0 and therefore any syntax error will not be reported until that branch becomes

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Ned Batchelder added the comment: To add to the confusion, the treatment of "if __debug__:" and "if not __debug__:" is now asymmetric: Here is debug.py: import dis import sys print(sys.version) def f(): if __debug__: print("debug") else: print("not debug") if

[issue37510] argparse removing more "--" than it should

Jorge L. Martinez added the comment: Sorry, I forgot to add details on my machine. Python: 3.7.3 OS: Archlinux -- ___ Python tracker ___

[issue37511] mmap module add OpenBSD MADV_CONCEAL flag

Change by David Carlier : -- nosy: David Carlier priority: normal pull_requests: 14424 severity: normal status: open title: mmap module add OpenBSD MADV_CONCEAL flag versions: Python 3.9 ___ Python tracker

[issue18374] ast.parse gives wrong position (col_offset) for some BinOp-s

Change by Carl Friedrich Bolz-Tereick : -- pull_requests: +14423 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/14607 ___ Python tracker

[issue37510] argparse removing more "--" than it should

New submission from Jorge L. Martinez : $ python -c ' import argparse p = argparse.ArgumentParser() p.add_argument("first_arg") p.add_argument("args", nargs="*") r = p.parse_args(["foo", "--", "bar", "--", "baz", "--", "zap"]) print(r.first_arg + " " + " ".join(r.args)) '

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Ned Batchelder added the comment: I can see the logic of the argument that says the code exists, and should be measured. But this is changing behavior that has been in place for at least 15 years. Before this change, code could have had an unreported SyntaxError, but it was code that was

[issue37369] Issue with pip in venv on Powershell in Windows

Steve Dower added the comment: > I'm pretty sure there is code in the wild that expects / > python.exe to be the Python executable (when you're not in a virtual > environment) ... for example, when getting > sys.prefix from the registry (um, I don't think that's right, as the > executable

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Stefan Behnel added the comment: > it should not be rely upon IMHO, the correct behaviour under coverage analysis is to keep the code and not discard it. After all, it is code that exists, and that is not being executed, so it should count as uncovered code. The fact that some Python

[issue37369] Issue with pip in venv on Powershell in Windows

Paul Moore added the comment: On Thu, 27 Jun 2019 at 18:08, Steve Dower wrote: > However, it does mean that we need to start reporting a sys.executable that > is not inside sys.prefix, and I'm not sure whether that is a good idea. > > Looking at venv (+Vinay for confirmation here), it seems

[issue37487] PyList_GetItem() document regarding index

Terry J. Reedy added the comment: Good catch. (In the future, try to include the url, as below.) The full sentence in question, at https://docs.python.org/3/c-api/list.html#c.PyList_GetItem, is "The position must be positive, indexing from the end of the list is not supported." 'positive'

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Ned Batchelder added the comment: I don't know what you mean by, "it should not be rely upon." Are you saying that in 3.8 you want to keep the lines in the compiled bytecode? Do you understand the implications for coverage measurement? -- ___

[issue37496] Support annotations in signature strings.

Change by Ivan Levkivskyi : -- nosy: +levkivskyi ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37504] Documentation fails to build when using Sphinx' texinfo builder

Change by Dmitry Shachnev : -- title: 3.8 b2 now requires sphinx2, but only has documented 1.8 -> Documentation fails to build when using Sphinx' texinfo builder ___ Python tracker

[issue37504] 3.8 b2 now requires sphinx2, but only has documented 1.8

Change by Dmitry Shachnev : -- keywords: +patch pull_requests: +14421 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14606 ___ Python tracker ___

[issue37478] Docs: Method os.chdir() does not mention errors that can be raised

Terry J. Reedy added the comment: > what exactly is the standard for mentioning errors My impression is that there is none, or that it is inconsistent, but that the trend is to say more. If you want to followup, check the documentation chapters of the devguide, and if there is nothing clear

[issue18374] ast.parse gives wrong position (col_offset) for some BinOp-s

Carl Friedrich Bolz-Tereick added the comment: I think the attached patch fixes the problem. Will create a pull request soon. -- versions: +Python 3.5 -Python 3.7, Python 3.8, Python 3.9 Added file: https://bugs.python.org/file48458/binop-offset.patch

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

miss-islington added the comment: New changeset 7d93effeb4f8e86dfa283f2376ec5362275635c6 by Miss Islington (bot) (Pablo Galindo) in branch '3.7': [3.7] bpo-37500: Revert commit 85ed1712e428f93408f56fc684816f9a85b0ebc0 (GH-14605)

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Change by Pablo Galindo Salgado : -- Removed message: https://bugs.python.org/msg347367 ___ Python tracker ___ ___ Python-bugs-list

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: Ned, I have prepared PR14605 for the 3.7 branch to revert 85ed1712e428f93408f56fc684816f9a85b0ebc0. As this is somehow changing behavior in the 3.7 series, I think is the best course of action for 3.7. For 3.8 the proposed way to do this is now using

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: Ned, I have prepared PR14605 for the 3.7 branch to revert 85ed1712e428f93408f56fc684816f9a85b0ebc0. As this is somehow changing behavior in the 3.7 series, I think is the best course of action for 3.7. For 3.8 the proposed way to do this is not using

[issue37476] Adding a unit test of unicode in test_unicode.py

Change by Terry J. Reedy : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +14420 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14605 ___ Python tracker

[issue37506] os.mkdir creates invalid folder when path string has trailing space and slash

Steve Dower added the comment: Yeah, I'd rather not do this level of validation in Python. If Windows decides to reject or automatically correct this, fine, but Python is just being a thin layer over the operating system here. We shouldn't try and prevent things that the OS allows.

[issue30090] Failed to build these modules: _ctypes

hai shi added the comment: In centos, `sudo yum install -y libffi libffi-devel` should worked -- nosy: +shihai1991 ___ Python tracker ___

[issue37509] OSError preadv()

New submission from YoSTEALTH : import os import ctypes # Stdlib # -- def test_preadv_stdlib(path): fd = os.open(path, os.O_RDWR | os.O_CREAT) buffer = bytearray(10) buffers = [buffer] try: length = os.preadv(fd, buffers, 0, os.RWF_NOWAIT) # OSError: [Errno

[issue37501] Test failures when CPython is built without docstrings

Eric V. Smith added the comment: Also surprised by the marked dataclasses tests. I don't see anything there that requires docstrings. See my review on the PR. -- ___ Python tracker

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Ned Batchelder added the comment: The real-word implications from my world are this: if your code has "if 0:" clauses in it, and you measure its coverage, then because the lines have not been optimized away, coverage.py will think the lines are a possible execution path, and will be

[issue37501] Test failures when CPython is built without docstrings

Brett Cannon added the comment: Bit surprised by the test_importlib failure. What has crept into there that requires docstrings? -- nosy: +brett.cannon ___ Python tracker

[issue37504] 3.8 b2 now requires sphinx2, but only has documented 1.8

Change by Dmitry Shachnev : -- nosy: +mitya57 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37505] Early auditing broken

Christian Heimes added the comment: The hooks are about auditing the behavior of an interpreter. It's not strictly tight to some attack scenario. I would find it useful to either get back the old behavior or to have some sort of event, which indicates the start of the auditing log.

[issue37151] Calling code cleanup after PEP 590

Petr Viktorin added the comment: New changeset 7b57c03a7cb63ccfb2b8dfa82a1bf169268d80ba by Petr Viktorin (Jeroen Demeyer) in branch 'master': bpo-37151: remove _PyMethodDef_RawFastCall* functions (GH-14603) https://github.com/python/cpython/commit/7b57c03a7cb63ccfb2b8dfa82a1bf169268d80ba

[issue37505] Early auditing broken

STINNER Victor added the comment: PySys_Audit() exit immediately if ts=NULL: /* Early exit when no hooks are registered */ if (!should_audit(ts)) { return 0; } It exits before calling: /* Dtrace USDT point */ if (dtrace) { PyDTrace_AUDIT(event, (void

[issue37505] Early auditing broken

Steve Dower added the comment: Yeah, at some point we had to add an initialization check to the audit calls because of the tuple, so it essentially became a subinterpreter event but not the main one. But I thought the dtrace call happened before that check? Looking through the linked

[issue37508] A wrong return type in memory.rst

Change by hai shi : -- keywords: +patch pull_requests: +14419 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14604 ___ Python tracker ___

[issue37508] A wrong return type in memory.rst

New submission from hai shi : the result should be a bytes object in #L70 in https://github.com/python/cpython/blob/master/Doc/c-api/memory.rst -- assignee: docs@python components: Documentation messages: 347356 nosy: docs@python, shihai1991 priority: normal severity: normal status:

[issue37151] Calling code cleanup after PEP 590

Change by Jeroen Demeyer : -- pull_requests: +14418 pull_request: https://github.com/python/cpython/pull/14603 ___ Python tracker ___

[issue37421] Some tests leak temporary files

miss-islington added the comment: New changeset 229f6e85f8b4d57a2e742e0d3fc361c5bd15f1cb by Miss Islington (bot) in branch '3.8': bpo-37421: multiprocessing tests now stop ForkServer (GH-14601) https://github.com/python/cpython/commit/229f6e85f8b4d57a2e742e0d3fc361c5bd15f1cb --

[issue23312] google thinks the docs are mobile unfriendly

Change by Ned Deily : -- nosy: +mdk versions: +Python 3.9 -Python 2.7, Python 3.4, Python 3.5 ___ Python tracker ___ ___

[issue37506] os.mkdir creates invalid folder when path string has trailing space and slash

Steven D'Aprano added the comment: > it would be better for an exception to be thrown rather than creating a > corrupt folder. I am not convinced that Python should refuse to create a perfectly valid directory because some components of Windows sometimes have trouble resolving the pathname

[issue37505] Early auditing broken

STINNER Victor added the comment: I don't see how the first call to PyInterpreterState_New() can be audited: PySys_Audit() builds a tuple to call hooks, but there is no interpreter yet, so we cannot even build tuples. Are you talking about the "main" interpreter, or sub-interpreters? I'm

[issue37421] Some tests leak temporary files

STINNER Victor added the comment: I created a follow-up issue: bpo-37507 "multiprocessing: Add a stop() method to ForkServer". -- ___ Python tracker ___

[issue37507] multiprocessing: Add a stop() method to ForkServer

New submission from STINNER Victor : While working on bpo-37421, I fixed multiprocessing tests to explicitly call _run_finaliers(), so temporary directories are removed: New changeset 039fb49c185570ab7b02f13fbdc51c859cfd831e by Victor Stinner in branch 'master': bpo-37421: multiprocessing

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Ned Deily added the comment: How serious a regression is this? We still have time to revert the 3.7 commit of Issue1875 (85ed1712e428f93408f56fc684816f9a85b0ebc0) from 3.7.4 final if we act immediately. -- nosy: +ned.deily versions: +Python 3.7

[issue1875] "if 0: return" not raising SyntaxError

Ned Deily added the comment: See also discussion in Issue37500. -- nosy: +ned.deily ___ Python tracker ___ ___ Python-bugs-list

[issue37421] Some tests leak temporary files

STINNER Victor added the comment: New changeset 8fbeb14312b4c1320d31ad86e69749515879d1c3 by Victor Stinner in branch 'master': bpo-37421: multiprocessing tests now stop ForkServer (GH-14601) https://github.com/python/cpython/commit/8fbeb14312b4c1320d31ad86e69749515879d1c3 --

[issue37421] Some tests leak temporary files

Change by miss-islington : -- pull_requests: +14417 pull_request: https://github.com/python/cpython/pull/14602 ___ Python tracker ___

[issue36974] Implement PEP 590

Petr Viktorin added the comment: Buildbots are green, closing. Thank you for the implementation! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue37506] os.mkdir creates invalid folder when path string has trailing space and slash

New submission from Holly : If we use os.mkdir to create a folder as follows: os.mkdir("C:/test /") Then we successfully create a folder with name "test ". This folder can be accessed normally, but it cannot be renamed or deleted. Instead we get the following error message: Could not

[issue37505] Early auditing broken

Christian Heimes added the comment: 3.8.0b1 is also broken, so it may have been a different commit. I'm sure that I was able to see interpreter initialization with dtrace hooks. # audit.stp probe process("/usr/lib64/libpython3.8.*").provider("python").mark("audit") { printf("%s\n",

[issue37505] Early auditing broken

STINNER Victor added the comment: Oh. How can I reproduce this issue? -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue37149] link to official documentation tkinter failed !!!

Change by Guilloux : -- versions: +Python 2.7, Python 3.5, Python 3.6 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue37421] Some tests leak temporary files

STINNER Victor added the comment: ./python -u -m test test_multiprocessing_spawn -R 3:3 still fail: ERROR: test_context (test.test_multiprocessing_spawn.TestStartMethod) ERROR: test_set_get (test.test_multiprocessing_spawn.TestStartMethod) PR 14601 fix these tests when

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Ned Batchelder added the comment: Since this was backported to 3.7 but not yet released, I'm adding 3.7regression. -- keywords: +3.7regression ___ Python tracker ___

  1   2   >