[issue38290] cleanup ababstractproperty in typing.py

[hongweipeng]

New submission from hongweipeng :

`abc.ababstractproperty` was deprecated since version 3.3. 
https://docs.python.org/3/library/abc.html#abc.abstractproperty

I checked the code and found that only `typing.py` is still used. I created a 
PR and replaced it with the one written in the documentation.

--
components: Library (Lib)
messages: 353348
nosy: hongweipeng
priority: normal
severity: normal
status: open
title: cleanup ababstractproperty in typing.py
versions: Python 3.9

___
Python tracker 

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

[issue38290] cleanup ababstractproperty in typing.py

[hongweipeng]

Change by hongweipeng :


--
keywords: +patch
pull_requests: +16011
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16432

___
Python tracker 

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

[issue38290] cleanup ababstractproperty in typing.py

[miss-islington]

Change by miss-islington :


--
pull_requests: +16012
pull_request: https://github.com/python/cpython/pull/16433

___
Python tracker 

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

[issue38290] cleanup ababstractproperty in typing.py

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8

___
Python tracker 

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

[issue38160] Add a "PyInterpreterState *" field to PyTypeObject.

[Petr Viktorin]

Petr Viktorin  added the comment:

> only if PEP 573 makes it *compulsory* for heap types to contain a pointer to 
> their module

And that's impossible without either breaking API (or some hackery).
PyType_FromSpec doesn't get the information, and it can be easily outside 
module initialization.

One possibility is to attach the __main__ module (or sys, or some synthetic 
module) to "module-less" classes, just to have something interpreter-specific 
there. But at that point, a dedicated "PyInterpreterState *" field starts 
looking like a better alternative.
It does complicate the "chain":

instance --> type -?> module --> interpreter
   |   ^
   '---'

But, one more thing that we need to think about is static types. Those are 
shared across interpreters; the "PyInterpreterState *" field should only be 
added to PyHeapTypeObject. ISTM that until we phase out static types entirely, 
you can't get the interpreter by following pointers from a type/instance anyway.
At that point, the opt-in approach of PEP 573 starts looking more attractive 
again:

instance --> type -?> module --> interpreter

--

___
Python tracker 

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

[issue38269] AMD64 Debian PGO 3.x, AMD64 Clang UBSan 2.7 buildbots: No space left on device

[STINNER Victor]

STINNER Victor  added the comment:

> Can we close this issue?

When it's an issue about specific buildbots, I prefer to first check that the 
buildbot is back to green.

> https://buildbot.python.org/all/#/builders/47/builds/3578

AMD64 Debian PGO 3.x buildbot is back to green.

> https://buildbot.python.org/all/#builders/136/builds/311

AMD64 Clang UBSan 2.7 is back to green.

So yes, it seems like the disk has free space again ;-)

--

___
Python tracker 

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

[issue38269] AMD64 Debian PGO 3.x, AMD64 Clang UBSan 2.7 buildbots: No space left on device

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

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

[issue38160] Add a "PyInterpreterState *" field to PyTypeObject.

[STINNER Victor]

STINNER Victor  added the comment:

> No, but it means that a type A *knows* that it was created in interpreter 1 
> without relying on the current thread local storage.

What's wrong with _PyInterpreterState_GET_UNSAFE()?

This macro is based on 
_Py_atomic_load_relaxed(&_PyRuntime.gilstate.tstate_current).

If this atomic variable is an issue, do we need a better solution to get the 
current thread state and get the current interpreter?

--

___
Python tracker 

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

[issue38234] The value of Py_SetPath is not used to populate the configuration

[Kubilay Kocak]

Change by Kubilay Kocak :


--
nosy: +koobs

___
Python tracker 

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

[issue38174] Security vulnerability in bundled expat CVE-2019-15903 (fix available in expat 2.2.8)

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +16013
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/16434

___
Python tracker 

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

[issue37431] test_asyncio: test_start_tls_server_1() failed on ARMv7 Debian buster 3.7

[STINNER Victor]

STINNER Victor  added the comment:

New fail on ARMv7 Debian buster 3.x:
https://buildbot.python.org/all/#/builders/176/builds/1356

==
ERROR: test_start_tls_server_1 
(test.test_asyncio.test_sslproto.SelectorStartTLSTests)
--
Traceback (most recent call last):
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/test_asyncio/test_sslproto.py",
 line 585, in test_start_tls_server_1
self.loop.run_until_complete(run_main())
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/asyncio/base_events.py",
 line 632, in run_until_complete
raise RuntimeError('Event loop stopped before Future completed.')
RuntimeError: Event loop stopped before Future completed.

--

___
Python tracker 

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

[issue22107] tempfile module misinterprets access denied error on Windows

[And Clover]

And Clover  added the comment:

Attempting to answer the question "did this open call fail because the path was 
a directory" by implication from "do we think we ought to be able to write a 
file to this directory" is IMO doomed. There's no reliable way to determine 
whether one should be able to write to a location, short of trying to write to 
it. There isn't in general and there especially isn't on Windows, for the 
reasons discussed by Eryk and more.

I believe Billy's patch is an improvement over what we have, in as much as it's 
specifically checking for the condition we care about to work around a 
shortcoming of Windows error reporting. I would further remove the use of 
os.access, which does nothing useful (it reflects the read-only file attribute, 
which no-one uses, and which doesn't exist for directories anyway).

Yes, there is a race condition if the directory goes away between use and 
check, but it seems vanishingly unlikely this could happen by accident, and it 
could only happen on purpose if an attacker can guess the random filenames in 
which case they already have worse attacks than just making mkstemp fail. In 
general failure is a much better outcome than hanging for hours on end.

We may be overthinking this. Maybe it is OK to treat all permission errors as 
maybe-file-exists errors, like issue 18849 originally did, and just retry 
without trying to pick apart the entrails.

...just not quite as many as 2147483647 times. Given how unlikely an accidental 
filename clash is in the first place, I'm thinking a more realistic number of 
retries might be something like, 2.

`os.TMP_MAX` probably isn't a good choice in any case, as it indicates the 
number of names C's tmpnam() can come up with, which (a) is unrelated to the 
number of names _RandomNameSequence can come up with and (b) we have no 
particular reason to try to completely exhaust anyway.

--
nosy: +aclover

___
Python tracker 

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

[issue38206] Clarify that tp_dealloc must decref for heap allocated type

[miss-islington]

Change by miss-islington :


--
pull_requests: +16014
pull_request: https://github.com/python/cpython/pull/16436

___
Python tracker 

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

[issue38206] Clarify that tp_dealloc must decref for heap allocated type

[miss-islington]

miss-islington  added the comment:


New changeset 5faff977adbe089e1f91a5916ccb2160a22dd292 by Miss Islington (bot) 
(Ammar Askar) in branch 'master':
bpo-38206: Clarify tp_dealloc requirements for heap allocated types. (GH-16248)
https://github.com/python/cpython/commit/5faff977adbe089e1f91a5916ccb2160a22dd292


--
nosy: +miss-islington

___
Python tracker 

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

[issue38206] Clarify that tp_dealloc must decref for heap allocated type

[miss-islington]

miss-islington  added the comment:


New changeset 14ddca726a8cd337d0461934374b5e6bf65bf812 by Miss Islington (bot) 
in branch '3.8':
bpo-38206: Clarify tp_dealloc requirements for heap allocated types. (GH-16248)
https://github.com/python/cpython/commit/14ddca726a8cd337d0461934374b5e6bf65bf812


--

___
Python tracker 

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

[issue38291] Unclear status of the typing.io and typing.re pseudo-modules in docs and runtime

[dgelessus]

New submission from dgelessus :

According to bpo-35089 (and the GitHub issues linked there), the typing.io and 
typing.re modules should no longer be used. Starting with Python 3.6, the 
typing documentation no longer mentions the typing.io and typing.re modules, 
and instead documents their contents as part of the main typing module.

However, the typing module at runtime still supports typing.io and typing.re as 
before. Since these modules are not meant to be used anymore and are no longer 
documented, I would expect at least a DeprecationWarning when using them at 
runtime.

The documentation on this could also be a bit clearer. As long as the modules 
are still supported at runtime, I would expect the documentation to mention 
that they still exist, but shouldn't be used anymore. In its current state, the 
documentation is confusing when coming from Python 3.5 (where typing.io and 
typing.re were the only documented way to access IO, Pattern, etc., but 
accessing typing.IO and typing.Pattern directly also works at runtime).

--
assignee: docs@python
components: Documentation, Library (Lib)
messages: 353356
nosy: dgelessus, docs@python
priority: normal
severity: normal
status: open
title: Unclear status of the typing.io and typing.re pseudo-modules in docs and 
runtime
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue38239] test_gdb fails on AMD64 Fedora Stable LTO 3.8 and AMD64 RHEL8 LTO 3.x: Unexpected gdb output

[STINNER Victor]

STINNER Victor  added the comment:

> AMD64 RHEL8 LTO 3.x is green again. I will keep the issue open until all 
> mentionned buildbots are back to green (when test_gdb pass on these workers).

I checked an all buildbots mentioned in this issues are back to green 
(success). I close the issue.


> AMD64 RHEL8 LTO 3.x:
> https://buildbot.python.org/all/#/builders/312/builds/4

Green

> AMD64 RHEL8 LTO + PGO 3.7:
> https://buildbot.python.org/all/#/builders/255/builds/13

Green

> AMD64 RHEL8 LTO 3.7:
> https://buildbot.python.org/all/#/builders/293/builds/13

Green

> AMD64 RHEL8 LTO 3.8:
> https://buildbot.python.org/all/#/builders/265/builds/12

Green

> Similar issue on AMD64 Fedora Stable LTO 3.8:
> https://buildbot.python.org/all/#/builders/235/builds/2

Green

> AMD64 Fedora Stable LTO + PGO 3.7 is also affected:
> https://buildbot.python.org/all/#/builders/252/builds/2

Green

> And AMD64 Fedora Stable LTO 3.7:
> https://buildbot.python.org/all/#/builders/270/builds/2

Green

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue38270] Tests: Avoid MD5 or check for MD5 availablity

[miss-islington]

miss-islington  added the comment:


New changeset 90558158093c0ad893102158fd3c2dd9f864e82e by Miss Islington (bot) 
(Christian Heimes) in branch 'master':
bpo-38270: More fixes for strict crypto policy (GH-16418)
https://github.com/python/cpython/commit/90558158093c0ad893102158fd3c2dd9f864e82e


--

___
Python tracker 

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

[issue38292] tkinter variable classes don't link to widget if matplotlib's set_cmap() function is called before the tkinter GUI is instantiated

[Amir Emami]

New submission from Amir Emami :

TkInter variable classes don't link to a widget (tested on Checkbutton and 
Scale) if matplotlib.pyplot.set_cmap() function is called before the 
tkinter.Tk() call which instantiates the root of a TkInter GUI. There is no 
problem if it is called after this, though.

Simple example with checkbox attached below:

### Test program start ##

import matplotlib.pyplot as plt
import tkinter as tk

plt.set_cmap('viridis') # <--- when placed here, breaks the variable
root = tk.Tk()
#plt.set_cmap('viridis') # <--- when placed here, everything is fine

# creation of variable class and widget
var = tk.BooleanVar()
tk.Checkbutton(root, variable=var).pack()

# for printing result
def on_click():
print(var.get())
tk.Button(root, text="Print State to Console", command=on_click).pack()

root.mainloop()

--
components: Tkinter
files: tk and plt conflict.py
messages: 353359
nosy: amiraliemami
priority: normal
severity: normal
status: open
title: tkinter variable classes don't link to widget if matplotlib's set_cmap() 
function is called before the tkinter GUI is instantiated
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file48627/tk and plt conflict.py

___
Python tracker 

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

[issue22107] tempfile module misinterprets access denied error on Windows

[Erik Aronesty]

Erik Aronesty  added the comment:

i would like to point out that the primary reason any of this nonsense exists 
is because of short filename restrictions.   

i've replaces nearly all of my temp file creation code in all of my project to 
`return os.urandom(32).hex()` ... which is reliable secure, fast, and doesn't 
require any fileops

sure, it doesn't work on 8.3 limited systems, but maybe the NamedTemp code 
should check that *first* and *if* it's OK to use long  names... just use 
them, otherwise revert to existing behavior

--

___
Python tracker 

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

[issue38270] Tests: Avoid MD5 or check for MD5 availablity

[Christian Heimes]

Change by Christian Heimes :


--
pull_requests: +16015
pull_request: https://github.com/python/cpython/pull/16437

___
Python tracker 

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

[issue38266] Revert bpo-37878: Make PyThreadState_DeleteCurrent() Internal

[Eric Snow]

Eric Snow  added the comment:

FWIW, I support reverting the removal of PyThreadState_DeleteCurrent().  We 
only reverted under the assumption that no one was using this function.  
Clearly we were mistaken. :)

I'll re-open #37878 to revive the discussion about documenting the function 
(which we still may or may not want to do).

--

___
Python tracker 

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

[issue38266] Revert bpo-37878: Make PyThreadState_DeleteCurrent() Internal

[Eric Snow]

Eric Snow  added the comment:

FWIW, when we un-revert we should be sure to move PyThreadState_DeleteCurrent() 
from Include/pystate.h to Include/cpython/pystate.h.  (I suppose that could be 
done in a separate PR to keep the git history clear.)

--

___
Python tracker 

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

[issue38266] Revert bpo-37878: Make PyThreadState_DeleteCurrent() Internal

[Eric Snow]

Eric Snow  added the comment:

s/un-revert/revert/

--

___
Python tracker 

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

[issue38266] Revert bpo-37878: Make PyThreadState_DeleteCurrent() Internal

[Joannah Nanjekye]

Joannah Nanjekye  added the comment:

+1 for moving from Include/pystate.h to Include/cpython/pystate.h

--

___
Python tracker 

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

[issue38266] Revert bpo-37878: Make PyThreadState_DeleteCurrent() Internal

[Joannah Nanjekye]

Joannah Nanjekye  added the comment:

I will handle this later today.

--

___
Python tracker 

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

[issue38266] Revert bpo-37878: Make PyThreadState_DeleteCurrent() Internal

[STINNER Victor]

STINNER Victor  added the comment:

If we want to make the function "fully public", I suggest to write 
documentation and have a simple unit test.

--

___
Python tracker 

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

[issue38266] Revert bpo-37878: Make PyThreadState_DeleteCurrent() Internal

[Eric Snow]

Eric Snow  added the comment:

I *was* going to suggest that we also put an underscore prefix on the name, but 
I couldn't think of a reason why we would want to discourage use (other than to 
reduce the size of the [supported] public API).  Moving it to 
Include/cpython/pystate.h is probably enough.

--

___
Python tracker 

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

[issue38266] Revert bpo-37878: Make PyThreadState_DeleteCurrent() Internal

[Eric Snow]

Eric Snow  added the comment:

@Joannah, sounds good.  Thanks!

--

___
Python tracker 

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

[issue37878] Sub-Interpreters : Document PyThreadState_DeleteCurrent()

[Eric Snow]

Eric Snow  added the comment:

I've re-opened this issue to address the original point: documenting 
PyThreadState_DeleteCurrent().  FWIW, I don't see a problem with documenting it 
if we're keeping it around (which it looks like we are).

We will address reverting GH-15315 in #38266.

--
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open

___
Python tracker 

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

[issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h

[Eric Snow]

Eric Snow  added the comment:

+1 to the suggested "whatsnew" updates.  If no one beats me to it I'll work on 
a PR soon.

--

___
Python tracker 

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

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Christian Heimes]

Christian Heimes  added the comment:

Łukasz,

I haven't been able to verify that the last patches are sufficient to prevent 
Python from segfaulting. We need to wait until rc1 is out. I need a proper 
release or RPM build to run the tests on our internal test infrastructure.

You have to release rc1 with this blocker and hope for the best...

--

___
Python tracker 

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

[issue38187] test.test_tools.test_c_analyzer fails in refleak mode

[Eric Snow]

Eric Snow  added the comment:


New changeset 6693f730e0eb77d9453f73a3da33b78a97e996ee by Eric Snow in branch 
'master':
bpo-38187: Fix a refleak in Tools/c-analyzer. (gh-16304)
https://github.com/python/cpython/commit/6693f730e0eb77d9453f73a3da33b78a97e996ee


--

___
Python tracker 

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

[issue38187] test.test_tools.test_c_analyzer fails in refleak mode

[Eric Snow]

Change by Eric Snow :


--
assignee:  -> eric.snow
resolution:  -> fixed
stage: patch review -> resolved
status: open -> pending

___
Python tracker 

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

[issue37415] Error build Python with Intel compiler: doesn't provide atomic_uintptr_t

[Rainer Keller]

Rainer Keller  added the comment:

We have been experiencing the same problem with compiling Python-3.7.4 on a 
system with CentOS 7.6 (aka glib-2.17): Intel Compiler 2019.6 implements 
stdatomic.h. but lacks the definition of atomic_uintptr_t.

>From a configure-point of view just failing to define HAVE_STDATOMIC_H would 
>suffice.
Therefore just add another otherwise unused variable (which might warn & bail 
out in case of -Werror / -Werror-all)...

The following patch works for us to compile.

Granted, the "proper" way would be to add another configure check for the 
underlying type and not blurry the check for stdatomic.h -- but then again, 
Intel should just implement all of C11...

--
keywords: +patch
nosy: +rakeller
Added file: https://bugs.python.org/file48628/python.patch

___
Python tracker 

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

[issue13214] Cmd: list available completions from the cmd.Cmd subclass and filter out EOF handler(s)

[Kimball Leavitt]

Kimball Leavitt  added the comment:

I know that many people do something like:

def do_EOF(self, arg):
return True

to exit the program when you press Ctrl+d. Others might prefer something like 
ngie https://bugs.python.org/issue13214#msg145856:

def do_EOF(self, arg):
raise EOFError

The issue that I have is if the command you enter is 'EOF' (or 'EOF --some 
--arg'), you end up calling your do_EOF function. I think this unintended side 
effect could be avoided if the check for EOFError was removed and the exception 
was just raised. (see 
https://github.com/python/cpython/blob/master/Lib/cmd.py#L127).

--
nosy: +Kimball Leavitt

___
Python tracker 

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

[issue38293] Deepcopying property objects results in unexpected TypeError

[Guðni Nathan]

New submission from Guðni Nathan :

Currently, attempting to deepcopy a property object will result in an 
unexpected TypeError:

>>> import copy
>>> obj = property()
>>> new_obj = copy.deepcopy(obj)
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Program 
Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1264.0_x64__qbz5n2kfra8p0\lib\copy.py",
 line 169, in deepcopy
rv = reductor(4)
TypeError: can't pickle property objects


What I believe is happening here is that since property objects are not treated 
by the copy module as atomic, they are passed off to be pickled and so our 
error is raised.
This can be fixed in a similar manner to how it works for type objects, 
function objects and more.
Adding a single line of code to Lib/copy.py after line 208:

d[property] = _deepcopy_atomic

Means that property objects will be treated as atomic, and therefore returned 
as-is.

--
components: Library (Lib)
messages: 353375
nosy: Guðni Nathan
priority: normal
severity: normal
status: open
title: Deepcopying property objects results in unexpected TypeError
type: behavior
versions: Python 3.7

___
Python tracker 

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

[issue38293] Deepcopying property objects results in unexpected TypeError

[Guðni Nathan]

Guðni Nathan  added the comment:

A small change:

The fix should go to Lib/copy.py:198, not line 208.

--

___
Python tracker 

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

[issue38206] Clarify that tp_dealloc must decref for heap allocated type

[Ammar Askar]

Change by Ammar Askar :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue38293] Deepcopying property objects results in unexpected TypeError

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

But the property object is not atomic. It's attribute __doc__ is writeable.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

There is this PR that avoids a hard crash in the interpreter:

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

--

___
Python tracker 

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

[issue32820] Add and document __format__ method for IPv[46]Address

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 5d6f5b629394066a5249af25cc01f1a1f0edc138 by Serhiy Storchaka in 
branch 'master':
bpo-32820: Simplify __format__ implementation for ipaddress. (GH-16378)
https://github.com/python/cpython/commit/5d6f5b629394066a5249af25cc01f1a1f0edc138


--

___
Python tracker 

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

[issue38294] re.escape seems to miss some importante regex characters

[Ricardo Bánffy]

New submission from Ricardo Bánffy :

Under Python 3.6, re.escape escapes "/"

In [1]: import re

In [2]: re.escape('http://workday.com')
Out[2]: 'http\\:\\/\\/workday\\.com'

Under 3.7 and 3.8, "/" is not escaped.

In [1]: import re

In [2]: re.escape('http://workday.com')
Out[2]: 'http://workday\\.com'

Is this change deliberate? For a minor release (3.6 to 3.7) this broke some 
code that generated `sed` commands to run on a remote server.

--
components: Regular Expressions
messages: 353380
nosy: Ricardo Bánffy, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.escape seems to miss some importante regex characters
type: behavior
versions: Python 3.7, Python 3.8

___
Python tracker 

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

[issue38294] re.escape no longer escapes "/" or ":"

[Ricardo Bánffy]

Change by Ricardo Bánffy :


--
title: re.escape seems to miss some importante regex characters -> re.escape no 
longer escapes "/" or ":"

___
Python tracker 

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

[issue38295] macOS Catalina test failures

[Barry A. Warsaw]

New submission from Barry A. Warsaw :

test_py_compile fails on macOS Catalina beta (19A573a)

==
ERROR: test_relative_path (test.test_py_compile.PyCompileTestsWithSourceEpoch)
--
Traceback (most recent call last):
  File "/Users/bwarsaw/projects/python/3.8/Lib/test/test_py_compile.py", line 
30, in wrapper
return fxn(*args, **kwargs)
  File "/Users/bwarsaw/projects/python/3.8/Lib/test/test_py_compile.py", line 
111, in test_relative_path
py_compile.compile(os.path.relpath(self.source_path),
  File "/Users/bwarsaw/projects/python/3.8/Lib/py_compile.py", line 157, in 
compile
os.makedirs(dirname)
  File "/Users/bwarsaw/projects/python/3.8/Lib/os.py", line 221, in makedirs
mkdir(name, mode)
FileNotFoundError: [Errno 2] No such file or directory: 
'../../../../../../../var/folders/w6/w_2zrjgj7bgdgkhdjm4_r9s4000slb/T/tmpq3p6aoly'

==
ERROR: test_relative_path 
(test.test_py_compile.PyCompileTestsWithoutSourceEpoch)
--
Traceback (most recent call last):
  File "/Users/bwarsaw/projects/python/3.8/Lib/test/test_py_compile.py", line 
20, in wrapper
return fxn(*args, **kwargs)
  File "/Users/bwarsaw/projects/python/3.8/Lib/test/test_py_compile.py", line 
111, in test_relative_path
py_compile.compile(os.path.relpath(self.source_path),
  File "/Users/bwarsaw/projects/python/3.8/Lib/py_compile.py", line 157, in 
compile
os.makedirs(dirname)
  File "/Users/bwarsaw/projects/python/3.8/Lib/os.py", line 221, in makedirs
mkdir(name, mode)
FileNotFoundError: [Errno 2] No such file or directory: 
'../../../../../../../var/folders/w6/w_2zrjgj7bgdgkhdjm4_r9s4000slb/T/tmpquor0q8r'

--

--
components: Tests
messages: 353381
nosy: barry, ned.deily
priority: normal
severity: normal
status: open
title: macOS Catalina test failures
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue38296] unittest expectedFailure does not differentiate errors from failures

[Kit Choi]

New submission from Kit Choi :

I expect the following test to fail, because an "error" is not a "failure".
Unexpectedly, the test passes:

```
class TestFailure(unittest.TestCase):

@unittest.expectedFailure
def test_expected_failure(self):
raise TypeError()   # for example, a typo.
```

```
$ python -m unittest test_main
x
--
Ran 1 test in 0.000s

OK (expected failures=1)
```

This behaviour exists since Python 2.7, and is still true for the Python 3.8.0b1

--
components: Tests
messages: 353382
nosy: Kit Choi
priority: normal
severity: normal
status: open
title: unittest expectedFailure does not differentiate errors from failures
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue38294] re.escape no longer escapes "/" or ":"

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Yes, it is deliberate. "/" and ":" do not have special meaning in regular 
expressions and do not need escaping. re.escape() now produces more 
human-readable result and works faster.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue38293] Deepcopying property objects results in unexpected TypeError

[Guðni Nathan]

Guðni Nathan  added the comment:

Function objects are considered "atomic" here and I believe you can also write 
to their __doc__ (among other attributes).

--

___
Python tracker 

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

[issue38297] Imports at top of module is often not used

[Dominic Littlewood]

New submission from Dominic Littlewood <11dlittlew...@gmail.com>:

In PEP 8, it is stated that:
"Imports are always put at the top of the file, just after any module comments 
and docstrings, and before module globals and constants."

Note the word "always". This advice makes sense because it cuts down on 
performance costs.

I recently got into an argument about this, and so I created a script to find 
all the times in the standard library that an import statement was used inside 
a function or method. I was expecting to get one or two, but it's safe to say 
that the answer 1576 was a little surprising. (I was on 3.7.4, if anyone wants 
to check.)

It turns out that more than one in five modules (defined as any .py file) 
contain at least one violation of this rule. In the standard library, there are 
more violations of the rule than there are while loops. Do we need to either a) 
fix large parts of the standard library or b) rewrite PEP 8 to say that this 
might not actually be all that bad?

--
components: Library (Lib)
messages: 353385
nosy: plokmijnuhby
priority: normal
severity: normal
status: open
title: Imports at top of module is often not used
type: performance

___
Python tracker 

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

[issue38298] Base class of generic type has wrong `cls` argument in classmethods

[Kefei Lu]

New submission from Kefei Lu :

This is a new regression in Python3.7.


Create the following file as `test.py`

```
# test.py

import typing as t


T = t.TypeVar("T")


class BaseOfGeneric:

@classmethod
def f(cls):
# when called from an instantiated generic type, e.g.,
# `MyList[int]`, expect `cls` to be the GenericAlias with its type
# argument already insteantiated
print(f"current class is {cls}")
print(f"current class's type: {type(cls)}")


class MyList(t.List[T], BaseOfGeneric):
pass


MyIntList = MyList[int]

MyIntList.f()
```

Run with Python3.6:

>>> python3.6 ./test.py 
current class is __main__.MyList[int]
 ^^^ as expected

current class's type: 

EXPECTED BEHAVIOR: The outcome is expected: `cls` of `BaseOfGeneric.f` should 
be `MyList` **with** type argument `int`


However this is wrong in Python3.7:

>>> python3.7 ./test.py 
current class is 
 ^^^ type argument is LOST !!!

current class's type: 

Note that `cls` of `BaseOfGeneric.f` has lost the type argument `int`! It is 
not expected.

--
messages: 353386
nosy: kflu
priority: normal
severity: normal
status: open
title: Base class of generic type has wrong `cls` argument in classmethods
type: behavior
versions: Python 3.7

___
Python tracker 

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

[issue38297] Imports at top of module is often not used

[Eric V. Smith]

Eric V. Smith  added the comment:

I think PEP 8 should say "Module-level imports are always put at the top of the 
file, ...".

--
nosy: +eric.smith

___
Python tracker 

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

[issue38293] Deepcopying property objects results in unexpected TypeError

[Guðni Nathan]

Guðni Nathan  added the comment:

This bug appears to also affect shallow copies and can be reproduced with the 
following code:

>>> import copy
>>> obj = property()
>>> copy.copy(obj)
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Program 
Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1264.0_x64__qbz5n2kfra8p0\lib\copy.py",
 line 96, in copy
rv = reductor(4)
TypeError: can't pickle property objects

--

___
Python tracker 

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

[issue38294] re.escape no longer escapes "/" or ":"

[Ricardo Bánffy]

Ricardo Bánffy  added the comment:

Thanks for the clarification, Serhiy. Should we update the 3.7 docs to warn 
others about it?

--

___
Python tracker 

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

[issue38293] Deepcopying property objects results in unexpected TypeError

[Guðni Nathan]

Change by Guðni Nathan :


--
keywords: +patch
pull_requests: +16016
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16438

___
Python tracker 

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

[issue38294] re.escape no longer escapes "/" or ":"

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It is already documented. There are even examples which contain "/" and ":".

--

___
Python tracker 

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

[issue38299] build errors - latest "git pull"

[Geoge R. Goffe]

New submission from Geoge R. Goffe :

SUMMARY: AddressSanitizer: 240 byte(s) leaked in 3 allocation(s).

--
components: Build
files: build-python-3.log
messages: 353391
nosy: grgo...@yahoo.com
priority: normal
severity: normal
status: open
title: build errors - latest "git pull"
type: compile error
versions: Python 3.9
Added file: https://bugs.python.org/file48629/build-python-3.log

___
Python tracker 

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

[issue38294] re.escape no longer escapes "/" or ":"

[Ricardo Bánffy]

Ricardo Bánffy  added the comment:

Indeed. It was easy to miss because of the joining and sorting. Being explicit 
on the 3.7 changes, that '!', '"', '%', "'", ',', '/', ':', ';', '<', '=', '>', 
'@', '`' were up to 3.6 but are no longer escaped since 3.7, would be nice.

--

___
Python tracker 

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

[issue38300] Documentation says destuction of TemporaryDirectory object will also delete it, but it does not.

[Ian]

New submission from Ian :

The documentation found here 
https://docs.python.org/3.7/library/tempfile.html#tempfile.TemporaryDirectory 
states the following

"On completion of the context or destruction of the temporary directory object 
the newly created temporary directory and all its contents are removed from the 
filesystem."

However calling del on the object does not call the cleanup method.

t = tempfile.TemporaryDirectory()
del t

I'm not sure if that is incorrect documentation or my own misunderstanding of 
what you call destruction. I tested adding my own def __del__(): self.cleanup() 
which worked as I expected.

--
messages: 353393
nosy: iarp
priority: normal
severity: normal
status: open
title: Documentation says destuction of TemporaryDirectory object will also 
delete it, but it does not.
type: behavior
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue38300] Documentation says destuction of TemporaryDirectory object will also delete it, but it does not.

[Ammar Askar]

Ammar Askar  added the comment:

Hmm, I can't recreate this locally:

>>> import tempfile
>>> import os
>>> t = tempfile.TemporaryDirectory()
>>> temp_dir = t.name
>>> os.path.exists(temp_dir)
True
>>> del t
>>> os.path.exists(temp_dir)
False

What version of Python are you using?

--
nosy: +ammar2

___
Python tracker 

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

[issue37883] threading.Lock.locked is not documented

[Ido Michael]

Change by Ido Michael :


--
keywords: +patch
pull_requests: +16017
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16420

___
Python tracker 

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

[issue38243] A reflected XSS in python/Lib/DocXMLRPCServer.py

[STINNER Victor]

STINNER Victor  added the comment:


New changeset e8650a4f8c7fb76f570d4ca9c1fbe44e91c8dfaa by Victor Stinner 
(Dong-hee Na) in branch 'master':
bpo-38243, xmlrpc.server: Escape the server_title (GH-16373)
https://github.com/python/cpython/commit/e8650a4f8c7fb76f570d4ca9c1fbe44e91c8dfaa


--

___
Python tracker 

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

[issue38294] re.escape no longer escapes "/" or ":"

[Ricardo Bánffy]

Change by Ricardo Bánffy :


--
assignee:  -> docs@python
components: +Documentation -Regular Expressions
nosy: +docs@python
type: behavior -> enhancement

___
Python tracker 

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

[issue37883] threading.Lock.locked is not documented

[Tal Einat]

Tal Einat  added the comment:

For future reference, there's a nicer, more concise way to reference PRs: just 
type GH-16420 (using the relevant PR number).

--
nosy: +taleinat

___
Python tracker 

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

[issue38243] A reflected XSS in python/Lib/DocXMLRPCServer.py

[miss-islington]

Change by miss-islington :


--
pull_requests: +16019
pull_request: https://github.com/python/cpython/pull/16440

___
Python tracker 

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

[issue38243] A reflected XSS in python/Lib/DocXMLRPCServer.py

[miss-islington]

Change by miss-islington :


--
pull_requests: +16018
pull_request: https://github.com/python/cpython/pull/16439

___
Python tracker 

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

[issue38243] A reflected XSS in python/Lib/DocXMLRPCServer.py

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +16020
pull_request: https://github.com/python/cpython/pull/16441

___
Python tracker 

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

[issue38234] The value of Py_SetPath is not used to populate the configuration

[STINNER Victor]

STINNER Victor  added the comment:

Oh, the main issue has been fixed and I added a lot of tests. So I remove the 
"release blocker" priority.

I would like to keep the issue open since I plan to do one more change: use 
PyWideStringList in _PyPathConfig for module_search_paths to support paths 
which contains DELIM (":" on Unix).

--
priority: release blocker -> 

___
Python tracker 

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

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[STINNER Victor]

STINNER Victor  added the comment:

> I haven't been able to verify that the last patches are sufficient to prevent 
> Python from segfaulting. We need to wait until rc1 is out. I need a proper 
> release or RPM build to run the tests on our internal test infrastructure.

I pushed two fixes in the 3.8 branch for FreeIPA:

* I removed func_clear() which triggered the bug
* I fixed a reference cycle... in the weakref module :-)

As Pablo wrote, this issue is still open since the real deepest root issue is 
not fixed yet.

I was busy with random other stuff last weeks, so I didn't find time to dig 
into this issue again.

IMHO fixing the root issue can wait for Python 3.9 (and Python 3.8.1).

FreeIPA should now work fine on the current Python 3.8 branch.

--

___
Python tracker 

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

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[STINNER Victor]

STINNER Victor  added the comment:

I remove the "release blocker" priority since the regression has been fixed in 
Python 3.8. The main "regression" was the addition of the func_clear() 
function: I removed it.

--
priority: release blocker -> 

___
Python tracker 

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

[issue38291] Unclear status of the typing.io and typing.re pseudo-modules in docs and runtime

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

Guido, what is your final opinion on this?

--
nosy: +gvanrossum, levkivskyi

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Kyle Stanley]

Kyle Stanley  added the comment:

> Andrew, do you want me to submit a PR or you can do it?

Since this has been elevated to a release blocker, I wouldn't mind helping to 
revert this ASAP. I can open a PR to fix it today.

--

___
Python tracker 

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

[issue37883] threading.Lock.locked is not documented

[Tal Einat]

Tal Einat  added the comment:

Looking at Lib/threading.py and Modules/_threadmodule.c, it actually appears 
that RLock.locked() is only implemented by the C implementation, but not the 
Python implementation which is used as a backup.

If we're going to make the locked() method more visible by documenting it, we 
should expose such a method on the Python implementation, so that 
threading.RLock will indeed always have a locked() method.

>From a quick look, it seems that the Python RLock's _is_owned() method might 
>be just what we need, but that should be validated.

--

___
Python tracker 

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

[issue38277] Allowing conditions with assignment expressions in comprehensions without parantheses

[Terry J. Reedy]

Change by Terry J. Reedy :


--
type:  -> enhancement
versions: +Python 3.9 -Python 3.8

___
Python tracker 

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

[issue38243] A reflected XSS in python/Lib/DocXMLRPCServer.py

[miss-islington]

miss-islington  added the comment:


New changeset 39a0c730e31c6941a78da19b6a5b61170687 by Miss Islington (bot) 
in branch '3.7':
bpo-38243, xmlrpc.server: Escape the server_title (GH-16373)
https://github.com/python/cpython/commit/39a0c730e31c6941a78da19b6a5b61170687


--
nosy: +miss-islington

___
Python tracker 

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

[issue37883] threading.Lock.locked is not documented

[Tal Einat]

Change by Tal Einat :


--
Removed message: https://bugs.python.org/msg353402

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Yury Selivanov]

Yury Selivanov  added the comment:

> Since this has been elevated to a release blocker, I wouldn't mind helping to 
> revert this ASAP. I can open a PR to fix it today.

Sure, by all means, any help would be hugely appreciated.  Thank you, Kyle.

You'll need to be careful to only revert the new functions & the asyncio.Stream 
class.  Also the new docs.  Due to proximity to the deadline, please be 
prepared that we might need to abandon your pull request if it's not ready by 
Sunday morning.  In which case Andrew or I will do this ourselves.

--

___
Python tracker 

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

[issue37883] threading.Lock.locked is not documented

[Tal Einat]

Change by Tal Einat :


--
versions: +Python 2.7

___
Python tracker 

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

[issue38243] A reflected XSS in python/Lib/DocXMLRPCServer.py

[miss-islington]

miss-islington  added the comment:


New changeset 6447b9f9bd27e1f6b04cef674dd3a7ab27bf4f28 by Miss Islington (bot) 
in branch '3.8':
bpo-38243, xmlrpc.server: Escape the server_title (GH-16373)
https://github.com/python/cpython/commit/6447b9f9bd27e1f6b04cef674dd3a7ab27bf4f28


--

___
Python tracker 

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

[issue38280] Feature request: Add support to compile to native binary like as golang

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The PSF and the core developer group do not have the resources to do this.  Pie 
in the sky proposals like this should be floated on python-list or perhaps 
python-ideas, where you can get more answers as to 'Why not ...?" or perhaps 
'How to ...?".  (Several millions dollars?)

--
nosy: +terry.reedy
resolution:  -> rejected
stage:  -> resolved
status: open -> closed
versions:  -Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue38280] Add support to compile to native binary like as with golang

[Terry J. Reedy]

Change by Terry J. Reedy :


--
title: Feature request: Add support to compile to native binary like as golang 
-> Add support to compile to native binary like as with golang

___
Python tracker 

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

[issue38243] A reflected XSS in python/Lib/DocXMLRPCServer.py

[STINNER Victor]

STINNER Victor  added the comment:

@Dong-hee Na: Would you mind to try to backport the change to Python 2.7 which 
also has the bug?

--

___
Python tracker 

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

[issue38295] macOS Catalina test failures

[Terry J. Reedy]

Change by Terry J. Reedy :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Python 3.7 does not compile
type:  -> compile error

___
Python tracker 

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

[issue38295] macOS Catalina test failures

[Terry J. Reedy]

Terry J. Reedy  added the comment:

This is not a duplicate because Python *did* compile enough to fail a test.

--
components: +macOS
nosy: +ronaldoussoren, terry.reedy
resolution: duplicate -> 
stage: resolved -> needs patch
status: closed -> open
superseder: Python 3.7 does not compile -> 
type: compile error -> behavior

___
Python tracker 

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

[issue38014] Python 3.7 does not compile

[Terry J. Reedy]

Terry J. Reedy  added the comment:

#38295 gives error reports for test_py_compile with 3.8, which implies that 
Python was compiled well enough to run and fail a test.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue38277] Allowing conditions with assignment expressions in comprehensions without parantheses

[Guido van Rossum]

Change by Guido van Rossum :


--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Neil Schemenauer]

Neil Schemenauer  added the comment:

A few comments from the "peanut gallery".  Thanks to Victor and Pablo for doing 
the hard work of investigating this bug.

First, it has been a long time since Tim and I first developed gcmodule.c.  So, 
some of my understanding may be inaccurate due to code changes or old age 
memory loss. ;-P

If I understand Victor's test case correctly, the problem is caused if you have 
an extension type that implements tp_traverse but not tp_clear and that there 
is also a weakref involved in the trash cycle.  In my original design of the 
GC, not implementing tp_clear should have been okay.  It would mean that the GC 
might find garbage reference cycles that it couldn't cleanup.  Those would leak 
memory but would not crash Python.

I'm not sure what has changed since to require that tp_clear actually 
successfully clears the cycle.  Tim was the origin of the code that handles 
weakrefs. The GC is (relatively) simple if not for handling weakrefs and 
finalizers.  Tim did almost all of the difficult and brain exploding work on 
that stuff.  There was a big re-org some years ago to handle "legacy 
finalizers" and PEP 442 finalizers.  That made things more complicated yet.  
Maybe the requirement for a working tp_clear came into existence then?  I added 
Tim to the nosy list since he might have insight.

To me, it seems problematic that we would require a type to have a tp_clear 
method that actually breaks cycles.  For mutable objects like dicts and lists, 
we can have tp_clear do its thing while leaving the object in a valid state.  
The tp_clear added for functions was not like that because other code expected 
structure fields to be non-NULL.  At least that's my understanding.

Is the behavior of tp_clear the key to this bug?  In the original design GC, 
calling tp_clear was not guaranteed to cause objects in the cylce to be freed.  
So, after tp_clear, the object still needs to be in some kind of valid state.  
That is one of the reasons why the tuple type doesn't have a tp_clear (also 
that they can't normally be directly be used to create cycles).

One last observation: the reference cycle GC is now being relied upon in ways 
that were never originally envisioned.  Originally the cyclic GC was an 
optional feature and you could build Python without it.  Reference cycles were 
supposed to exist in rare cases and only be created by user code.  In that 
world, having tp_clear on the function type is be unneeded.  Now, CPython is 
creating reference cycles itself and the GC is being relied on much more to 
free memory.  I'm afraid we are evolving into a complicated and low performance 
GC (refcount + cycle collection).  I don't have any good suggestions on a 
better approach.  Maintaining the C-API ties us to reference counting.  I 
mention it because it might be helpful to have a high-level view of the 
evolution of this part of CPython.

--
nosy: +nascheme, tim.peters

___
Python tracker 

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

[issue38296] unittest expectedFailure does not differentiate errors from failures

[Terry J. Reedy]

Terry J. Reedy  added the comment:

A function can fail to return an expected object by either returning a wrong 
object or raising an (unexpected) exception.  The assertXyz methods, which 
ultimately raise AssertionError or something similar, are mostly about catching 
the first kind of failure, but tests should also catch and report the second 
kind.  The traceback shows the kind of failure.  The assertXyx failures add 
additional details after the traceback.


import unittest

class T(unittest.TestCase):
def test_f(self): raise TypeError()

unittest.main()

# Properly results in

Traceback (most recent call last):
  File "F:\Python\a\tem4.py", line 4, in test_f
def test_f(self): raise TypeError()
TypeError

--
Ran 1 test in 0.050s

FAILED (errors=1)

--
nosy: +terry.reedy
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue38294] re.escape no longer escapes "/" or ":"

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
pull_requests: +16021
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16442

___
Python tracker 

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

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[STINNER Victor]

STINNER Victor  added the comment:

> Is the behavior of tp_clear the key to this bug?

Once func_clear(my_func) is called, calling my_func() will crash: my_func() is 
unsuable.

Because of a complex dance involving borrowed references, the function is 
called *after* it's cleared.

Pablo's PR 15645 works around the problem by detecting this very specific case: 
call a function "after it's cleared" (while it's being garbage collected in 
practice).

Honestly, I'm still not sure how *exactly* the bug is triggered. I tried but 
failed to reproduce the initial cffi crash. reproducer.tar.gz is still a giant 
piece of code. I failed to simplify it to a few objects.

According to Pablo, gc_crash.py is a *different* (but similar) bug.

I would only be confident in approving a fix once I would be confident that I 
understood *exactly* how the initial bug (reproducer.tar.gz) occurred.

--

___
Python tracker 

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

[issue38296] unittest expectedFailure does not differentiate errors from failures

[Kit Yan Choi]

Kit Yan Choi  added the comment:

For your test:

class T(unittest.TestCase):
def test_f(self): raise TypeError()

If you run this test with unittest test runner, you should get this result:

E
==
ERROR: test_f (test_main.T)
--
Traceback (most recent call last):
  File "test_main.py", line 5, in test_f
def test_f(self): raise TypeError()
TypeError

--
Ran 1 test in 0.000s

FAILED (errors=1)


I expect to get this behaviour even if the test is decorated with 
unittest.expectedFailure. However, currently we get a success.


Scenario:


You create a class named Duck with a method "quack".  Then you added a test, 
and test needs to call Duck.quack.

Later on for whatever reason, you need to decorate the test with 
expectedFailure.  The test passes with the expected failure.

Then you rename the "quack" method to "walk", but you forget to update the 
test.  Now the test is actually failing with an AttributeError, but you won't 
notice it because expectedFailure silences it.

In this scenario, it is important to differentiate a "test error" and a "test 
failure". A test has four status: success, failure, error, skipped.  I expect 
unittest.expectedFailure to make "failure" a "success" and a "success" a 
"failure", and it should leave "error" and "skipped" unchanged.

Please consider reopening this issue.

--
nosy: +Kit Yan Choi

___
Python tracker 

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

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[STINNER Victor]

STINNER Victor  added the comment:

> If I understand Victor's test case correctly, the problem is caused if you 
> have an extension type that implements tp_traverse but not tp_clear and that 
> there is also a weakref involved in the trash cycle.

I'm not sure that "implements tp_traverse but not tp_clear" is enough to 
trigger the issue. It's unclear to me neither if it's a good practice or not to 
implement tp_clear... Since it seems like implementing tp_clear for functions 
(func_clear) caused this regression... Or maybe it's very specific to the magic 
combo: weak references with callback.

--

___
Python tracker 

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

[issue38296] unittest expectedFailure does not differentiate errors from failures

[Kit Yan Choi]

Change by Kit Yan Choi :


--
nosy:  -Kit Choi

___
Python tracker 

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

[issue29988] with statements are not ensuring that __exit__ is called if __enter__ succeeds

[Gregory P. Smith]

Gregory P. Smith  added the comment:

As a note on the general pattern, a user at work diagnosed a ^C problem in 
their code when running on 2.7 to be due to Queue.get's

acquire()
try:
  ...
finally:
  release()

Pattern, with the KeyboardInterrupt triggering after acquire() but before the 
try is entered.  so release() is never called.

A try finally pattern that probably alleviates this by entering the try block 
first might look like:

try:
  acquire()
  ...
finally:
  try:
release()
  except ThreadError:
pass  # interrupted before acquire() succeeded.


It'd be a shame if any with statements lock acquisition context managers need 
to be turned into that, but I _believe_ it'd be a viable workaround for the 
time being if this race is found to be biting anyone.

--

___
Python tracker 

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

[issue38301] If "_REENTARNT" is defined in the header file, we should use "-D_REENTRANT" when compiling

[Jesús Cea Avión]

New submission from Jesús Cea Avión :

When compiling on Solaris family, we define "_REENTRANT" in "Pyconfig.h".  That 
file is included when compiling C extensions, but if the extension is made of 
several C files, it could be included only in the file that interfaces with 
python runtime.

Unfortunately, "_REENTRANT" modifies the way C code is compiled, so compiling a 
C extension with some source files with "_REENTRANT" and some other without 
that "define" can produce bizarre errors and crashes.

One example: https://github.com/joyent/pkgsrc/issues/207

In particular, "include" order can make a big difference: 
https://github.com/jnwatson/py-lmdb/issues/213

I suggest that when "_REENTRANT" is defined in "Pyconfig.h", Python C 
extensions compilation machinery adds "-D_REENTRANT" to the compilation flags.

The patch is trivial.

--
assignee: jcea
components: Build
messages: 353416
nosy: jcea
priority: high
severity: normal
status: open
title: If "_REENTARNT" is defined in the header file, we should use 
"-D_REENTRANT" when compiling
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue38301] If "_REENTRANT" is defined in the header file, we should use "-D_REENTRANT" when compiling

[Jesús Cea Avión]

Change by Jesús Cea Avión :


--
title: If "_REENTARNT" is defined in the header file, we should use 
"-D_REENTRANT" when compiling -> If "_REENTRANT" is defined in the header file, 
we should use "-D_REENTRANT" when compiling

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Kyle Stanley]

Kyle Stanley  added the comment:

> You'll need to be careful to only revert the new functions & the 
> asyncio.Stream class.

So far the trickiest part has proven to be the tests (specifically 
test_streams.py) and keeping the deprecation warning for passing explicit loop 
arguments. I've had to be careful to be certain that no tests were 
unintentionally removed.

> Due to proximity to the deadline, please be prepared that we might need to 
> abandon your pull request if it's not ready by Sunday morning

No problem, I'll make sure to allow anyone with write access (yourself and 
Andrew) to edit the PR I open directly to make any needed changes. That way, at 
least any progress I make on it can help reduce the amount of work for you two.

--

___
Python tracker 

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

[issue38243] A reflected XSS in python/Lib/DocXMLRPCServer.py

[Dong-hee Na]

Dong-hee Na  added the comment:

Sure!

--

___
Python tracker 

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

[issue38302] __rpow__ not reached when __ipow__ returns NotImplemented

[Adi]

New submission from Adi :

Due to shared code between the 2 and 3 forms of pow, the following code causes 
a TypeError:

class A:
def __init__(self, val):
self.val = val

def __ipow__(self, other):
return NotImplemented

class B:
def __init__(self, val):
self.val = val

def __rpow__(self, other):
return A(other.val ** self.val)

a = A(2)
b = B(2)
a **= b


(https://stackoverflow.com/questions/58141475/ipow-raising-typeerror-when-left-hand-side-object-returns-notimplemented)

--
components: Interpreter Core
messages: 353419
nosy: DeepSpace
priority: normal
severity: normal
status: open
title: __rpow__ not reached when __ipow__ returns NotImplemented
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Kyle Stanley]

Kyle Stanley  added the comment:

Currently focusing on the Lib/asyncio/* and Lib/test/* changes. Working on doc 
changes next, but that should be significantly easier. 

In addition to 
https://github.com/python/cpython/commit/23b4b697e5b6cc897696f9c0288c187d2d24bff2
 (main commit from Andrew that added asyncio.Stream and new functions), I've 
also had to remove https://github.com/python/cpython/commit/4cdbc452ce3 (minor 
asyncio test change from Pablo) due to it causing issues with the other tests 
from deleting asyncio.StreamReader and asyncio.StreamWriter.

--

___
Python tracker 

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

[issue38292] tkinter variable classes don't link to widget if matplotlib's set_cmap() function is called before the tkinter GUI is instantiated

[Terry J. Reedy]

Terry J. Reedy  added the comment:

You neglected to state the observation that led to the conclusion of 'not 
linked'.  Using 3.8 on Win10, I replaced "plt.set_cmap('x')" with "tk.Tk()".  
Then, clicking the button prints 'False' even when the checkbutton is checked.  
After either removing 'tk.Tk()' *or* changing 'BooleanVar()' to 
'BooleanVar(root)', button clicks print 'True' when the checkbutton is checked.

Explanation of what I see: tkinter has attribute tkinter._default_root 
initialized to None.  By default, this is rebound to the *first* root created 
by an internal or user tkinter.Tk() call.  Barring exceptional circumstances, 
one should either always use the default root and never create and pass a named 
root *or* never use the default one and create a named root and always pass it. 
 Your program is buggy in using the default root for the var and the named root 
for the buttons.  When the two are different, the expected linkage does not 
work.

I assume that you see the same failure with the code you posted and the same 
fix after (re)moving the .set_cmap call.  So I am further assuming that 
set_cmap somehow results in a default root being created and that fixing the 
buggy BooleanVar call will also fix things.

To test the set_cmap assumption, add "print(tk._default_root)" *before*  "root 
= tk.Tk()".  Do you see 'None' or '.'?  Does adding 'root' to the var call fix 
the link?  If you seen 'None' and the link still does not work, then 'set_cmap' 
must be affecting tkinter some other way, which would likely be a 3rd party bug 
in that function or pyplot.

--
nosy: +terry.reedy
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.6

___
Python tracker 

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